AI Strategy · Agentic Patterns

Hora’s Watchmaker: Decompose, Interface, Map, Dumb Recompose

The 60-year-old pattern that makes AI work survive an agent that dies every hour — and why “it fits the context window better” is only a quarter of the story.

Scott Farrell — LeverageAI  ·  ~12 min read

Here is a small thing every serious builder of AI agents has noticed and almost nobody has explained: the smaller the artifact you hand an agent, the better it does. Break the 1,000-line file into modules and the coding agent stops mangling it. Split the ebook into a file per chapter and the writer stops losing the plot. Turn the knowledge base into a page-per-idea wiki and a cheap model suddenly reasons like it knows your business.

The usual explanation is “it fits the context window better.” That is true, and it is about a quarter of the reason. The other three quarters are more interesting, they don’t go away when the windows get bigger, and they turn out to be the same pattern showing up on four completely different planes of work.

To see why, we need a watchmaker who has been dead since 2001 and a memo from 1972. Then we can talk about why your agent keeps dying.

The two watchmakers

In 1962, Herbert Simon — Nobel laureate, one of the founders of artificial intelligence — wrote a paper called The Architecture of Complexity.¹ Buried in it is a parable about two watchmakers, and it is the most useful thing you will read this year about building with AI.

Both watchmakers, Tempus and Hora, make fine watches of about a thousand parts. Both are successful, so their phones ring constantly with orders. Here is the difference.

Tempus built each watch as a single assembly. Every part was added directly to the whole. If he had to put a half-finished watch down to answer the phone, it fell to pieces, and he had to start again from the first part. As his business got more popular and the interruptions more frequent, it became nearly impossible for Tempus to finish a watch at all. He went broke.

Hora built his watches out of stable subassemblies — units of about ten parts that held together on their own. Ten subassemblies made a larger unit; ten of those made a watch. When Hora’s phone rang, he lost only the small piece in his hand. Everything he had already assembled stayed assembled. Hora prospered.

Complex systems that survive in an interrupting world are built from stable intermediate forms.
— Herbert Simon’s argument, The Architecture of Complexity, 1962

Simon’s point was about evolution and organisations. But read the parable again with one substitution, and it stops being a nice analogy and becomes an operating manual.

Your agent is Tempus

What is an LLM agent’s working life actually like? Constant interruption. Context windows fill and end. Sessions die. Compaction eats the history mid-task. The next agent that picks up the work starts cold, with no memory of what the last one was holding. An agent’s normal condition is Hora’s ringing phone, except the phone never stops.

Now the parable bites. A monolith forces every agent to be Tempus. Hand an agent one giant undecomposed artifact and every interruption threatens the whole thing — it has to re-hold the entire context to make a safe change, and when the context ends, the work in flight falls apart. Hand it stable subassemblies — a function, a chapter file, a wiki page — and each one survives the death of the session that made it.

That is why “decompose, make it navigable, recompose” is not merely good taste borrowed from software engineering. It is an agentic pattern, forced by a property of the workers themselves. Software engineers decompose to manage human attention and change. We decompose for that too — plus a reason Simon would recognise instantly: our builders are mortal on a one-hour clock.

Why “fits context better” is only a quarter of it

Once you stop thinking about the window, you notice that a well-chosen component is doing four jobs at once. It is simultaneously:

The unit of edit is the one the early coding models taught us the hard way. Anyone who used agentic coding tools in the early days remembers what happened past about a thousand lines: the model would lose the spot, patch the wrong region, and occasionally delete a big chunk while trying to make a small change. Those weren’t intelligence failures. They were addressing failures — the agent couldn’t reliably locate a span in a thousand-line sea. Small files fix it by making the filename the address. You don’t ask the model to find the code; you hand it the file.

The unit of regeneration is the sleeper. A component is the largest thing you can cheaply throw away and regenerate from its specification. That means decomposition sets your regeneration granularity — it decides how fine-grained your “delete and rebuild from the recipe” move can be. If your regeneration doctrine says the durable asset is the recipe, not the output, then your decomposition is literally drawing the borders of what you can afford to regenerate.

The unit of parallelism is why the whole pattern stays optimal even as models stop choking on big files. A monolith serialises your agents — only one can safely touch it at a time. Components let a hypersprint fan out ten workers with no merge conflicts, because each owns its own file.

The full pattern: decompose, interface, map, dumb recompose

