The layers of coding-agent infrastructure
A model call is not an agent platform. Production coding agents need context acquisition, task orchestration, tool routing, execution, credentials, policy, observability, artifact handling, and a way to reconcile completed work with the repository. The “agent infrastructure” category covers that supporting system.
A useful architecture separates concerns instead of hiding them behind one broad agent API. The orchestrator decides what should happen. The sandbox owns where commands and writes happen. The evidence plane reports what happened. The publication path decides what becomes durable. A browser console, CLI, or MCP adapter can then expose those capabilities without changing their underlying semantics.
| Layer | Responsibility | Failure to avoid |
|---|---|---|
| Orchestration | Task planning, assignment, retries, and dependency order | Two agents unknowingly own the same task |
| Sandbox control | Create, inspect, export, and destroy environments | Orphaned environments and ambiguous lifecycle |
| Runtime | Execute commands and file operations in a named workspace | Edits escape into another task’s state |
| Observability | Health, events, resources, activity, and provenance | Promotion without enough evidence |
| Publication | Reconcile private output with current shared history | Partial or last-writer-wins changes |
Why the agent sandbox is an infrastructure layer
Coding work has continuity. A command may keep running after the initial response, a second operation may need the files created by the first, and a task may span many tool calls. That makes the sandbox more than a one-shot command runner. It owns a lifecycle and a stable execution identity.
Ephemeral Sandbox separates the manager-owned sandbox, the writable workspace session, and the narrower command session. A sandbox identifies the container, daemon, endpoints, runtime state, and workspace root. A workspace session identifies a leased LayerStack view with private writable state. A command session identifies one running process and its transcript. These identities let an orchestrator resume or inspect the right scope rather than guessing from a process ID or directory.
- Stable sandbox, workspace, command, and request identifiers
- Explicit creation and destruction rather than directory conventions
- Separate management, runtime, and observability capabilities
- Bounded operations with structured requests and responses
- Private state over shareable immutable project history
- A finalization contract for accepted and rejected work
A narrow control plane for agents and operators
Ephemeral Sandbox exposes one authenticated gateway to management, runtime, and observability clients. Public CLI and MCP tools are generated from the same operation catalog. The CLI keeps three separate executables; each MCP process selects exactly one tool set. This allows a deployment to grant an observer read-only evidence access without also granting command execution or destruction authority.
The browser console is maintained as a separate consumer. That separation keeps user-interface concerns out of the Rust core and requires adapters to consume an immutable compatible set of operation contract, catalog, and client revisions. See the operation reference for the current public vocabulary.
Evidence and publication are part of the product
An agent that returns “done” has reported a belief. Infrastructure should expose independent evidence: exit states, stable command transcripts, file activity, resource readings, LayerStack state, and line attribution. Evidence is point-in-time and can be partial, so clients should preserve timestamps and errors rather than turning every inspection into a misleading boolean.
Publication is also distinct from execution. In Ephemeral Sandbox, capture turns private session changes into a proposed delta. The latest shared head is checked, conflicts are resolved per path, and one immutable layer is published or the change set is rejected. This makes the promotion decision explicit and traceable for an agent swarm.
Questions for an agent infrastructure evaluation
- Which component owns lifecycle and cleanup?
- Which filesystem, process, network, and credential boundaries are actually enforced?
- Can multiple agents share base data without sharing writable state?
- Are tools separated by authority, or does one token grant everything?
- Can an operator inspect activity and provenance before publication?
- Does publication account for changes made after a task began?
- Can clients resume a running process through stable identifiers?
- Are security non-goals documented as clearly as supported features?
Ephemeral Sandbox provides the sandbox, runtime, evidence, and publication layers; it does not prescribe a model vendor or agent orchestrator. Start with the quickstart or inspect the open-source Rust core to decide where it fits in your control plane.