Operations
Reproducible infrastructure: the overlooked precondition for AI agents
Starting an agent is easy compared with explaining how someone else would restore it on a new machine after a failure. If that requires memories of manual installations, personal shell settings and spoken instructions, the operation depends on particular people. Reproducible infrastructure is therefore not a matter of technical aesthetics. It creates a basis for carrying responsibility across staff changes and changes to the technology itself.
Move the intended state out of individual heads
Declarative infrastructure describes what a system should look like instead of recording only a sequence of past interventions. In NixOS, important system properties are expressed as configuration. This makes services, dependencies and settings discussable before they take effect on a machine. A new colleague does not have to infer every historical decision from the current state of a running computer.
The business significance is the ability to hand over responsibility. When someone is unavailable, knowledge of how an important working environment is assembled should not disappear with them. A description alone is insufficient, however: it must actually cover the relevant parts. Credentials, external services and persistent data need additional ownership because a package definition does not automatically make them available or restore them.
Treat agents as reviewable infrastructure
In my open-source project tentaflake, isolated agents on a NixOS host are described declaratively and managed through system services. The installation owns its configuration; importing an agent does not start it. This is a concrete example of separating setup from activation. The question becomes not only which model to use, but also which environment and authority to give it.
Tentaflake is explicitly at an early stage of development. Interfaces and security policy can change, and real provider acceptance is not fully established. This makes declarative descriptions valuable: assumptions and changes become available for discussion. They do not replace evidence that a particular installation actually enforces its intended resource, network and access boundaries under the conditions in which it will operate.
Give each change a traceable verification path
A configuration difference is easier to discuss than someone's recollection of a series of manual interventions. A readable difference still does not establish that the new environment works. Before approval, it must be clear which checks should assess the change and what prerequisites they need. Otherwise reproducibility is confused with correctness: an unsuitable configuration can also be recreated reliably and consistently.
My open-source project project-check-nix runs verification commands explicitly declared by a repository. A plan can identify prerequisites without executing those checks, so ready does not mean passed. Missing coverage and blocked checks do not count as success either. The runner is not a sandbox. It structures evidence but replaces neither the host's security boundary nor the judgement needed to select meaningful checks.
Rollback is a decision about state
Returning to a previous system configuration is an important benefit of a declarative operating approach. It does not automatically answer what happens to data changed in the meantime. An agent might already have edited files or triggered external actions. Reverting its runtime environment does not undo those effects. Configuration, stored state and external consequences therefore require separate recovery considerations rather than one reassuring rollback label.
For an accountable approval, I would discuss the route back before making the change. Which earlier configuration remains available? Which data needs its own backup? Who decides whether moving backwards is still acceptable? Such a plan should be exercised in the actual environment. The mere existence of a rollback mechanism is not evidence that your particular operation can successfully resume after using it.
Source access supports a handover but cannot replace it
My public Rust fork mcp-nixos-rust makes NixOS ecosystem information queryable by AI clients. It builds on an existing MCP project and can expose package and configuration sources, among other information. That helps people investigate assumptions about an environment. Certain local queries require Nix; ordinary API queries do not. These dependencies belong in a useful handover, not only in the memory of whoever originally assembled the system.
Finding a source does not establish that it has been applied correctly to your system. Configuration, its rationale and observed verification results need to remain understandable together. For me, that is the real value of reproducible infrastructure in agent operation: the machine does not assume responsibility. People gain a shared, inspectable basis for understanding changes, assessing boundaries and handing operation over to somebody else.
Questions for your team or vendor
- Could another person recreate the agent environment on a new machine using our documentation?
- Which settings are declared, and which exist only on the running system?
- Which checks actually ran, and which remained open because prerequisites were missing?
- What can be rolled back, and which data or external actions remain unaffected by that rollback?
- Who owns configuration and approves changes to permissions, network access and dependencies?
- When did we last exercise rebuilding and handover in the intended environment?