The atomic-unit architecture, twelve months in

Twelve months ago, almost to the week, I wrote the atomic-unit-architecture piece. The argument was that AI workloads should be designed as bounded atomic units, each interaction with its own context window, its own audit trail, its own memory boundary, its own permission scope, rather than as long-lived sessions or shared-state agents. I framed it as the right mental model for production AI in regulated environments. I've been building inside that pattern for a year. Worth grading.

The honest summary: the core of the pattern held up better than I expected. Two of the load-bearing claims bent under real workloads. One thing I didn't address turned out to be the most important question of the year. Worth being plain about all three.

What held up

The bounded-context claim. The single strongest thing in the original piece was the argument that an AI interaction's context window should be its security boundary, not its session boundary. Twelve months in, this is the thing I'm most glad I wrote. Every public incident I've followed in multi-tenant AI started when context bled between units. Every system I've watched avoid a class of incidents had drawn the boundary around the unit and held it.

The pattern survives because it maps to how AI actually fails. Models don't fail at the call; they fail at the context. A context that contains data from two tenants is a context that can leak data from one tenant into the other tenant's response. The atomic-unit framing turns the boundary problem into a build-time decision instead of a run-time one. That's a real win and it kept being a real win.

The audit-per-unit claim. I argued that every atomic unit should produce its own complete audit record, inputs, tool calls, intermediate states, output. The piece I wrote in October extended this. Twelve months of operating against this discipline: it's the difference between debuggable AI and undebuggable AI. Systems that kept the audit-per-unit invariant could answer "what happened" questions in minutes. The ones that didn't spent days reconstructing.

The economic argument also held. I'd worried storage cost would be the constraint; it wasn't. Audit-data volume scales with interaction count, and even at production scale the storage bill is trivial compared to the inference bill. The real constraint turned out to be retention policy and PII handling, both solvable problems, neither of which scared anyone away from the pattern.

The MCP-shaped tool surface. The original piece predicted MCP would become the right surface for the tool-side of the atomic unit. The MCP-only-architecture piece made that more concrete in mid-2025. By early 2026 this is just true. MCP is the tool surface; the atomic unit composes cleanly with MCP servers because each unit gets its own session, its own scope, its own permission set. The two patterns reinforce each other. I got lucky on the timing of the MCP bet, and the atomic-unit framing made the MCP integration almost mechanical.

What bent

The "stateless by default" claim was too strong. I wrote the original piece with a strong stateless-by-default disposition, each atomic unit should start clean, pull what it needs, and return clean. The framing was right for security; it was too strong for usability. Twelve months of running this pattern on my own stack taught me that some workflows want continuity across units, and forcing them into the strict-stateless mold produces awkward UX without producing meaningfully better security.

What I'd write now: stateless by default at the security boundary, with explicit, audited, scoped continuity primitives layered on top. The continuity is the user-visible feature; the statelessness is the underlying invariant. The two aren't in tension as long as the continuity primitive is itself an atomic unit with its own audit and its own scope. I had the right instinct and the wrong vocabulary. The pattern needed a "continuity-as-unit" sub-pattern and I didn't write it.

The single-model-per-unit assumption. I implicitly assumed each atomic unit would call one model. Reality through 2025 was that the interesting units called several, a router model, a tool-using model, a verifier model, sometimes a small fast model for a sub-step. The atomic unit is still the right boundary; the inside of the unit got more complex than I anticipated. The audit story still works (just log more). The context-isolation story still works (the unit's context boundary contains all the model calls). The framing I gave for "what's inside an atomic unit" was too simple, and I'd write the inside-the-unit chapter differently now.

The bent claims aren't refutations. They're places where the pattern needed more nuance than I gave it. The skeleton holds; some of the muscles needed redrawing.

What I missed

The thing I didn't address at all in the original piece, and which turned out to be the most important question of the year, is how atomic units compose into agents.

I wrote the piece treating each unit as the natural unit of work. I left the question of "what happens when you string a hundred of them together to do something an agent does" entirely alone. By mid-2025, the agent workflows I was building had units composing into chains, chains composing into plans, plans composing into longer-running workstreams. The atomic-unit framing kept being the right unit for the security and audit story. It wasn't the right unit for reasoning about the agent's behavior over time, the agent's accumulated effect, the agent's drift.

What I needed and didn't write: a layer above the atomic unit that addresses the trajectory, how units compose, how the composition is itself audited, how the chain's permissions are bounded relative to the unit's permissions, how the agent's running state is reconciled against the unit-level audit trail. The atomic-unit pattern is necessary; it isn't sufficient for agent-class workloads.

I'm sketching a follow-up that addresses the composition layer specifically. The working title is something like "the trajectory layer above atomic units." The piece doesn't exist yet because I'm still working out which abstractions earn their keep. The honest version of what I missed: I wrote a foundation piece and treated it as a complete piece. The composition layer was the obvious next chapter and I didn't see it as a gap until I was three months into needing it.

The pattern as it stands now

What I'd tell someone starting fresh in 2026:

The atomic unit is still the right primitive. Build to it. Make each AI interaction a bounded unit with its own context, its own audit, its own memory scope, its own permission set. The discipline pays for itself the first time something goes wrong.

Statelessness is the invariant; continuity is the feature. Don't build the security boundary around the statefulness. Build it around the unit boundary, then layer continuity on top as its own audited primitive. Both can be true simultaneously and the layering matters.

MCP is the tool surface; the atomic unit composes with MCP cleanly. This was a happy accident of timing in 2025; in 2026 it's just the convention. If you're building an AI workload that uses tools, you're using MCP servers, and each atomic unit gets its own MCP session.

Multi-model units are normal; the boundary is still the unit. Don't try to push the security boundary down to the individual model call. The unit is the right grain. Inside the unit can be as complex as the workload needs.

The composition layer is the open question. Atomic units handle the per-interaction story. Agent workflows need a trajectory story on top. That story is being written by the practitioner community in real time and the conventions aren't settled. Watch the space; expect to revise.

The grade

If I had to put a letter on it: B+. The core thesis held up. The framing was useful enough that teams are using the pattern in production and the pattern is doing what it was supposed to do. Two of the load-bearing claims needed nuance I didn't provide; one chapter was missing entirely. Not an A. I'd want the missing composition chapter to call it complete. Not lower, the part I wrote did the job and continues to do it.

Worth coming back to in another twelve months. The composition piece will exist by then; the multi-model chapter will be conventional; the bridge between atomic-unit and agent-trajectory will either be settled or will be the next obvious open question. Either way, grading the pattern annually has been useful and I'm going to keep doing it.

The original piece was right that AI workloads need a stronger primitive than the session. The atomic unit was the right call. The piece I'd write today is more honest about where the unit ends and the agent begins. That gap is the next year's work.