Breaking things up is the famous half. The half that gets skipped is what holds the pieces together — and getting that half wrong quietly re-creates the monolith you just escaped. The complete pattern has four moves.

1. Decompose. Cut the work into components sized to the unit of attention — a function, a prompt file, a chapter, a wiki page.

2. Interface. Give each component a cheap interface: a small, stable surface that lets you use it without reading its body. The function signature. The one-line chapter card. The index entry. This is not a new idea — it is David Parnas’s information hiding from 1972,² the insight that a module should hide a design decision behind a stable interface so changes don’t ripple. Fifty years later it is the reason a coding agent can call a function it hasn’t read, and a writing agent can reference a chapter it isn’t holding.

3. Map. Keep a deterministic manifest of how the interfaces connect — the call graph, the index.md, the outline file, the table of contents.

4. Dumb recompose. Assembly must require no intelligence. A function call. include 'chapter3.php'. Concatenating by the outline. This is the load-bearing leg, and here is why:

If composition required intelligence, you’d re-import the monolith problem at assembly time — just moved somewhere later, and harder to see.

The moment your reassembly step needs a model to figure out how the pieces fit, you have built a second monolith at the seam. Intelligence belongs in the components. The glue between them must be mechanical. Intelligence in the parts, a cheap interface on each, a dumb map that clicks them together.

The flagship: the wiki is a codebase

Here is where it stops being a metaphor. Run the four-move lens over a knowledge wiki — the page-per-idea, edge-linked kind — and the correspondences are not poetic. They are exact.

Pages are functions. Edges are the call graph. The index is the manifest. Claims are statements. And the maintenance agent that keeps the wiki healthy — the “janitor” — is doing something a software engineer would recognise on sight: it is a refactoring engine.

You didn’t build a knowledge base that resembles a codebase. You built a codebase whose language is claims — and imported forty years of software maintenance discipline for free.

That is why the janitor works, and why it was buildable at all: refactoring is a solved craft. Once your knowledge graph is a codebase in disguise, decades of hard-won discipline — deduplication, extract-method, splitting overgrown modules, running the tests before you commit — arrive already invented. You are not designing a novel knowledge-maintenance system. You are running refactor on your worldview.

One pattern, four planes

Step back and the same move appears everywhere, applied to a different kind of matter each time. This is the generalisation that turns an anecdote into a framework.

• Code. Functions and classes. Prompts pried out into their own markdown files so they’re separately maintainable. The original plane, where every engineer already lives.
• Artifacts. The chapter-per-file ebook. Each chapter is its own file; the writer works one chapter’s context at a time; a trivial include — or php index.php > index.html — assembles the book. This article’s ebook edition is built exactly that way.
• Agents. Micro-agents: single-responsibility workers behind a thin router, instead of one mega-brain juggling every tool. The agent plane — a pattern we’ve argued in full elsewhere, and it is the same cut.
• Knowledge. The wiki. Worldview decomposed into pages with edges, recomposed on the fly from whatever the task at hand actually needs.

Same move each time: match the unit of matter to the unit of attention, hide the bodies behind cheap interfaces, keep the map deterministic. Knowledge is probably the last plane, because a worldview was the only asset most of us hadn’t yet decomposed. We were still keeping it as one big document — the monolithic “kernel” — and wondering why it kept going stale and why every task seemed to need its own version. It turned out the kernel just hadn’t been refactored yet.

The hard part: where to cut

One honest boundary, from the same 1962 paper. Simon’s exact phrase was not “decomposable.” It was nearly decomposable. Real systems are never perfectly separable; some concerns cut across every component. That is precisely why edges exist — they carry the cross-cutting relationships that don’t belong inside any single piece.

Which gives you a diagnostic. When a wiki page — or a module, or a class — starts sprouting edges to everything, that is the god-object smell. It’s not telling you the thing is important. It’s telling you the cut lines are wrong: a real component is hiding inside it, badly separated. The janitor’s hardest judgement calls are all of this species, and so are a senior engineer’s.

So the next time an agent handles a small file beautifully and chokes on a big one, don’t reach for a bigger context window. Reach for Hora’s bench. Decompose the work into stable subassemblies, give each a cheap interface, keep the map dumb, and let assembly be mechanical. Build for the watchmaker who keeps getting interrupted — because that watchmaker is the one doing your work now, and their phone never stops ringing.