What makes an atomic agent genuinely atomic? It needs to be defined declaratively. A single specification that captures what it does, what it takes as input, what it produces, and what constraints govern its behavior. Defined this way, agents become composable. A parent agent orchestrates child agents. Child agents run in parallel. The entire graph can be inspected by reading a spec file rather than tracing through opaque code.
This is the same insight that made infrastructure-as-code work. When infrastructure is a YAML file, anyone can read it, audit it, version-control it. When an agent is a declarative spec, the same properties hold. A business analyst can read it. A compliance team can audit it. An engineer can swap the underlying model without changing the spec.
Composability enables model optimization at the atomic level. If one agent's job is to say yes or no, you do not need a frontier model. Test cheaper models against the known-good outputs of the expensive one, validate accuracy, swap. The savings compound across hundreds of agents — but only because each agent is isolated enough to evaluate independently.
This matters because cost is going to dominate the operational picture as agent fleets scale. A team running thousands of atomic agents on a frontier model is going to be unhappy with the bill. A team running the same fleet with appropriate models per task — small models for classification, frontier models only where reasoning depth justifies it — pays a fraction. The ones who can do that are the ones who isolated each unit cleanly enough that swapping is a config change.
Declarative specs are also what make agents software, not prompts in any operational sense. The spec is the artifact engineers version, review, and deploy. The prompt inside is an implementation detail.
If you are designing agent infrastructure, treat the spec format as load-bearing. It will outlive the models you start with. Get it right and the rest of the system gets easier.
Sources
Related Essays
Agents Are Software, Not Prompts
The industry treats agents as a new category. They are not. Agents are software, and the same engineering principles that have always mattered still apply.
The Agent Is the Primitive, Not the Automation
Automations bundle trigger, prompt, tools, and model into one flat object. That works at five. It falls apart at fifty. The agent has to become its own primitive.
Sessions Replace Tasks, Runs, and Threads
When the same object has three names, your architecture is drifting. Tasks, runs, threads, chats — all of it is just a session. One container, many shapes of work.
Key takeaways
- An atomic agent is defined declaratively — a spec, not a sprawl of code.
- Declarative specs make agents composable, auditable, and version-controllable.
- Atomicity enables per-agent model optimization. Cheap models for cheap jobs, frontier for the rest.
FAQ
What does declarative mean for an agent?
A single specification that captures what the agent does, what it takes in, what it produces, and what constraints govern it. Anyone can read it. Anyone can audit it. The spec is the source of truth.
How does atomicity drive cost savings?
If an agent's job is to say yes or no, you do not need a frontier model for it. Test cheaper models against the known outputs of the expensive one. The savings compound across hundreds of agents — but only because each agent is isolated enough to evaluate independently.