Give AI agents a way to verify their infra work

Coding agents have become remarkably capable. Give Claude access to a repository and it can write features, fix bugs, refactor code, and complete complex tasks with minimal supervision.

Part of that improvement comes from better models, but a large part comes from the loop around the model: they execute code, run tests, inspect results, and use those results to improve their work. Anthropic captures the pattern succinctly:

Give Claude something that produces a pass or fail, and the loop closes on its own. Claude does the work, runs the check, reads the result, and iterates until the check passes.

This lesson applies to infrastructure code equally. Unfortunately, checking an infrastructure task is non-trivial and has received less attention in the industry. How does a model check the SONiC or Arista config it just generated? Or how does it validate that the newly generated deployment script passes?

Antrieb is a research project on this topic, to help fill the gap so humans stop being verification loops for LLM-generated infra code. It does so by allowing agents to spin up testbeds instantly, wire them, use them, and dispose them. We created short demos showing Antrieb in Action.

The Runtime for Infra Is a Testbed

Software has runtimes in the form of containers or virtual machines. Infrastructure has a larger runtime: a testbed with machines, clusters, networks, switches, routers, storage, operating systems, and services. Once those things exist, the checks are familiar. Can the nodes reach one another? Did DHCP assign addresses correctly? Did the cluster form? Are pods distributed as expected?

There are obvious apparently simple answers: use staging, give the agent access to a shared lab, or hand it a hypervisor. Each helps, but each misses part of the loop. A human-operated environment leaves the human as the conduit. A shared long-lived environment accumulates state and loses reproducibility. Raw hypervisor access pushes too much low-level orchestration into the agent’s reasoning loop. The useful testbed is one the agent can operate directly to mimic the real world (faithfulness), recreate quickly (instantaneity), and throw away after each attempt (disposability).

Faithfulness

Faithful means the environment preserves the parts of the real system that matter for the check. Faithfulness has many dimensions: operating system image, kernel version, package set, network topology, etc. Each infrastructure task depends on a different subset of those dimensions, so faithfulness has to be chosen deliberately.

For instance, a BGP exercise depends heavily on routing behavior, while Kubernetes scheduling may care more about node topology and labels. Reproducing every dimension is usually expensive and often unnecessary, so the useful environment is the one that preserves the properties that decide the outcome being exercised.

Other dimensions that impact faithfulness are age of environments under test (e.g. legacy) as well as physical distance from the datacenter (e.g. edge, field).

Disposability

In app development, a test runner starts clean: no leftover state, no half-applied fixes, no residue from the previous attempt. Infrastructure loses that property quickly because the agent patches, retries, changes routes, restarts services, leaves temporary files, and modifies cluster state. After a few rounds, "it works now" may only mean the environment has evolved around the mistakes.

The same applies when the agent original hypothesis was based on a wrong assumption, such as the wrong NIC names. It should be able to throw the testbed away and recreate a clean one.

A disposable testbed restores the clean slate. If a solution cannot be reproduced on a fresh testbed, it does not count.

Instantaneity

Instantaneity matters because the loop has to stay usable. Slow provisioning creates more opportunities for timeouts, retries, partial output, stale assumptions, and half-explained state. Those artifacts become part of the testbed state and of the agent's working context. That means, the model has to reason over more noise while still deciding what to try next.

The human side follows the same pattern. A loop measured in seconds keeps supervision engaged, while a loop measured in minutes sends attention elsewhere, to coffee, Slack, email, or some other distraction. By the time the testbed is ready, the context the person was holding has to be rebuilt.

Verification works best when the testbed can be recreated fast enough to stay inside the loop, both for the model and for the person watching it. In fact, this applies to both manual and automated verification. Slow or awkward verification creates pressure to skip verification. That is how "looks done" infrastructure code can make its way toward production.

Antrieb

Antrieb provides an implementation attempt for the runtime described in this article. It gives infrastructure agents access to the primitives they need to close the loop themselves: machines, clusters, LANs, NICs, switches, routers, egress, operating system images, command execution, and runbooks. An agent can provision up to four virtual machines in roughly two seconds, wire them up, deploy packages, run checks, inspect failures, and destroy the testbed when done. Because the testbed appears quickly, verification stays inside the agent's reasoning loop instead of becoming a separate human operational task.

The available operating systems include general-purpose Linux distributions, network operating systems, and firewall/router images such as VyOS, OpenWrt, SONiC, and OPNsense. Users can also create custom images to extend faithfulness.

The reader is welcome to try Antrieb. The easiest way is through Claude.ai. Add a connector with the MCP server: https://antrieb.sh/mcp. Then run an infra task.

For example:

Create a SONiC switch with two isolated LANs, attach three Ubuntu nodes, install k3s, deploy nginx with anti-affinity, and verify failover.

Or:

Create a 4-node cluster. On three nodes, install httpd on port 6700; on the fourth, install HAProxy and configure it as a load balancer.

Not every check needs live execution by the AI agent. When infra code is generated, some questions can be answered from the existing configuration, through static analysis, simulation, or modelling, and Antrieb supports these approaches as well. For instance, some network configurations can be verified with the Batfish images. These approaches answer different questions, and the agent can reach for whichever the task needs.

Conclusion

The advice from Anthropic's guide is simple:

"Claude does the work, runs the check, reads the result, and iterates until the check passes."

That loop is now ordinary in software, and infrastructure deserves the same treatment. Today, many infrastructure prompts produce infrastructure code and, in the optimistic case, human verify them. The model writes, and the human provisions, deploys, inspects, diagnoses, and decides what passes.

A realistic disposable testbed changes that loop because the agent can provision the machines, wire them, deploy the system, inspect the outcome, run checks, and keep iterating until the checks pass. That is the idea behind instant ephemeral infrastructure for AI agents. See Antrieb in Action.

If AI infrastructure agents are going to become genuinely useful and safe, they need a place where reality can answer back. Antrieb gives them that place.