Agents Don't Have a Reasoning Problem. Builders Have an Architecture Problem.

Microsoft Research shipped two papers in one week, SkillOpt and Memora, and both land on the same read: deployed coding agents have no real memory and no reliable way to learn from their own mistakes. The industry's fix is to build better memory systems. That is the wrong layer. Agents do not have a reasoning problem or a capability problem. They have an architecture problem, and it is baked into how the models were trained and how we ask them to work.

Here is the shape of it. Every frontier model learned to write code from real developer codebases: complex, elegant, deeply interconnected systems built by engineers who could hold the whole thing in their head, or at least knew the architecture well enough to know where every piece lived. So when a model writes code, it reaches for that same style. Elegant, clever, cross-referencing, DRY. That is exactly why something like Fable v5 can one-shot a genuinely complex app. The model is pattern-matching against beautifully architected human code, and it is very good at that pattern, in a vacuum.

The vacuum is where it breaks

A model, or an agent looping on a model, cannot hold an entire real codebase in its head. It works in chunks, bounded by a context window. Any project that has been alive for a meaningful amount of time blows past a million tokens of code. So the moment you point an agent at extending that codebase, it is, by construction, working from an incomplete picture. It is touching parts of a system it cannot fully see.

And its instinct is still to write it the elegant, cross-referencing way, the way it learned from human codebases meant to be held in one head. So it reproduces logic that already exists elsewhere, because it genuinely cannot see that the function is already there, three directories over. You get patchwork. Duplicate functions scattered across the codebase, drift between them, and because the whole thing is too large for the agent, or a human skimming its output, to hold at once, that duplication is brutally hard to even find, let alone reconcile.

This is the exact failure mode SkillOpt and Memora are patching. Give the agent a skill library. Give it episodic memory. Let it learn from past failures instead of repeating them. Those are real, useful ideas. But they solve it at the memory layer. They try to help the agent remember more of a system that was never designed to be partially understood in the first place. It is a sophisticated bandage on the actual wound.

Fix the architecture, not the memory

My bet is on fixing the architecture the code is built in, not the memory the agent carries around. If the codebase itself is the thing too big to fit in context, the fix is to stop building codebases that require full-context understanding to extend safely.

AI coding agent architecture is the discipline of shaping code so no single unit of work ever requires seeing the whole system. Concretely, that means atomic units instead of elegant, interwoven ones.

An atomic unit is a small, self-contained piece of logic with a clearly defined input and output, sized to fit entirely inside an agent's context window, and decoupled enough from its neighbours that touching or breaking one does not cascade into breaking the system.

Instead of writing the thing as one clever, cross-referencing implementation, you write a sequence of atomic steps that compose into the thing. That reads as more moving parts on the page, and it is. You trade a little elegance for a lot of legibility.

Three things that buys you

None of them are abstract.

1. The agent can actually reason. Hand it one atomic unit and it loads the entire relevant context for that unit. It reasons about a complete picture instead of guessing at a system it can only half see. The duplication problem disappears at the source, because the unit's boundary is the whole world the agent needs to hold.

2. The system gets resilient. A bad change stays contained. It does not quietly ripple through five files nobody re-reads. When something breaks, it breaks in one bounded place with a defined input and output, which is the difference between a ten-minute fix and a two-day archaeology dig.

3. It is legible to less technical builders. Each piece can be understood entirely on its own terms. You do not need to hold the architecture in your head to reason about one unit, because the unit does not depend on the architecture living in your head.

None of this is new, and that is the point

Atomic units, clean input and output, no shared state, composed rather than intertwined: this is not a discovery, it is a return. Unix got there first, build small programs that do one thing and compose them with pipes. Erlang and the actor model got there by assuming failure and isolating it inside message-passing units that cannot take the rest of the system down with them. Microservices got there for the same reason at a different scale: a service you can reason about in isolation is a service you can change without an all-hands meeting. Functional programming has been arguing for pure, composable, side-effect-free units since before most of the current frontier models' training data existed.

We did not invent an architecture. We took architecture that already survived decades of humans needing to reason about systems too large for one head, and pointed out that agents have exactly the same limitation humans do, a bounded window they can hold at once, so the same medicine applies. The insight is not the pattern. The insight is that the constraint an agent has is not new, we already know how to build for it, and the industry is currently trying to invent a new fix instead of reaching for the established one.

Why this matters more for builders than for engineers

A senior engineer can survive an elegant, tangled codebase. They built the mental model as they went, they know where the bodies are buried. That is precisely the model an agent does not have and cannot build. It shows up cold to every session.

But the same gap exists for a non-technical builder working with an agent. They cannot hold the tangled version in their head either. Atomic units fix both problems with the same move: a unit small enough for an agent to reason about in full is also small enough for a founder, an operator, a non-engineer, to point at and understand on its own terms. You do not need to hold the system's architecture in your head to reason about one piece of it, because the piece does not depend on that. That is what makes the pattern legible to the people actually building with agents today, most of whom are not classically trained engineers.

The concrete version we run on

Internally, our version of this pattern is what we call the gateways, tools, and workflows model: external connections isolated in one layer, atomic capabilities as tools, fixed sequences composed as workflows. We wrote the full breakdown here: The Gateways-Tools-Workflows Model That Kills Token Waste. nyyon-lite is our end-to-end reference build of that model, proof it holds up under a real agent doing real extension work, not just a diagram.

A question worth asking your own codebase

Look at whatever you are building or extending with an agent right now and ask three things. Is the logic more complex than it needs to be, or has it just accreted that way. Would it be simpler, and more legible, mapped into a gateways, tools, and workflows shape, small atomic pieces with clear boundaries instead of one clever interwoven thing. And most importantly: is it easier to extend six months from now, when neither you nor the agent remembers why a given function lives where it does.

If the honest answer is that your architecture only works because you are still holding it together in your own head, it will not survive being handed to something that never had that picture to begin with.