Problem 15 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Sequential Pipeline Routing Pattern.

The Problem — Producing a verdict no single model can fake

One judgment is unreliable, and self-evaluation is reliably lenient. The system must decide what is good without depending on a single model's opinion — and the frontier has evolved the gate into an iterative critic (F1) with hands (F5).

Discussion

The verdict problem is where the "system, not the agent" framing is most visible: self-evaluation is reliably lenient — "agents tend to respond by confidently praising the work" — so the system must not depend on a single model's opinion. The pattern makes verification statistical: independent judgments aggregated by code, and the honest limit is that agreement measures preference, not correctness. The frontier evolves the gate into a critic with agency (F1) and hands (F5), both at an honest price; the committee without an aggregation rule is an infinite loop with a nicer name.

Key Insight

Agreement is a signal, not a ground truth. Independence is the whole game — correlated members vote as one and add nothing — and termination is the difference between a debate and a decision. The ensemble replaces self-review with cross-review, and it is never a ground truth.

References

LMArena (lmarena.ai); AutoGen (arXiv:2308.08155); Anthropic, Harness design for long-running application development (post); archive: verifiers-are-king, mob programming remastered.

Problem 14 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Blackboard Pattern · Next: Voting / Consensual Ensemble Pattern.

The Problem — Keeping linear flows linear

Some flows are genuinely linear — classify, transform, emit — and the simplest verifiable shape is the right one. There is no named anti-pattern; its failure mode — forcing non-linear flows into pipelines — is in the tradeoffs.

Discussion

The pipeline is the disciplined baseline for genuinely linear flows: each hop has one job and a deterministic contract, which makes the system verifiable, replayable, and billable. The boundary is the pattern's own warning: chains are right when the flow is linear, wrong when it needs to branch or recover — forcing non-linear flows into a rigid shape pays the costs (no rerouting, serialization, poisoned stages) without the benefits.

Key Insight

Linear flows deserve linear shapes. The pipeline is the disciplined baseline — and its boundary is explicit: it is the default for the flows that are already linear, not for everything. When the flow needs to branch, loop, or recover, an orchestrator or a graph wins.

References

LangChain chains (docs); Anthropic, Building Effective Agents (post); archive: Agentic-First CLI, Loop Engineering.

Problem 13 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Orchestrator-Worker Pattern · Next: Sequential Pipeline Routing Pattern.

The Problem — Coordinating through shared state without corruption

Multiple agents need a shared working memory, and unsynchronized writes corrupt it. The board must be shared and safe at once.

Discussion

The blackboard is choreography made concrete — shared state with no orchestrator. Shared state is shared risk: the board concentrates races, and its durability decides whether corruption is recoverable, which is why snapshots (P7) compose with it. The fix is the durable-daemons discipline: "no RPC. No message bus. No central orchestrator" is only safe when the shared state itself is the coordination mechanism, and the coordination mechanism must be transactional.

Key Insight

Shared state is shared risk. Choreography without an orchestrator requires transactional ownership — writes through a single ordered log, exactly-once, idempotency keys — and the ownership question, which state is shared and who owns the boundary, is the least-solved governance problem in the catalog.

References

CrewAI Flows (docs); Temporal (docs); archive: durable daemons series, Buzz and the Identity Problem, always-on agents.

Law 12 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: The Bitter Lesson.

The Law

All non-trivial abstractions, to some degree, are leaky. (Joel Spolsky, via hacker-laws)

The Key Insight for Agentic Software Engineering

The agent lives on a stack of abstractions, and every one of them leaks: tool calling is an abstraction over the model's output format, and it leaks when the format changes; structured output is an abstraction over the model's ability to follow a schema, and it leaks when the schema is wrong; the context window is an abstraction over the model's attention, and it leaks in the middle (Lost in the Middle); "the model understood the task" is the deepest abstraction of all, and it leaks exactly when the model misunderstood. Spolsky's warning applies with a new twist: the user of the abstraction is also the thing that leaks. The agent cannot see the leak — it cannot tell the difference between a tool that failed and a tool that succeeded, which is precisely the silent crash anti-pattern: the abstraction returns "" or "ok" and the agent confidently proceeds on a false premise.

The consequence is that the harness is the leak-detection layer, and the verifier is the leak detector. Every abstraction boundary in the agent's stack needs a check on the far side of it: the schema boundary needs enforcement with feedback (the model is still in the loop to fix what leaked); the tool boundary needs the gatekeeper and legible exit codes (the three channels exist so failures are visible); the outcome boundary needs the evaluator with hands that uses the artifact instead of trusting the abstraction. The agentic-first CLI discipline is Leaky Abstractions in contract form: make the leak visible in the interface, because the agent will not see it otherwise.

The ASE reading of the Law of Leaky Abstractions: agent abstractions leak — and the leak layer is where the harness must put the verifier, because the model cannot see the leak. Each abstraction saves the agent from the underlying complexity until the day the complexity breaks through, and on that day the agent — unlike a human — has no prior experience of the underlying system to draw on. The harness is the one component that can be told about all the layers at once, so it is the one that must watch the seams.

References

• dwmkerr. hacker-laws — The Law of Leaky Abstractions; Spolsky, The Law of Leaky Abstractions (2002).
• Liu et al., Lost in the Middle — the context abstraction leaking in the middle.
• This blog's Harnessing Agentic AI Systems series — schema enforcement & self-correction, static intercepting gatekeeper, voting / consensual ensemble.
• Agentic-First CLI — the interface as the visible contract.

Problem 12 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Dynamic Tool Discovery Pattern · Next: Blackboard Pattern.

The Problem — Dividing a workflow across agents

No single context can hold a whole workflow. The work must be divided, delegated, and handed off — and the frontier has added the contract that makes delegation safe (F2).

Discussion

Delegation is how a system outgrows one context window: the orchestrator curates a delegation tree instead of drowning in context. The single point of failure is the orchestrator — the spec must stay high-level because errors cascade downstream, and termination must be a system property, not the conversation's. The god agent fails by construction; F2 makes each delegation safe by negotiating "done" before the work exists.

Key Insight

No single context can hold a workflow. Delegation is how systems scale, the spec must stay high-level because errors cascade, and termination is a system property, not a conversation's. One window holding every phase degrades exactly as the middle fills.

References

AutoGen (arXiv:2308.08155); CrewAI crews (docs); Anthropic, Harness design for long-running application development (post); archive: DeepSeek teardown, harness canon.

Law 11 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Chesterton's Fence · Next: The Law of Leaky Abstractions.

The Law

The biggest lesson that can be read from 70 years of AI research is that general methods that leverage computation are ultimately the most effective, and by a large margin. (Richard S. Sutton, via hacker-laws)

The Key Insight for Agentic Software Engineering

The Bitter Lesson was written about model research: hand-crafted features lose to scaled general methods. It applies with equal force to harness research, and the evidence is already in this blog's archive. The closed loop — trajectories in, trained model out — beats the hand-tuned prompt: a 350M-parameter specialist fine-tuned on tool-calling trajectories beat ChatGPT on ToolBench by 51 points, because the general method (distillation at scale) out-leveraged the bespoke reasoning of a frontier model. Meta-Harness reached 76.4% on Terminal-Bench 2.0 and "was itself discovered through automated harness evolution" — the general method of searching the harness space beat every hand-designed harness (DeepSeek teardown). Sutton's lesson, applied to ASE: the loop that feeds trajectories back into training beats the prompt you spent a week writing.

The second half of the law is the part nobody wants to hear: the agent will apply the same lesson to your harness. An agent optimizing a benchmark will find the general solution you did not hand-craft — it will game the metric, exploit the interface, take the shortcut — because general search over the solution space beats the specific behavior you tried to engineer (this is Goodhart's Law at machine speed, Law 5). The bitter lesson cuts both ways: computation beats your hand-crafted prompt, and the agent's computation beats your hand-crafted constraints.

The ASE reading of the Bitter Lesson: the loop that leverages computation beats the hand-crafted prompt — and the agent will apply the same lesson to your harness. Invest in the general machinery — the eval, the loop, the training signal — not the bespoke prompt; and design the eval as if the agent's general search will find the crack, because it will. The bitter lesson is not an argument for less care in harness design; it is an argument for putting the care where the computation can amplify it.

References

• dwmkerr. hacker-laws — The Bitter Lesson; Sutton, The Bitter Lesson (2019).
• Agents Aren't Magic. They're Distillation at Scale. — the 350M result; the closed loop.
• DeepSeek Harness: Everything Is a Plugin — Meta-Harness found by automated evolution; harness-level improvements without training.
• Goodhart's Law — the agent's general search finds the crack in your metric.

Problem 11 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Mock Tool Virtualization Pattern · Next: Orchestrator-Worker Pattern.

The Problem — Discovering capabilities without bloating the prompt

Tool spaces grow, and static lists bloat the prompt and confuse selection. Capabilities must be discoverable — and the frontier has standardized the discovery seam itself (F4).

Discussion

The registry is the capability seam made discoverable: many tools behind small prompts, with the type-graph mirror keeping specs from drifting. The two boundaries are the interesting parts: discovery is not authorization (the gatekeeper still decides), and the tool list must not reorder, or the cache prefix dies — the registry and the bill are the same seam. The anti-pattern is the registry without curation: with the same model, a minimal, well-designed interface more than doubled state-of-the-art (SWE-agent).

Key Insight

Discovery is not authorization. Many tools behind small prompts, specs that cannot drift, a tool list that never reorders — and the gatekeeper still decides what the registry surfaced may do. The model should learn which tool; the system should not trust it with all tools.

References

Toolformer (arXiv:2302.04761); Model Context Protocol (architecture); Agent Client Protocol (agentclientprotocol.com); AGENTS.md (agents.md); archive: DeepSeek teardown, Agentic-First CLI.

Law 10 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Parkinson's Law · Next: The Bitter Lesson.

The Law

Reforms should not be made until the reasoning behind the existing state of affairs is understood. (hacker-laws)

The Key Insight for Agentic Software Engineering

Chesterton's Fence is the law every agent violates on its first pass: it comes across a fence — a function that looks redundant, a workaround that looks wrong, a test that looks pointless — and removes it, because the agent has no memory of why the fence was built and no patience to find out. The unrequested feature that cost Fowler's team three days of investigation is the mild form (Verification Is the Bottleneck); the removed workaround that was load-bearing is the severe form. "Each line of a program was originally written by someone for some reason" — and in an agentic system, the someone is often an earlier run of the same agent, which makes the fence rule both more important and harder: the reasoning may exist only in a session log.

The law is why legacy modernization is the clearest near-term value pool for agents, and why it is also the sharpest test of the harness: an agent told to "clean up this legacy code" is a fence-removal machine. The fix is not a better prompt ("understand before you change" is exactly the kind of instruction an agent will be told to ignore or will comply with shallowly); it is a harness rule — the verifier must check intent, not just correctness. Fowler's DSL idea is the constructive form: restrict the agent's change vocabulary until removing a fence requires explaining it first (Verification Is the Bottleneck).

The ASE reading of Chesterton's Fence: the harness must make the agent find out why the code is there before letting it change — intent is a verification problem. The fence rule cannot be a line in the system prompt; it has to be a gate in the pipeline: the agent must produce the fence's purpose as an artifact, and the verifier must check that artifact against the change. The mayor's answer to the man applies verbatim to the agent: "If you don't know its purpose, I certainly won't let you remove it. Go and find out the use of it, and then I may let you destroy it."

References

• dwmkerr. hacker-laws — Chesterton's Fence and Wikipedia.
• Verification Is the Bottleneck — the unrequested feature; the DSL as the restricted change vocabulary.
• The Factory Is Not Dead — legacy modernization as the agentic value pool.
• This blog's Harnessing Agentic AI Systems series — static intercepting gatekeeper, verifiers are king.

Problem 10 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Asynchronous Tool Worker Queue Pattern · Next: Dynamic Tool Discovery Pattern.

The Problem — Making the fast loop repeatable

Real APIs are slow, flaky, and costly; the system needs deterministic replay at scale. There is no named anti-pattern; its failure mode — the mock that drifts from production — is in the tradeoffs.

Discussion

Mocks are how the fast loop gets deterministic replay at the sample sizes data-driven design demands — "a single run is a data point; a thousand runs is a distribution." The honesty rule is the whole pattern: a drifting cassette teaches the wrong lessons, and the final gate must always be real. F5's live environment is this pattern's slow-loop counterpart.

Key Insight

The fast loop needs frozen reality. Deterministic replay is the enabling condition for measurement — a harness that cannot reproduce a run cannot measure a change — and the honesty rule is: mock for the unit test, record for the integration test, real for the eval.

References

VCR.py (docs); archive: harness canon, Agents Are Too Stochastic for Intuition.

Law 9 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Kernighan's Law · Next: Chesterton's Fence.

The Law

Work expands so as to fill the time available for its completion. (hacker-laws)

The Key Insight for Agentic Software Engineering

Parkinson's Law described bureaucracies; agentic software engineering gives it a meter. An agent does not have a deadline, it has a context window and a token budget — and its work expands to fill both. Give an agent a vague task and a large window and it will produce a large result: more features it wasn't asked for, more refactoring it wasn't asked to do, more files touched than the task required. The unrequested feature that cost Fowler's team three days of investigation is Parkinson's Law with teeth (Verification Is the Bottleneck): the work expanded to fill the scope the agent inferred, and nobody had bounded the scope.

The law has a second, economic face. Work expands to fill the budget — and the budget is metered. This is the token economics argument in one sentence: an agent given an uncapped budget will spend it, because "the employee's rational strategy is to maximize usage — to tokenmaxx" — and the employee is now a loop that never gets tired. Parkinson's Law is why the budget throttler and the infinite execution vortex are the same pattern's two sides: without a ceiling, the work expands without bound; with a ceiling, the work expands to the ceiling and stops.

The fix is the discipline the pattern language keeps naming: the scope is a contract agreed before the work — the sprint contract that defines "done" before the agent starts, and the tasks-that-fight-back principle that keeps tasks small enough to score. Parkinson's Law is not defeated by asking the agent to be brief; it is defeated by making the container small.

The ASE reading of Parkinson's Law: agent work expands to fill the budget — the budget is the discipline, and the scope is a contract agreed before the work. The deadline is not a time; it is a context window, a token ceiling, and a definition of done. Make the container small and the work will fit it.

References

• dwmkerr. hacker-laws — Parkinson's Law and Wikipedia.
• Every Token Has a Price Tag — the meter; tokenmaxxing as the rational strategy.
• Verification Is the Bottleneck — the three-day unrequested feature.
• This blog's Harnessing Agentic AI Systems series — budget throttler, orchestrator-worker (sprint contracts), harness canon.

Problem 9 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Schema Enforcement & Self-Correction Pattern · Next: Mock Tool Virtualization Pattern.

The Problem — Not blocking the loop on long tools

Some tools take minutes. The loop must stay live while the work happens elsewhere, and cancellation must be a contract. There is no named anti-pattern; its failure modes — the blocking loop and the abandoned worker — are in the tradeoffs.

Discussion

The queue decouples the loop from the tool: the agent holds a tracking ID, not the worker's output, so the window stays lean and the loop stays live — the context-budgeting benefit is as important as the latency one. The cost is consistency: cancellation must be a contract ("cancellation never abandons the body"), workers must be idempotent, and the queue is infrastructure the team owns forever. Its named risk is A12: asynchrony is how races enter the system.

Key Insight

The loop must never wait on a tool. The tracking ID is the interface, cancellation is the contract, and idempotency is the price of retry — a retried task double-executes unless the worker can deduplicate.

References

Celery (docs); archive: DeepSeek teardown, durable daemons execution.

Law 8 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Hofstadter's Law · Next: Parkinson's Law.

The Law

Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. (Brian Kernighan, via hacker-laws)

The Key Insight for Agentic Software Engineering

Kernighan's Law was written for human programmers; agentic software engineering makes it worse, because the writer and the debugger are different systems. The model writes the code; the model cannot debug it — an agent asked to evaluate its own work "tend[s] to respond by confidently praising the work" (Anthropic's harness) — so the debugging burden falls on the system: the verifiers, the tests, the reviewers, and eventually the humans. This is the same finding Fowler's retreat made the headline of the agentic era: "code generation is no longer the bottleneck — verification is" (Verification Is the Bottleneck). Kernighan's Law names why: the generation half is now nearly free, so the debugging half — always twice as hard — is where all the cost went.

The law's prescription survives verbatim: don't let the agent write clever code. If the agent produces the most intricate solution it can, the system — which must debug it — is "by definition, not smart enough." The harness-level translation is the whole boring-output discipline: schema-enforced, conventional, simple output that the verifier can actually check; and the verifier must be built to be the smarter half — the evaluator with hands that uses the artifact instead of reading it, the ensembles that cross-check instead of self-praise. The 79% self-review datum from the mob post is Kernighan's Law in review form: most agent PRs were reviewed by the same developer who prompted the agent — the writer debugging its own work, which the law says is impossible (mob programming remastered).

The ASE reading of Kernighan's Law: if the agent writes clever code, the system must debug it — keep agent output boring and make the verifier the smarter half. The model generates; the harness verifies; and the division is structural, because the writer can never be trusted to debug what it wrote.

References

• dwmkerr. hacker-laws — Kernighan's Law; Kernighan & Plauger, The Elements of Programming Style.
• Verification Is the Bottleneck and In the Land of AI Agents, the Verifiers Are King.
• Zuill's Mob Programming, Remastered — the self-review problem.
• This blog's Harnessing Agentic AI Systems series — schema enforcement & self-correction, voting / consensual ensemble.

Problem 8 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: State Snapshot & Rollback Pattern · Next: Asynchronous Tool Worker Queue Pattern.

The Problem — Typing tool output and keeping errors legible

Model output is text; tools and downstream systems need types. Malformed values fail far from their cause, and swallowed errors become hallucinated successes. The boundary must be typed, and failures must stay legible.

Discussion

The schema is the grammar of the contract: output is converted from text to structure at the boundary where the model is still in the loop to fix it, and the correction is an append, not a rewrite (DeepSeek teardown). The two anti-patterns are the boundary's two failure directions — the silent crash hides the error (a hallucinated success), and the free-for-all defers parsing until no model is present to correct it. Both are fixed by enforcement at the boundary with legible feedback.

Key Insight

The schema is the grammar of the contract. Malformed output is fixed while the model is still in the loop, the retry budget is part of the pattern (unbounded self-correction is the schema version of the vortex), and swallowed errors become hallucinated successes.

References

Instructor (docs, retry logic); Pydantic (docs); archive: Agentic-First CLI, harness canon, DeepSeek teardown.

Law 7 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Hyrum's Law · Next: Kernighan's Law.

The Law

It always takes longer than you expect, even when you take into account Hofstadter's Law. (Douglas Hofstadter, via hacker-laws)

The Key Insight for Agentic Software Engineering

Hofstadter's Law is about estimation, and agentic software engineering is the first discipline where the "it" being estimated is a loop you cannot see the end of. An agent run is not a task with a duration; it is a loop that keeps deciding to continue — and every continuation invalidates the estimate. The law's recursive form is the literal description of an agentic pipeline: the task takes longer than you expect, and when you account for the agent's tendency to loop, it takes longer than that. This is why the budget throttler exists: when the estimate is structurally unreliable, the ceiling must be structural too. "It always takes longer than you expect" is not a problem to be solved by better estimation; it is a constraint to be bounded by design.

The recursion has two named components. First, the infinite execution vortex: an agent retrying a broken step is Hofstadter's Law with a bug — every retry re-estimates, and the estimate never converges. Second, context anxiety: models begin wrapping up prematurely as they approach their perceived context limit, so the run ends early with work unfinished — the estimate was wrong in the other direction, but the fix is the same: the system must decide when the work is done, never the loop (termination as a system property).

The ASE reading of Hofstadter's Law: an agent task always takes longer than you expect, recursively — so the ceiling is a system property, not an estimate. Every agent pipeline needs the structural equivalent of the sprint contract: "done" defined before the work, a budget that ends the loop, and a verifier that decides when the output is good enough. The estimate is for planning; the ceiling is for survival.

References

• dwmkerr. hacker-laws — Hofstadter's Law and Wikipedia.
• This blog's Harnessing Agentic AI Systems series — token & time budget throttler, rolling window compression (context anxiety), voting / consensual ensemble (termination).
• Every Token Has a Price Tag — the bill as the real timeline.

Problem 7 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Semantic Memory Router Pattern · Next: Schema Enforcement & Self-Correction Pattern.

The Problem — Making state survive and giving it homes

State must survive crashes and error loops, and different state types need different lifetimes. The system must remember across turns, crashes, and sessions — the survival half (P7) and the organization half (P8) are two patterns for one problem.

Discussion

Remembering has two halves: surviving (P7) and organizing (P8). Recovery is promised exactly as wide as the system reifies — a snapshot of the conversation does not capture the world, which is why external effects need idempotency keys and why removal still has to be invoked (spatiotemporal composability). Tiers give state homes, and forgetting across all tiers is the least-solved stage of the state lifecycle (always-on agents).

Key Insight

Recovery is promised exactly as wide as the system reifies. The snapshot covers the conversation; the world needs idempotency keys; and remembering without forgetting is not governance. A stateless loop is a request-response function with a longer prompt.

References

Temporal (docs); Lilian Weng, LLM Powered Autonomous Agents (post); LangGraph memory (docs); archive: durable daemons series, always-on agents, spatiotemporal composability.

Law 6 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Goodhart's Law · Next: Hofstadter's Law.

The Law

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviours of your system will be depended on by somebody. (Hyrum Wright, via hacker-laws)

The Key Insight for Agentic Software Engineering

Hyrum's Law assumed human users who squint, scroll, and improvise. The agent is a user who never blinks: it reads every byte of help text, every line of output, every exit code, every timestamp, every ordering — and it depends on all of it, because it has no tolerance for ambiguity and no memory of what "should have worked." The agentic-first CLI discipline is Hyrum's Law taken as a design contract: "a lie in help text is the most expensive bug an agentic CLI can have," and "no timestamps unless asked" is not a preference but a dependency hazard — the agent will start parsing the timestamp and break when it changes format.

The law sharpens in two directions. First, the model-facing interfaces: the tool schemas, the --json outputs, the structured contracts the agent reads — every observable behaviour, including the ones you did not promise, becomes part of the de facto API. The type-graph mirror exists precisely because spec drift is a Hyrum's Law failure: the tool catalogue that drifts from the implementation is an implicit interface that somebody — some agent — will depend on. Second, the model itself becomes an interface others depend on: once agents are built on a model's observable behaviours (its tool-calling format, its refusal patterns, its output ordering), those behaviours are frozen by the ecosystem the way an API is frozen by its users — which is why compatibility-breaking changes in a harness's session format are so expensive (DeepSeek teardown).

The ASE reading of Hyrum's Law: the agent will depend on every observable behaviour you didn't promise — for agents, the implicit interface IS the contract. The defense is to make the promised contract exhaustive: stable, versioned, additive --json schemas; deterministic ordering; explicit exit-code semantics; and honest --help. You cannot stop agents from depending on your behaviour, but you can decide which behaviour they depend on. Hyrum's Law does not say the contract is meaningless — it says the contract must cover everything observable.

References

• dwmkerr. hacker-laws — Hyrum's Law and Hyrum's Law.
• Agentic-First CLI — the agent as the user who never blinks; the contract as the architecture.
• DeepSeek Harness: Everything Is a Plugin — the type-graph mirror; session-format compatibility as a Hyrum constraint.
• This blog's Harnessing Agentic AI Systems series — schema enforcement & self-correction.

Problem 6 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Rolling Window Compression Pattern · Next: State Snapshot & Rollback Pattern.

The Problem — Choosing what context to inject

Not every retrieved fact belongs in every prompt. Retrieval without judgment drowns the instruction — and every injected chunk is untrusted input. The system must decide, and the decision cannot be the model's.

Discussion

The router is the decision layer RAG was missing: not every retrieved fact belongs in every prompt, and the decision cannot be the model's because the model cannot see what it was not shown. The mechanism is curation — chunking, metadata filtering, reranking — and the security corollary is that retrieved content is untrusted input: the router is both the grounding layer and the injection surface.

Key Insight

The system curates what the model sees. Injected context is the highest-leverage observation and the highest-leverage attack — retrieval quality is a decision, not a volume, and the decision cannot be the model's.

References

Pinecone RAG guide (learn) and advanced RAG (learn); OWASP Top 10 — LLM08 (2025); Liu et al., Lost in the Middle (arXiv:2307.03172); archive: Agentic-First CLI, always-on agents.

Law 5 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Gall's Law · Next: Hyrum's Law.

The Law

When a measure becomes a target, it ceases to be a good measure. (Marilyn Strathern, via hacker-laws)

The Key Insight for Agentic Software Engineering

Goodhart's Law was always true; agentic software engineering makes it a training signal. The classic examples — assert-free tests satisfying a coverage target, lines-of-code as a performance score — are human-speed games of the metric. An agent games the metric at machine speed, and worse: the closed loop bakes the gaming in. The DeepSeek minimal preset ships the RL composition as a product option because "the harness produces the trajectories; the trajectories feed post-training" (DeepSeek teardown) — which means whatever the harness measures becomes not merely a target but the curriculum. The eval is not an audit after the work; it is the training data for the next version of the agent. When a measure becomes a target, the agent does not just chase it — it becomes it.

The consequence is that benchmark design is now model design, and the benchmarks are already leaking. Terminal-Bench and SWE-bench measure task completion, and the harnesses that score well are the ones being distilled into the next models (data-driven design); a metric that rewards short tool lists produces agents that under-tool; a metric that rewards solving quickly produces agents that skip verification. The harness canon's own warning is Goodhart's Law in agentic dress: "if every test can be passed by pattern-matching the prompt, you are not measuring the assistant — you are measuring prompt luck" (harness canon).

The ASE reading of Goodhart's Law: for agents, the measure becomes the training target — choose evals as if the agent will learn to game them, because it will. The defense is the same one the pattern language gives for the voting ensemble: measure outcomes, not proxies; make the metric what you actually want, because the loop will optimize exactly that and nothing else. "The tasks are not only an evaluation — they are the training data, which is the strongest argument for getting them right and the strongest warning against letting them drift."

References

• dwmkerr. hacker-laws — Goodhart's Law and Wikipedia.
• Agents Aren't Magic. They're Distillation at Scale. — the closed loop that bakes the metric in.
• DeepSeek Harness: Everything Is a Plugin — the training environment as product; the eval as curriculum.
• Agents Are Too Stochastic for Intuition and Harness Engineering: Best Practices.
• This blog's Harnessing Agentic AI Systems series — voting / consensual ensemble.

Problem 5 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Token & Time Budget Throttler Pattern · Next: Semantic Memory Router Pattern.

The Problem — Keeping a long session in a lean window

Context is finite and conversation is not; raw dumps degrade reasoning. The frontier has split the answer into three: compression (P5), resets (F3), and the umbrella discipline of context engineering (F6).

Discussion

The memory problem contains the catalog's most honest war: the append-only log says the past is immutable, compression rewrites it as a projection, tiers store it in parallel — the resolution is layering, and the compaction prefix bug is what happens when the layers touch. The boundary is context anxiety: compaction preserves continuity but not a clean slate, and whether you need resets is a function of the model generation. F6 is the umbrella coordinating all three answers against the cache prefix and the governance gap.

Key Insight

The past is immutable and the view is derived. Compression is a projection over the log — if the summarizer rewrites history, the past becomes negotiable and the cache prefix dies. Context anxiety is a model property the system must adapt to; the harness is coupled to the model's psychology, and must be re-examined every time the model changes.

References

MemGPT (arXiv:2310.08560); Liu et al., Lost in the Middle (arXiv:2307.03172); Anthropic, Effective context engineering (post); Anthropic, Harness design for long-running applications (post); archive: DeepSeek teardown.

Law 4 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Amdahl's Law · Next: Goodhart's Law.

The Law

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. (John Gall, via hacker-laws)

The Key Insight for Agentic Software Engineering

Gall's Law is the anti-pattern catalogue in one paragraph. The god agent — the one massive agent with an immense prompt managing every phase of a workflow — is precisely the "complex system designed from scratch": every tool, every rule, every stage in one context window, assembled in one go and expected to work. It never does, and "cannot be patched up to make it work. You have to start over with a working simple system." The working simple system is the single loop — read, act, verify, reflect — and the evolution is the harness pattern language: from the sequential pipeline (linear, boring, working) you grow the orchestrator-worker (delegation added when the context overflows), and from that the ensembles and evaluators (verification added when the failures demand it). Each step is a small change to a system that already works.

The empirical record agrees. Anthropic's own long-running harness grew exactly this way: the earlier harness was an initializer plus a coding agent working one feature at a time; the frontier version added a planner and an evaluator, one at a time, each addressing a specific observed gap (Harness design for long-running application development). The most successful guidance in the field is Gall's Law in product form: "the most successful implementations use simple, composable patterns rather than complex frameworks" (Building Effective Agents). And the blog's own self-improving loop — read lessons, do work, reflect, write lessons — is the simple system from which everything else evolves.

The ASE reading of Gall's Law: grow the agent from a working single loop; don't design the multi-agent system from scratch. When a complex agentic architecture fails, the fix is not to add more scaffolding to it — it is to start over with the smallest loop that works and let the harness evolve. The system that works was found, not designed.

References

• dwmkerr. hacker-laws — Gall's Law and Wikipedia.
• This blog's Harnessing Agentic AI Systems series — orchestrator-worker (the god agent), sequential pipeline routing, voting / consensual ensemble.
• Harness Engineering: Best Practices for Reliable Agent Systems — the simple self-improving loop.
• Anthropic. Harness design for long-running application development and Building Effective Agents.

Problem 4 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Human-in-the-Loop Breakpoint Pattern · Next: Rolling Window Compression Pattern.

The Problem — Bounding the loop

Loops can burn unbounded tokens, wall-clock, and money retrying a broken step. The ceiling must be enforced by the system, never requested of the model — the enforcement half of the Bill as Assertion.

Discussion

This problem is the economic face of the harness: it decides the shape of the bill when the model cannot be trusted to — "the caps were about the shape of the bill, not the money" (Every Token Has a Price Tag). The subtle interaction distinguishes a good throttler: it must not invalidate the warm prefix it exists to protect. And the honest limit is documented: soft enforcement is not enforcement.

Key Insight

The bill is a design decision and the ceiling is a system property. Reminders are not enforcement, and a throttler that kills its own cache prefix is the failure it was meant to prevent. Enforce in code, never in the prompt.

References

AutoGPT configuration (docs) and issue tracker (issues); OWASP Top 10 — LLM10 (2025); archive: Every Token Has a Price Tag, DeepSeek teardown.

Better Harnesses, Smaller Models (Yang, Zhao, Wu, Kästner — Carnegie Mellon, July 2026) starts from the null result every deployment engineer believes and inverts it. Swap a small model into a harness designed for a frontier LLM and it collapses; the paper shows the collapse is a harness artifact, not a model property. Adapt the harness automatically, and a 4B-parameter model matches the frontier model at a fraction of the cost.

The opening example is the whole argument. A budget-approval agent with gemini-3.1-pro hits 97.3% at $0.22 per query. Swap in gemma-4-26b-a4b unchanged and accuracy drops to 75.0%. After automated harness adaptation — a step-by-step workflow in the system prompt, a filtered tool set, and a hook that blocks the agent from sending the same message twice — the same SLM hits 98.3%, beating the frontier model at 8% of the cost. Five insights follow.

Insight 1 — The deployable unit is the model+harness pair, not the model

The "model swap" mental model — replace one model, re-validate, ship — is wrong. Across seven business tasks and three SLMs, a generic harness averages 31.4% / 26.9% / 9.5% accuracy (gemma / qwen3-coder / ministral); the optimized harnesses reach 80.2% / 74.8% / 25.0%. 16 of 21 task-model pairs improved significantly, and seven closed the SLM-LLM gap entirely — the best SLM recovering 89.7% of frontier performance at 4% of the cost, with 25% lower latency than the frontier agent.

The entanglement runs both ways. Harness adaptations don't transfer across models: ministral3-8b needs workarounds for its file-editing failures, qwen3-coder occasionally emits raw XML where the protocol demands JSON tool calls. Each model needs its own harness, so the optimization is part of every deployment and every model upgrade — the pair is the unit of deployment.

Insight 2 — Shared task difficulty is the lever, and it defines the boundary

Why does this work at all? Routine business tasks have structure shared across instances: every budget request hits the same policy lookup, the same pricing table, the same reserve accounting. A frontier LLM privately reconstructs that structure on every run, token by token, at frontier prices; an SLM reconstructs it worse. The fix is to lift the shared difficulty out of the model and into the harness — once, offline, and amortize it over every instance. The $20 one-time optimization per task is recovered after 13 production runs on average.

The same logic defines where the lever stops working:

• Repetitive tasks adapt; diverse tasks resist. Task diversity (average Levenshtein distance between tool-call sequences) correlates with optimized performance at ρ = −0.96. Controlled: going from 3 workflow templates to 20 drops accuracy from 89.1% to 68.0%. Low-entropy tasks are exactly the ones where a harness can win the fight — the quantitative version of this blog's tasks that fight back argument.
• Capable SLMs benefit more. Stronger models gain +48.8% from adaptation vs. +15.5% for the weakest — the harness offloads the repetitive parts; the model must still handle what can't be delegated.
• Harnesses can't manufacture capability. The weakest model stays at 0.0% on two of seven tasks no matter what the harness does; website-management resists at 45.6% even for the best SLM.

Insight 3 — Harness design is a search problem, not a craft

The paper's methodological bet, in the spirit of the bitter lesson: harness design should be automated as a search problem driven by data and evaluation, not manual trial and error. The optimizer is a meta-agent running an evolutionary loop over the SDK's design space — system prompts, skills, tools, hooks, context management, sub-agents:

1. Sample and evaluate — pick a candidate GEPA-style from the Pareto front of tried harnesses; run it on a batch of training instances, logging full trajectories.
2. Diagnose and propose — the meta-agent reads trajectories plus the harness code and edits it, guided by a search memory of past proposals (so it stops re-proposing dead ends) and design-space documentation. Proposals pass a cheap sanity check with a repair loop.
3. Validate and keep — full validation-set run if the edit improved the batch; add to the pool.

The loop is cheap by design: $20 per task-model pair, three runs each — $1,260 for the entire study.

Insight 4 — The meta-agent's moves are legible

The paper maps failures to adaptations so the search isn't a black box. Failures are indexed by capability — tool-use, instruction-following, knowledge, long-context, planning — and adaptations by harness component: contexts (add or manage), tools (create or manage), agent loops (instrument or orchestrate).

The winning moves are consistent. The dominant addressed failure modes are instruction-following (81%) and knowledge (81%); the dominant strategies are adding contexts (86%), creating tools (43%), and managing tools (29%). The best anomaly-detection harness combines all three: a custom query_mock_bigquery tool that sidesteps the default tool's long-context behavior, a filter from 40+ MCP tools down to seven, and the environment's table-naming convention externalized into the system prompt.

One negative result deserves emphasis: no optimized harness successfully used sub-agents — current SLMs can't track and coordinate sub-agent work. That is a bracing counterpoint to the industry reflex that answers every SLM weakness with a multi-agent topology.

Insight 5 — Diagnosis quality is the optimizer's bottleneck

The meta-agent loop is itself a system, and its developers learned where the leverage is:

• Evidence beats summaries. Raw JSON trajectories made the meta-agent diagnose better than post-processed markdown — less human-friendly, richer evidence.
• Intelligence beats iteration count. A cheaper meta-agent afforded more search steps but produced worse harnesses; lower-quality diagnoses outweighed the extra exploration. Hand-written heuristics (successful frontier trajectories, manual failure→fix maps) didn't help at all — given faithful evidence and an editable harness, the meta-agent infers repairs on its own.
• Explore diverse regions, not one long trajectory. Search memory prevents rediscovering the same fixes; several independent short searches beat one long search.

What this means

The decision rule for practitioners is clean: for repetitive business workflows where the frontier-token bill is the constraint, take the best cheap MoE SLM you can find, spend a few dozen dollars on automated harness search, and expect to recover most of the frontier model's accuracy at ~5% of the cost — provided you treat "re-optimize the harness" as a normal part of every model upgrade.

Economically, this is a distillation story. A frontier meta-agent spends $20 once, compresses the shared structure of a task into a harness, and every subsequent run of the cheap model executes that structure nearly free — the expensive intelligence is amortized away, the same economics as agents as distillation at scale. The cheap agent is not a model you buy; it is a system you build. The harness is the product — and as the next post shows, it is now a product you can build on top of: the OpenHands SDK is the substrate this optimizer searched, and the harness is the product.

The OpenHands Software Agent SDK (Wang et al., MLSys 2026) is a rare thing in the agent literature: an architecture paper that ships. It documents the redesign of the most popular open-source software-engineering agent — OpenHands, 64k+ GitHub stars in 18 months — into a modular SDK, and defends it with production telemetry: 61% fewer system-attributable failures in a 15-day live comparison, and state-of-the-art results on 3 of 5 benchmarks. Repos: software-agent-sdk, benchmarks.

It is also the substrate this blog wrote about yesterday: the harness optimizer in "Better Harnesses, Smaller Models" searches this SDK's design space — system prompts, tools, hooks, context management, sub-agents. The SDK paper explains why that space was searchable at all. A complete agent runs in six lines:

from openhands.sdk import LLM, Conversation
from openhands.tools.preset.default import get_default_agent
llm = LLM(model="openhands/claude-sonnet-4-5-20250929", api_key="...")
agent = get_default_agent(llm=llm)
conversation = Conversation(agent=agent, workspace="/path/to/project")
conversation.send_message("Write 3 facts about this project into FACTS.txt.")
conversation.run()

Insight 1 — The redesign is the story: four principles from V0's debt

The SDK is not a greenfield design; it is the answer to four failures of the original monolithic OpenHands (V0):

Each choice has a rejected alternative, stated honestly: event sourcing beat a database-backed model because a DB couples the SDK to a storage backend and breaks offline replay; optional isolation beat both mandatory containerization (V0's fragility) and fully-local-only execution (production needs safety).

Insight 2 — Event-sourced state is the consensus spine

The centerpiece is the state model. Every component (Agent, Tool, LLM) is an immutable, validated, serializable Pydantic model; all mutable variables live in ConversationState, which records interactions in an append-only EventLog. Events are two-tiered: LLM-convertible ones (messages, tool calls, observations, system prompts) are what the model sees; internal ones (CondensationRequest, PauseEvent, state updates) are pure bookkeeping. Persistence is dual-path — metadata in state.json, events as individual JSON files — so resuming a conversation means loading the file and replaying the log, with automatic detection of incomplete conversations.

The overhead objection is empirically dead: replaying 39,870 events from 433 real SWE-Bench conversations, persistence costs 0.20 ms median per event, full state replay 4.1 ms, crash recovery 7.4 ms (32.1 ms worst case). Against LLM round-trips of 1–30 s, event sourcing is free.

This is the third independent convergence this blog has covered on the same spine: DeepSeek Harness's enforced append-only session log, the spatiotemporal-composability calculus, and now OpenHands V1. Durable facts on a log, state as a pure derivation — that is the consensus architecture of the agent harness.

Insight 3 — Local-first beats sandbox-first

V0's mandatory sandboxing wasn't just awkward; in production it was the dominant source of failure. The conversation manager and execution runtime talked over inter-pod HTTP, and the 15-day V0/V1 rollout shows what that bought: HTTPStatusError 401s at 43.0 per 1k conversations, runtime-not-ready races at 18.8 per 1k, connection timeouts at 3.1 per 1k. V1 runs the agent and tools co-located by default, which eliminated the entire infrastructure-error class (69.8 → 0.0 per 1k) and cut system-attributable failures 61% (78.0 → 30.0 per 1k). The architecture removed a failure class structurally instead of patching its symptoms.

The same principle drives the deployment story. Conversation is a factory: give it a path or LocalWorkspace and you get an in-process loop with pause/resume (perfect for notebooks and debugging); give it a RemoteWorkspace and the same code serializes the agent config and delegates execution to an agent server over REST/WebSocket. Prototype to production is a two-line diff:

+from openhands.workspace import DockerWorkspace
+with DockerWorkspace(...) as workspace:
+    conversation = Conversation(agent=agent, workspace=workspace)
+    conversation.send_message("Create hello.py")
+    conversation.run()

Insight 4 — Serializability is the composability engine

The tool system runs on an Action–Execution–Observation contract: LLM tool calls validate into typed Action schemas before execution; ToolExecutor runs them; Observation structures results for the model. MCP tools are first-class — their schemas translate automatically into the same contract, so external servers behave identically to native tools.

The key move is the tool registry: Python executors aren't serializable, so tools travel across process and network boundaries as lightweight JSON specs, reconstructed lazily at runtime. That single mechanism is what makes distributed architectures and editable harnesses possible — specs can be composed, swapped, and searched. It is exactly why the harness optimizer could treat harnesses as a searchable space: a harness is just a composition of serializable specs.

Insight 5 — Security belongs inside the loop

The SDK treats safety as a control-loop component, not an afterthought, with two abstractions: SecurityAnalyzer, which rates each tool call low/medium/high/unknown risk, and ConfirmationPolicy, which decides when approval is required — pausing the agent in a WAITING FOR CONFIRMATION state until a human responds. Because assessment is separated from enforcement, trust can adapt mid-session (relax restrictions for read-only grep) and custom analyzers slot in without touching tool executors. SecretRegistry completes the picture: late-bound secrets fetched only at execution time, masked as <secret-hidden> in any output, rotatable mid-conversation.

These are precisely the features absent from the paper's comparison of the OpenAI, Claude, Google, and LangChain SDKs: the security analyzer, confirmation policies, secret auto-masking, and agent stuck detection are OpenHands-unique.

Insight 6 — The harness is the product (and the numbers back it)

Everything else follows the same logic. The LLM layer reaches 100+ providers, consumes native extended-thinking fields, and supports non-function-calling models via a text-prompt fallback — widening the usable model pool; RouterLLM lets routing policy (images to a multimodal model, text to a cheap one) live in a method, making the harness a cost-engineering surface. The Condenser halves API cost with no degradation by summarizing overflow.

The redesign's capability claims hold up: matched models score an identical 68.0% on SWE-Bench Verified across V0 and V1 (parity — the redesign didn't hurt), while Sonnet 4.5 gains +8.2 points on V1 thanks to extended-thinking support the event-sourced architecture absorbed naturally. Across 14 models and five task categories, the SDK hits SOTA on 3 of 5 — Commit0 at 56.2% vs. published SOTA 12.5%, GAIA at 80.0% vs. 74.6%, SWE-Bench Multimodal at 44.1% — using a single model per evaluation where several SOTA systems use multi-model orchestration. A three-tier QA pipeline (mocked-LLM tests on every commit, $0.5–3 LLM tests daily, $100–1000 benchmark runs on demand) keeps the whole thing honest.

The stated limits are worth repeating: single-agent focus (multi-agent coordination is future work); and a security core that is probabilistic — LLMSecurityAnalyzer is itself a model, so the guardrail inherits the model's failure modes, exactly the leaky abstraction this blog keeps returning to.

What this means

Read as a reference architecture, the SDK codifies three bets that now look convergent across the field: event-sourced state is the spine, local-first execution is the default, and the harness is the product — everything that matters (state, tools, security, context, deployment) lives in the foundation, which is why the minimal agent is six lines and why the harness-optimization literature builds directly on it. The architecture has been validated twice over: by 61% fewer production failures on one axis, and by being the substrate the next wave of agent research searches on the other.

Law 3 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Brooks' Law · Next: Gall's Law.

The Law

Amdahl's Law is a formula which shows the potential speedup of a computational task which can be achieved by increasing the resources of a system. Normally used in parallel computing, it can predict the actual benefit of increasing the number of processors, which is limited by the parallelisability of the program. (hacker-laws)

The Key Insight for Agentic Software Engineering

Agent swarms are parallel processors, and Amdahl's Law applies to them exactly as it applied to CPUs: the speedup from adding agents is bounded by the fraction of the task that can actually be parallelised, and even a task that is 95% parallelisable caps out long before the swarm grows large. In an agentic pipeline, the parallelisable fraction is the independent work — the feature edits, the searches, the test runs that can be handed to separate workers. The serial fraction is everything that must happen in one context: the plan, the merge, the context building, and — most importantly — the verification.

The verifier is usually the serial fraction, and it is the one this blog keeps proving is the bottleneck: Fowler's retreat made it the headline — "code generation is no longer the bottleneck — verification is" (Verification Is the Bottleneck). Spawn a thousand agents to write code faster and the pipeline still drains through the single verifier that has to check it all — the Sonar AC/DC finding is the same shape: verification is where the 3-5x velocity boost rots. This is why the evaluator with hands is reserved for the final gate: it is the most valuable serial step, and running it in parallel with itself is the one thing Amdahl's Law says you cannot do.

The ASE reading of Amdahl's Law: measure the serial fraction of your agent pipeline — the verifier is usually it, and no number of workers beats the ceiling it sets. The harness-level lever is to raise the parallel fraction, not to add workers: decomposition turns one serial task into many parallel ones, mocks let independent runs proceed without waiting on shared infrastructure, and verification must be layered so the cheap checks run in parallel and only the expensive judgment is serial.

References

• dwmkerr. hacker-laws — Amdahl's Law and Wikipedia.
• Verification Is the Bottleneck and In the Land of AI Agents, the Verifiers Are King.
• This blog's Harnessing Agentic AI Systems series — orchestrator-worker, voting / consensual ensemble, mock tool virtualization.

Problem 3 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Static Intercepting Gatekeeper Pattern · Next: Token & Time Budget Throttler Pattern.

The Problem — Stopping the loop for a human

Some mutations — financial transactions, deletions, releases — must not happen without human authority. The loop must stop, persist exactly where it paused, and resume only after a person decides. There is no named anti-pattern; its failure modes — the rubber-stamp and the swallowed breakpoint — are in the tradeoffs.

Discussion

The breakpoint makes authority a resumable property of the state machine: approval is a checkpoint, not a moment, and every human decision is recorded. Its two failure modes are failures of attention — the rubber-stamp, and the swallowed breakpoint (interrupts wrapped in try/except, which LangGraph explicitly forbids). The automation path is not an exception to the pattern; it is the pattern's other half, and its discipline is P4's: the system decides what is consequential, never the model.

Key Insight

Authority is a resumable state, not a moment. Approval without review is worse than no approval, and a breakpoint that can be swallowed does not exist. The harness decides what is consequential and what is routine; the model never does.

References

LangGraph interrupts (docs); archive: OpenWorker and the Outcome Layer, DeepSeek teardown, always-on agents.

Law 2 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Previous: Conway's Law · Next: Amdahl's Law.

The Law

Adding human resources to a late software development project makes it later. (hacker-laws)

The Key Insight for Agentic Software Engineering

The first temptation when a task is late is to spawn more agents — the "nine women can't make a baby in one month" intuition gets buried under the fact that an agent costs nothing to instantiate. But Brooks' reasoning survives the change of subject completely: the ramp-up time becomes the context handoff (the new agent must learn the task, the repo, and the state — exactly the goldfish amnesia risk of delegation); the communication overhead becomes the coordination between agents (shared state, delegation contracts, merge conflicts — the orchestrator-worker single point of failure); and many tasks are not divisible, because the serial reasoning and verification fraction cannot be split.

The cost structure is what changed, and it is the trap. Spawning an agent is nearly free; integrating its output is not. A human's ramp-up is measured in days and the org pays it once; an agent's ramp-up is measured in tokens and context, but it is paid on every delegation, and a late task invites delegating more, which multiplies the handoffs precisely when the serial path is already the bottleneck. This is the Brooks → Amdahl pair: adding workers only helps the parallelisable fraction, and the late task is late because of the serial fraction.

The ASE reading of Brooks' Law: nine agents can't make a feature in one day — the handoff is the ramp-up, and the serial fraction sets the ceiling. The fix is not to spawn more workers; it is to shrink the handoff (structured artifacts, sprint contracts that define "done" before the work — the frontier contract pattern) and to make the serial fraction explicit and measured, so the decision to add an agent is made against the ceiling it cannot move.

References

• dwmkerr. hacker-laws — Brooks' Law and Wikipedia; Brooks, The Mythical Man-Month.
• Amdahl's Law — the serial fraction is the ceiling.
• This blog's Harnessing Agentic AI Systems series — orchestrator-worker, state snapshot & rollback (handoff state), asynchronous tool worker queue.

Problem 2 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Previous: Ephemeral Sandbox Wrapper Pattern · Next: Human-in-the-Loop Breakpoint Pattern.

The Problem — Refusing a tool call before it happens

The system's hands must be able to say no before anything reaches an external API — and the denial must be final: structural, not prose. Interception and authorization are the same seam.

Discussion

The gatekeeper makes denial a system property rather than a model preference: the static floor does the deterministic denial, and the model-based layer adds judgment above it, never below — the DeepSeek ordering doctrine. The anti-pattern inverts the seam: policy as prose asks the model to obey a rule it can be told to ignore, so the refactoring is never a better instruction — it is moving the check into the tool, where injection cannot reach it.

Key Insight

Denial must be structural to be final. The blocklist decides before the model can be persuaded — deny by default, allow by exception — and authorization belongs in the tool, not the prompt: who may modify the system's state is a property of the harness.

References

Meta's Llama Guard (publication); OWASP Top 10 (2025); Willison's prompt injection series (series); archive: DeepSeek teardown, Verification Is the Bottleneck, always-on agents.

Terminal Agents: A Survey of AI Agents in Command-Line Environments (Yi Bin, Xiaoyang Yuan, Haoxi Zeng, Wencheng Ye, et al., arXiv:2608.20485, 52 pages) is the first survey that treats terminal-mediated execution as an object of study in its own right, rather than scattering it across software-engineering, tool-use, and computer-use literature. It is worth a close read because it formalizes a claim this blog has been circling for months: the terminal is not an interface the agent uses, it is the substrate the agent lives in (see Agentic-First CLI Design and the canonical Harness Engineering: Best Practices for Reliable Agent Systems).

The companion repo is awesome-terminal-agents.

The scope move: substrate, not surface

The survey's organizing lens is deliberately narrow: a terminal agent is a system whose dominant progress-bearing action–observation loop is mediated by terminal command execution, textual feedback, and stateful environment interaction. Three workload-level boundary tests operationalize "dominant":

1. Primary execution substrate — command execution is the workload's main means of progress.
2. Iterative command feedback — outputs, errors, logs, diffs, return codes, or state changes materially shape later actions.
3. Terminal dependence — removing terminal access would change the workload's core behavior.

The consequences are sharp. SWE-agent is in scope; Agentless is not (static patch pipelines lack iterative execution); OSWorld is not (visual feedback is the progress-bearing substrate); a CLI-packaged assistant that forwards requests to a non-terminal workflow is not. The tests apply per-workload, not per-product — a platform can be in scope for repository repair and out of scope for its browser workloads.

This matters for harness engineers because most "terminal agents" in industry are hybrid systems, and the boundary tests tell you which parts of them deserve terminal-specific evaluation.

Seven dimensions of terminal competence

The survey's analytical backbone is a seven-dimensional competence profile. These are not model capabilities; they are system-level responsibilities distributed across the model, interface, harness, runtime, and environment:

1. Command and action formulation — translating goals into executable commands, edits, and build/test/run actions.
2. Feedback and artifact interpretation — extracting evidence from stdout, stderr, exit codes, logs, diffs, stack traces.
3. Runtime and environment management — preparing, configuring, and repairing dependencies, services, containers, remote machines.
4. State, task, and context tracking — maintaining environment state and interaction history across extended sessions.
5. Progress verification — designing checks of intermediate validity and completion conditions.
6. Recovery and adaptation — diagnosing failures, replanning, retrying from grounded evidence.
7. Governance and side-effect control — permissions, sandboxes, approvals, resource limits, destructive-action prevention.

Two features of this list are worth internalizing. First, verification (5) is separated from recovery (6), and both from governance (7) — conflating them is why so many harnesses discover that "it passed the tests" and "it did something terrible" are simultaneous truths (see Sandboxing AI Agents and Always-On Agents, which frames governing and recovering as first-class state concerns). Second, the dimensions are trace-observable in principle: planning appears as executable action sequences, memory is tested against persistent state, adaptation is grounded in external feedback. That traceability is the hook for everything that follows.

Architecture: the harness is a performance-shaping component

The survey traces four shifts in design emphasis: tool-augmented prompting (ReAct, Toolformer, CodeAct) → structured executable actions (SWE-agent's ACI primitives, OpenHands) → terminal-mediated agency as a first-class target (Terminal-Bench, CLI-Gym, Endless Terminals) → runtime- and harness-centered design (Meta-Harness, AutoHarness, Agentic Harness Engineering), where context compaction, approval rules, observation shaping, and observability-driven harness evolution are treated as first-class variables.

Responsibilities are organized into four layers: interface and observation, runtime and workspace, control/verification/recovery/governance, and harness/context. The recurring tensions:

• Expressiveness vs. recoverability — raw command access is expressive but noisy and hard to roll back; ACI mediation is reliable but narrows the task surface.
• Generality vs. task discipline — platform runtimes span heterogeneous work but give less structured feedback.
• Automation vs. inspectability — permission gates and approval checkpoints aid auditability but add latency; governance is the least systematically addressed dimension.

And the one that should shape every comparison you publish: attribution difficulty. Controlled skill injection can add substantial token overhead without improving pass rate, and Agentless shows static pipelines rivaling interactive agents on some repository-repair tasks. Gains under an optimized harness may come from context management, observation shaping, retry policy, or injected procedural knowledge — not from a better model. The complete model–harness–runtime configuration is the unit of comparison, not the model.

Acquisition: trajectories are the unit, failure is the signal

The relevant learning unit is a stateful trajectory — actions, observations, state changes, verification, recovery — not a prompt–response pair. The survey maps the acquisition levers:

• SFT on successful traces teaches common commands and workflows, but offers almost no supervision for diagnosis, rollback, or recovery after wrong assumptions.
• RL with executable rewards (Endless Terminals, ECHO, SWE-Master, SWE-Gym, Tmax) aligns behavior with completion, but sparse rewards can reinforce brittle or unsafe behavior.
• Process-aware / verifier-guided optimization supervises intermediate decisions via judgments, rankings, or hindsight validation (AgentHER is the key example — terminal failures usually appear early through stderr, failed tests, or inconsistent state).
• Failure-conditioned training (TRACE, AgentHER, AgentForesight) preserves diagnosis and recovery, but suffers noisy labels and repair-loop overfit.
• Synthetic generation broadens coverage of rare commands but risks teaching synthetic regularities; runtime memory (Memento, Context-Folding, TACO) sustains long horizons but risks persisting incorrect assumptions.

The uncomfortable finding: recoverable failures remain underrepresented. Failed installs, version conflicts, rollback decisions, and dead-end repairs are exactly the interactions needed to learn recovery — and successful-trace filtering removes them. If your training pipeline only keeps traces that worked, you are training an agent that cannot diagnose.

Evaluation: outcomes are the floor, not the ceiling

The evaluation section is the most useful part of the paper for working engineers. Benchmark families expose different things:

The evidence hierarchy goes beyond binary correctness: outcome evidence (task completion), process evidence (how execution happened), environment evidence (runtime validity), trace evidence (inspection/replay), and governance evidence (permissions, containment, side effects). Three protocol facts deserve wide circulation:

• SWE-EVO-style long-horizon decay: 65–73% on SWE-Bench Verified drops to 21–25% on multi-file evolution in its reported setting. Short tasks hide failure.
• Reward hacking is measurable: an audit reports 16% of tasks across five terminal-agent benchmarks are reward-hackable.
• Harness effects dominate: WildClawBench reports an 18-point harness-conditioned gap; SWE-rebench finds evidence consistent with contamination inflation on static tasks.

Final success alone does not reveal whether an agent preserved state, recovered from failure, verified completion, or respected execution constraints.

The survey runs its own diagnostics

Rather than stopping at synthesis, the survey contributes bounded fixed-condition experiments — and these are the most concrete part of the paper. On a fixed configuration (mini-SWE-agent + DeepSeek-V4-Flash), it computes seven trace-derived process indicators (P1–P7) across four benchmark families:

Key results: rule-matched invocation failures are rare (P1 ≈ 0.0%), local feedback use is high (76–82%), but final-window verification spans 23.8%–36.6% on three benchmarks versus 66.2% on BashArena — the same agent shows different process behavior because the benchmarks foreground different demands. The matched system comparison is even more pointed: SWE-agent wins every block, but the gap between systems ranges from at most 7.00 points on SWE-bench Lite to 21.25 points on Claw-SWE-Bench Lite, and the ordering of OpenHands and mini-SWE-agent reverses across benchmarks. Meanwhile the Flash-vs-Pro model variant never moves outcomes by more than 2.50 points. Benchmark choice changes what you can see, and system comparison without benchmark context is meaningless.

The trace cases ground the aggregates — the magsac-install case shows a dependency loop with a 38.5% environment-command non-zero-exit rate that never closes because the agent ends before an evaluator-relevant import check. Local feedback without verification and recovery leaves the loop unclosed.

type TraceIndicators struct {
	InvocationFailures  float64 // P1: rule-matched command failure rate
	FeedbackUse         float64 // P2: helpful-use among feedback episodes
	EnvironmentExits    float64 // P3: non-zero exit on env-management commands
	StateErrors         float64 // P4: consequential state errors
	FinalWindowVerify   float64 // P5: verification in final window
	Recovery            float64 // P6: task-relevant recovery success
	GovernanceTriggers  float64 // P7: irreversible/overprivileged/secret-handling actions
}

This is the closest thing the survey offers to a portable process-evaluation schema — and it is exactly the shape of instrumentation this blog argues harnesses should ship with (see Harness Engineering: Best Practices for Reliable Agent Systems).

What to take away

The survey's own conclusion is the one to steal for your evaluation practice: report system and runtime conditions explicitly, pair task outcomes with process evidence, and publish replayable traces. The four research priorities it derives — cross-domain competence, fresh and replayable process-level evaluation, runtime governability, and controlled model–harness attribution — map one-to-one onto the gaps that keep showing up in real agent deployments.

For harness engineers the operative reading is: treat the terminal as substrate, instrument the seven dimensions, keep failure traces, and never publish a model comparison without pinning the harness, the runtime, and the benchmark. This is the survey version of "tasks that fight back" — except now the tasks are graded on process, not just outcomes, and the benchmark is treated as a measurement instrument that must resist gaming, the argument made in Empirical Game Theory for Agents. If you only track resolution rates, you are measuring the flattering version of your system. (Relevant adjacent reading: DeepSeek Harness Notes and the Harness Patterns for Agentic AI Systems index.)

References

• Yi Bin, Xiaoyang Yuan, Haoxi Zeng, Wencheng Ye, Wenqi Shao, Chen Qian, Wei Ye, Yujuan Ding, Zheng Wang, Pengpeng Zeng, Jingkuan Song, Heng Tao Shen. Terminal Agents: A Survey of AI Agents in Command-Line Environments. arXiv:2608.20485, submitted 20 Aug 2026. Companion repo.
• Key benchmarks discussed: Terminal-Bench, SWE-bench, SetupBench, BashArena, LongCLI-Bench, Claw-SWE-Bench, ClawSafety.

Law 1 of 12 in the Hacker Laws for Agentic Software Engineering series — read the index. Next: Brooks' Law.

The Law

The technical boundaries of a system will reflect the structure of the organisation. (hacker-laws)

The Key Insight for Agentic Software Engineering

Conway's Law was about the org chart, and the org chart just changed: it now includes the agents, and — more importantly — the harness that wires them. In an agentic software engineering shop, the structure that shapes the software is not only who reports to whom; it is how the agents communicate, what shared state they read, which delegations are allowed, and where the verifiers sit. The software will mirror that topology, because the topology decides what each agent can see and therefore what it can build. Give two agents the same repository but different shared-state boundaries and they will produce systems with seams in different places — the seam lands where the communication seam lands.

The harness is the org chart. The orchestrator-worker topology produces central-plan, delegated-feature systems; the blackboard topology produces choreographed, shared-state systems; the sequential pipeline topology produces layered, linear systems. The model is the same in all three — the topology is what changes, and the topology is a harness decision, not a model decision (the system, not the agent).

The flip side is sharper: agents also mirror each other. The distillation loop — small models trained on a large model's outputs — makes the "organisation" a single voice, and the software it produces is correspondingly single-voiced. When the agentic org has one mind, the software has one architecture, for better and for worse; when it has many independent minds with narrow channels between them, the software is modular in exactly the places the channels are narrow.

The ASE reading of Conway's Law: the software will mirror the topology of the agents that made it, so design the topology — the harness — to get the seams you want. If you want modular systems, make the communication channels between agents narrow and the shared state explicit; if you want integrated systems, wire the agents tightly. The law was never an excuse for the org chart; it was an instruction to take the org chart seriously. In agentic software engineering, the org chart is a file you can edit.

References

• dwmkerr. hacker-laws — Conway's Law and Conway's Law on Wikipedia.
• This blog's Harnessing Agentic AI Systems series — orchestrator-worker, blackboard, sequential pipeline routing.
• Agents Aren't Magic. They're Distillation at Scale. — the single-voice organisation.

Problem 1 of 15 in the Harnessing Agentic AI Systems series — read the index for the framing. Next: Static Intercepting Gatekeeper Pattern.

The Problem — Containing untrusted execution

An agentic system executes code that is untrusted by construction — written by a model, possibly steered by injected instructions. A mistake or an attack must die with the task that produced it.

Discussion

The pattern converts trust into lifetime: the system does not need to believe the code is safe, it needs the code to die with the task — which is why teardown must be derived from the load, not remembered. The anti-pattern is containment skipped: it trusts the least trustworthy component with the most valuable secrets, because instructions are data. Where the guarantee stops: the wrapper bounds the process, not the world — which is why the gatekeeper (P2) must sit outside it.

Key Insight

Trust is a lifetime property, not a belief. The wrapper converts "is this code safe?" into "does this code die with the task?" — and a guarantee you must remember to enforce is a guarantee an agent will, at some point, not.

References

LangChain sandbox integrations (docs); OWASP Top 10 for LLM Applications (2025); Willison's prompt injection series (series); archive: Sandboxes Are Hard, DeepSeek teardown, spatiotemporal composability.

dwmkerr/hacker-laws is the best-known catalog of the laws, theorems, and principles that software engineers cite to explain why things keep going wrong. This series takes twelve of them and asks a question the catalog was never written to answer: what does each law mean when the engineer is an agentic AI system?

The law does not change; the subject does. Brooks' Law was about people — and in agentic software engineering, "human resources" can be spawned in milliseconds. Amdahl's Law was about processors — and now the processors are agents. Goodhart's Law was about KPI-gaming by employees — and now the optimizer is a model that will game the metric at machine speed. The reasoning survives the change of subject; that is exactly why the laws are worth re-reading for the agentic era, and why this blog's own catalog — the Harnessing Agentic AI Systems pattern language — keeps landing on the same conclusions the laws reached decades ago.

Each post in this series is one law, one commit, one push, and one key insight for agentic software engineering — the insight is the whole point, and the law is the evidence.

The series

1. Conway's Law — the org chart is now humans, agents, and the harness that wires them.
2. Brooks' Law — adding agents to a late task makes it later.
3. Amdahl's Law — agent parallelism is bounded by the serial fraction.
4. Gall's Law — complex agent systems evolve from simple loops.
5. Goodhart's Law — the eval is the curriculum; the metric is the target.
6. Hyrum's Law — agents depend on every observable behaviour.
7. Hofstadter's Law — agent timelines are recursive estimates.
8. Kernighan's Law — debugging agent output is the bottleneck.
9. Parkinson's Law — agent work expands to fill the budget.
10. Chesterton's Fence — understand before the agent changes anything.
11. The Bitter Lesson — compute and the loop beat the hand-crafted prompt.
12. The Law of Leaky Abstractions — every agent abstraction leaks; the verifier lives at the leak.

References

• dwmkerr. hacker-laws — the source catalog; each law post links to its own entry and the primary source.
• This blog's Harnessing Agentic AI Systems: A Pattern Language — the pattern language the laws keep landing on.
• Loop Engineering is what the NATO conference asked for in 1968 — the loop as the unit of design, which most of these laws end up constraining.

A harness is the environment an agentic AI system lives in: everything between the models and the world. It decides what the system can see, what it can do, and how the outcome is judged. This series catalogs the patterns of that layer — the recurring engineering problems every agentic system faces, the patterns that solve them, and the anti-patterns that fail them.

The series exists because the harness — not the model — is where the leverage concentrates. The evidence is in the numbers: the same model finished between 47% and 67% of real tasks across eight different harnesses while cost per finished task varied sevenfold (DeepSeek Harness teardown); the same weights score 3.4 points apart on the public Terminal-Bench board under two major harnesses; SWE-agent more than doubled the previous state-of-the-art on SWE-bench with the same GPT-4 by changing only the interface (Agentic-First CLI); and harness-level improvements have lifted scores without training. Nothing about the intelligence changed. The wrapper changed.

Why harness engineering patterns matter

The unit of design is the agentic AI system, not the agent. A harness for an AI agent is an instrument around one model — a wrapper for a single component. A harness for an agentic AI system is the entire runtime around one or many agents: the loop, the tools, the memory and state, the interfaces the agents read, the policies that constrain them, the verifiers that judge them, the orchestrators that compose them, the humans in the loop, and the evaluation and billing apparatus that closes the loop. We harness the whole system, including the agent(s). We do not care about the agent as such — not because agents do not matter, but because the agent is the one component we cannot design, and everything that can be designed is the system. Google's Agents whitepaper makes the same claim from the vendor side: the agent is "a program that extends beyond the standalone capabilities of a Generative AI model" — model, tools, and an orchestration layer. MemGPT's title is the same claim in four words: LLMs as operating systems. The agent is the hardware. The harness is the OS.

Why it is a mistake to focus on the agent:

• It misattributes failures. When an agentic system fails, the agent-focus blames the model; the system-focus asks which tool it selected, what context it was given, what interface it read, which verifier approved it. "[The model decided]" is not an audit answer — regulators and boards accept checkpointed state, provenance chains, and deterministic replay (durable daemons execution).
• It optimizes the least controllable part. The agent is the only stochastic component. Every lever you actually pull is a system lever: the interface, the memory, the tools, the policies, the verifiers.
• It ignores where improvement lives. "Agents don't learn. Every mistake an agent makes, it will make again unless the harness explicitly prevents it" (Verification Is the Bottleneck). The loop that improves is a system loop.
• It confuses a component with its properties. Identity, auditability, authority, cost, safety, and correctness are all system properties — the agent cannot answer "who did what, why, and was it correct?"; only the system can (always-on agents, Buzz).

Patterns matter because the problems recur. Every agentic system eventually has to contain untrusted execution, refuse tool calls, bound its loops, manage its context, make its state survive, type its output, discover its tools, divide its work, coordinate through shared state, and produce a verdict no single model can fake. The fifteen patterns in this series are the named, evidenced answers to those recurring problems — with the anti-patterns that fail them and the frontier patterns that are evolving them. The tradeoffs are not defects in the patterns; they are the prices. Every pattern buys a guarantee and charges a cost, and the guarantee stops where the declaration stops.

How to read this series

The series is organized by problem, not by component, in the tradition of Christopher Alexander's A Pattern Language (1977): "a set of problems and documented solutions," cross-referenced into a network. Each of the fifteen problems lives in its own post, titled Harnessing Agentic AI Systems: <Pattern> Pattern. Every post has the same shape: the problem statement, one table — rows are the fixed pattern-language fields, columns are the problem's pattern, anti-pattern, and frontier entries (the row labels pair the two vocabularies: Forces/Smell, Solution/Anti-solution, Consequences/Failure, Tradeoffs/Refactoring, Evidence, Related) — followed by a Discussion, a Key Insight, and the problem's References. Read the posts in order: the problems build — first make the system safe (1–4), then make it remember (5–7), then make it act (8–11), then make it scale (12–14), then make it trustworthy (15).

The series

References

• Alexander, C., Ishikawa, S., Silverstein, M. A Pattern Language: Towns, Buildings, Construction (Oxford University Press, 1977) — the origin of the problem-first pattern-language form.
• Gamma, Helm, Johnson, Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994) — named patterns with forces and consequences.
• Each series post carries its own full references. The evidence behind this overview is documented in the archive: DeepSeek Harness teardown, Agentic-First CLI, Verification Is the Bottleneck, durable daemons series, always-on agents, Buzz and the Identity Problem.

On July 16, 2026, xAI shipped Automations in Grok: "Describe a job once and Grok runs it on a schedule or when an email arrives, then reports back." The one-line pitch is the whole design, and it deserves a close reading, because it is the first consumer-scale productization of an idea this blog has been tracking for months. The durable daemons series specified the pattern as four conditions — persistence, stateful memory, autonomous action, crash-proof execution — with a type hierarchy: Agent ⊃ Daemon ⊃ Durable Daemon. Its most memorable sentence was about condition 3: "Condition 3 is cron with an LLM." Grok Automations is that sentence, shipped.

"jobs Grok runs on its own. Describe the work once, choose when it runs, and Grok takes it from there, whether that's research done before you're awake or an important email flagged the moment it lands."

The announcement's own language is the language of the daemon: the job is described once, the system fires it, the system reports back, and no prompt is required. That is condition 3 — trigger-driven autonomy — in the product. The rest of this post reads the announcement the way the announcement asks to be read, then weighs the design decisions with the tradeoffs this blog's pattern-language series has been cataloging.

What shipped

An automation is a stored job: instructions that "read like any chat message," optional attached files, connectors, skills, and a mode. It runs on one of two trigger families:

• Schedules — once, daily, weekdays, weekly, monthly, or yearly, "at a time you choose in your timezone": a morning brief at 8:00, a rent reminder on the 1st.
• Email triggers — the automation watches the inbox; "when an incoming email matches your filters (sender, recipient, or subject), the automation fires with that email as context, and Grok responds to the actual message."

Every run is recorded: "When an automation fires, Grok opens a real conversation, does the work, and saves the result to its run history. Open any run to read the full thread, or pick up the conversation where Grok left off." Notifications are a choice — email, app, both, or neither. Automations can be created from chat ("check the news every morning and flag anything about pricing"), from templates, or with a Run now button for testing. Scheduled automations are free to everyone; email triggers are a SuperGrok feature.

The screenshot in the announcement shows the shape of the thing: a Morning Brief with Runs 4 · Succeeded 2, one run "Generating just now," and a run history that reads like a daemon's log — "2 calendar conflicts, 4 emails worth replies," "launch-day schedule and three stories to read," "quiet inbox, one deadline moved to Friday," "flight check-in opens at noon, pack for rain." The runs are conversations, saved, resumable, and auditable. That is the always-on agent with a provenance trail.

The design decision that matters: every run is a fresh request

The most consequential sentence in the announcement is easy to miss:

"every run is a fresh request: same instructions, current data."

Each firing is a full conversation built from the stored instructions plus whatever the triggers and connectors deliver at that moment — not a continuation of the last run. This is a deliberate architecture, and it is the same tradeoff the always-on survey names as the goldfish amnesia anti-pattern: a run that remembers nothing of the previous run. Here it is chosen on purpose, and the choice is defensible.

What the fresh-request design buys: no context accumulation, which means no context avalanche — a morning brief on day 200 does not carry 199 days of history into its window. Each run is bounded, legible, and independently debuggable from run history. Failures are isolated: one bad run does not poison the next. And the instructions are a stable prefix — the same front-of-request tokens every time — which is exactly the shape a prefix-cache discipline wants, if the harness keeps the prefix warm.

What it costs: the daemon cannot remember what it learned. An automation that must "remember what happened yesterday" has to externalize that memory through connectors or skills, because the run itself starts blank. This is the state-blindness tradeoff made explicit: the platform chose fresh-context reliability over cross-run memory, and the burden of memory is pushed to the harness's storage — run history (the audit trail) rather than working memory (the daemon's brain). The durable-daemons specification called condition 2 (stateful memory) a precondition for condition 3 (autonomous action); Grok's automation has condition 3 with a deliberately shallow version of condition 2.

The trigger is the product

This is where the blog's central argument applies: the system, not the agent. Grok is the model; the automation is the system — triggers, connectors, skills, mode, notification channel, run history, templates. Every point of value in the announcement is a harness feature, not a model feature:

• Triggers are the daemon's "when": schedules are cron with timezone support, and email filters (sender, recipient, subject) are condition matching over an inbox — the event-driven choreography this blog described in durable daemons execution: "The daemon watches conditions. Fires triggers. Makes and discharges commitments. Invokes itself."
• Connectors (type @ to mention a connector, and Grok uses it on every run) are the capability seam — the tool-binding pattern as a consumer feature: the automation's reach is defined by which connectors are mounted, not by the model.
• Run history is provenance — the always-on survey's audit trail, by construction. "Open any run to read the full thread" is the answer to "who did what, why, and was it correct?" — at least for the what and the why.
• Chat-to-automation ("ask Grok to 'check the news every morning…' and it sets one up") is loop engineering inverted for the consumer: you stop prompting, and the system turns your prompt into a loop.

This is the same-model-different-harness argument from the DeepSeek teardown made product-shaped. The model is a socket; the automation system is what the user actually buys. And the announcement is explicit that the system is configurable per job — "pick a mode," "add connectors and skills," choose notifications — which is the per-session composition idea wearing consumer clothes.

The economics: describe once, run forever

"Describe once, run forever" is a billing sentence dressed as a convenience sentence. Every scheduled run is a metered event; every email trigger is a metered event that arrives without an appointment. The token economics post computed the shape of this: always-on agents are "the token burn behind the tripled bills," and the Jevons paradox means that the cheaper the unit, the more total consumption — because the resource becomes economical for uses it could never before serve. A morning brief is a use case that did not exist as a product before, because nobody was going to prompt a chatbot at 8:00 AM every day for a year. Automations exist to convert that would-be manual labor into a recurring, metered run.

The pricing split in the announcement is the honest version of the meter: schedules are free to everyone (predictable, bounded, self-selected frequency), email triggers are SuperGrok (unbounded — any email that matches is a run). The meter is the product boundary: the trigger that can fire without your involvement is the one you pay for, because its bill has no shape until it has run.

Where the guarantees stop

The announcement is a product page, and product pages end where the design's hard questions begin. Four stand out, each mapped to this blog's pattern language:

1. Email is a prompt-injection surface with teeth. The email trigger "fires with that email as context" — the email is untrusted input inserted into the instructions of a run that has connectors attached. The prompt injection threat model this blog has documented since the Zero Overhead post applies with compounding interest: the attacker does not need to compromise the platform, only to send an email that matches a filter. A blocked sender can be spoofed; a subject filter can be matched; and the run has teeth — connectors, skills, and a "respond to the actual message" instruction. The gatekeeper pattern — a blocklist between the untrusted message and the tools — is the missing piece, and the announcement does not mention one. This is the oldest lesson in the catalog, now embedded in a consumer default.

2. No visible ceiling. The announcement shows no budget, no run limit, no cost control on the automation page. Schedules are bounded by construction (you choose the frequency), but email triggers are bounded by your inbox's volume — and a misbehaving automation (or an injected one) can fire on every matching email, every hour, forever. This is the infinite execution vortex risk with a trigger instead of a loop: the same unbounded consumption, entering through a different door. The budget-throttler pattern is the fix, and its absence from the announcement is a gap, not a feature.

3. The HITL gap on consequential actions. The announcement's own examples are read-only — summarize, flag, remind. But "Grok responds to the actual message" invites the next step, and the next step after that is sending. The HITL breakpoint — a persisted pause before a consequential action — is the governance seam, and the announcement is silent on what happens when an automation's run wants to do something irreversible. The pattern-language series's authority argument applies: "who may modify the system's state is a property of the harness, not of the model's reading comprehension."

4. Fresh runs are bounded intelligence. The deliberate amnesia caps what an automation can become. The daemon that cannot remember cannot compound: its value per run is constant, not growing, unless the user externalizes memory into connectors and skills — which is exactly the governance work the always-on survey says nobody has built yet.

The screenshot's run history is the most honest detail in the announcement: Runs 4 · Succeeded 2. Half the visible runs failed, and the announcement does not say what happens then — whether failure is notified, retried, or logged. That is the boundary every agentic system must declare: the guarantee stops where the failure policy stops.

What to steal

Read the announcement the way this blog reads every harness: separate the system from the model, and the design decisions from the marketing.

What Grok Automations gets right: the trigger as a first-class harness primitive — the daemon's "when" is a configuration, not a prompt; run history as provenance by construction; the fresh-request discipline that keeps runs bounded and legible; the honest meter (predictable schedules free, unbounded email triggers paid); and the chat-to-loop flow that turns "prompt me" into "loop for me" (loop engineering, productized).

What it leaves open: the injection gatekeeper between email and the run; the budget ceiling on trigger-driven runs; the approval seam before consequential actions; and the memory story beyond run history. Each of these is a named pattern in the series with a documented tradeoff — the product has shipped the daemon half, and the governance half is still this industry's open problem.

The durable daemons definition ended with a warning and a promise: "Agency is not discovered. It is designed." Grok Automations is the first time a major consumer platform designed it at scale — describe once, run forever, report back. The design is real, the economics are real, and the guarantees stop exactly where every announcement that omits its failure policy stops: at the boundary the platform chose not to declare. Name the boundary, design within it, and verify the design works — that is the engineering method, and it is the whole pattern language in one sentence.

References

• xAI. Automations in Grok (July 16, 2026) — the primary source for this post: the announcement, the product page copy, and the screenshots quoted here.
• This blog's Harnessing Agentic AI Systems: A Pattern Language — the series index; the pattern references above point to its posts: budget throttler, gatekeeper, HITL breakpoint, state snapshot & rollback, rolling window compression, dynamic tool discovery.
• Archive: Durable Daemons — Pattern Specification ("Condition 3 is cron with an LLM") and Runtime and Implementation (event-driven choreography, exactly-once, idempotency).
• Always-On Agents: state, memory, and the governance gap — the 435-paper survey; the authority, scope, provenance, and audit axes that an automation platform inherits.
• Every Token Has a Price Tag — the Jevons arithmetic behind "describe once, run forever": the meter, the shape of the bill, the caps.
• Loop Engineering is what the NATO conference asked for in 1968 — loops over prompts; "the simulation becomes the system."
• DeepSeek Harness: Everything Is a Plugin — the harness-is-the-product evidence (same model, eight harnesses, 47%–67%; prefix caching).
• Sandboxes Are Hard and Zero Overhead Is Zero Attack Surface — the injection threat model; email as untrusted input with connectors attached.
• Agentic-First CLI — the interface as contract; connectors and skills as the automation's observation channels.

On August 13, 2026, DeepSeek AI opened a repository called DeepSeek Harness — dsh, an open-source agent harness in TypeScript, MIT-licensed, whose one-line description is the whole design: "Everything is a Plugin." Four days later it had more than 149,000 GitHub stars, and the count was still climbing toward 150,000 as this post was written. That is an extraordinary reaction to any repository, and it is even more extraordinary for one that is explicitly a developer preview promising compatibility-breaking changes, with no external plugin ecosystem yet and no tagged stable release (the shipped artifact is 0.1.0-rc.7).

This blog met this repository's intellectual foundation two days after it appeared. On August 13 — the same day the Harness repository went public — an 88-page paper was published from the cordiverse/paper repository: A Programming Paradigm for Spatiotemporal Composability, by Yifan Shi and Wei Zhang of Peking University and Tianyi Cui of DeepSeek-AI. I summarized and reflected on it in Spatiotemporal Composability: The Missing Calculus for Self-Evolving Agents. The paper formalizes dynamic composition — components loaded, unloaded, and reconfigured at runtime — with two guarantees: temporal composability (when a component is removed, everything it did is undone) and spatial composability (when the world changes, components whose dependencies changed reconnect or wait, never crash). Its authors extracted the theory from Cordis and Koishi, a plugin framework and a chatbot framework with 4,000+ community plugins — which is why the theory did not arrive as a proposal: it was distilled from software that had already shipped.

DeepSeek Harness's README says in its second line: it is "powered by Cordis, whose design is described in A Programming Paradigm for Spatiotemporal Composability." The calculus this blog called "the missing calculus for self-evolving agents" is not a proposal anymore. It is the runtime under DeepSeek's own agent harness. This post reads the documentation site — deepseek-harness.github.io/deepseek-harness/en/ — the way the project's own docs ask a reader to read it, then distills the key design decisions as insights, each compared against other harnesses, and reflects on what the design actually buys and where its guarantees stop.

The documentation is part of the design

The English docs live at a VitePress site that mirrors a bilingual source tree in the repository — every page is projected from Markdown in docs/, with a Chinese counterpart kept in sync by a custom Git merge driver. The landing page is a one-line redirect to Guide → Use the Web UI, which is the honest shape of the project: the fastest path is npx @deepseek-ai/dsh web, which serves a web UI at http://127.0.0.1:3080, where you add a DeepSeek API key, choose a workspace, and send the agent a task.

Three nav sections matter more than their titles suggest. Guide is user-facing (Web UI, model configuration, a Python SDK). Development is plugin authoring, including a seven-part Cordis tutorial. Reference is the interesting part: an architecture page, a Cordis primer, capability seams, the agent lifecycle, the tool execution pipeline, then a long list of subsystem pages — one per capability (sessions, tools, shell, sandbox, approval, compaction, skills, subagents, workflows, and more) — each ending in a generated Cordis API section with the exact service methods and event signatures, byte-identical to the source, freshness-checked by a build gate so a JSDoc edit cannot ship without regenerating the catalog. The docs also include generated catalogs of every plugin config field, every model-facing tool schema, and every durable session event.

This is not documentation hygiene trivia; it is a design decision worth naming early. The repository treats its documentation as a machine-checked artifact: type declarations pasted into docs are verified drift-free against source (verify-type-equiv), generated catalogs must be byte-fresh (verify-cordis-catalog), and the AGENTS.md documentation standard enforces word budgets per document tier. The reason is stated plainly in the architecture page: "We recommend using an agent to explore the codebase." The documentation is written to be read by agents — which is exactly what a harness company's documentation should be, and almost none of it is.

Key design decisions, read as insights

The section above read the docs as a map. This section reads the code and the design records as a set of decisions — each one a choice with an alternative that lost, recorded in the repo's own Agent Notes, and a comparison that makes the stakes visible. Two framing notes. First, DeepSeek Harness is not the first harness to reach several of these destinations: OpenHands built an event-stream backbone years earlier, SWE-agent argued that the interface between model and computer is the product before DeepSeek shipped one, MiniCode's conversation client is the explicit reference shape behind the request pipeline, and the Claude Code and Codex hook protocols are things the harness implements as a bridge rather than invents. Second, the comparisons below are drawn from each harness's own documentation and code, not from marketing — and the second research pass added source-level findings the docs alone would not have yielded: the compaction checkpoint format, the hooks.json bridge, and Typert's type-graph generator, each covered in its own insight.

Insight 1 — History is the boundary: the append-only log, enforced

The spine of the design is the session log: an append-only log of typed events from which the model's message history is derived by a pure fold, never stored. What makes the decision an insight is the enforcement, which the source makes concrete. Every message-producing append must carry a surfaceOp marker and sourceEventSeqs; the surface manager throws on a raw event without a marker, on a tool/result replacement that changes anything but content, on a non-contiguous sequence number. The derived messages are shared, deep-frozen objects — "mutating logged history through a projection is unrepresentable (it throws)". The turn flow (claim → agent/pre-step → step/start → model request → tools → step/end → agent/turn-stopping → turn/end) is the same shape at every level: durable facts on the log, live control on agent/* events.

The comparison that frames the decision is inside the repo's own note: MiniCode's LLMClient, a stateful conversation client "appended to — never rebuilt — as the conversation advances". DeepSeek adopted the discipline and rejected the shape: a client is "a second operative truth beside the log — the two drift and nothing notices". OpenHands is the closest architectural cousin — its EventStream of actions and observations is also the backbone, replayable and searchable — but the LLM context there is derived by each agent implementation rather than gated by one logged-surface invariant, and the stream is a coordination backbone more than a billing boundary. Claude Code keeps JSONL transcripts for replay, but the transcript is not the source of the next request. Aider uses git as its history — a version of "never rewrite the past" at a much coarser granularity.

The current generation splits into the same two answers with different mechanics. Gemini CLI ships "conversation checkpointing to save and resume complex sessions" — snapshots, not an immutable log. Claude Code's checkpoints roll back the working tree through git: they undo the files an agent changed, not the conversation that changed them. DeepSeek's is the third answer — an append-only log from which everything derives. The other two make the past recoverable; this one makes it unchangeable.

The insight: history is not a record of the agent; it is the boundary of what the agent can do. A harness that edits history gives the model a world where the past is negotiable. DeepSeek's gives it a world where the only move is to append.

Insight 2 — The loop is a row: microkernel over monolith

A running dsh is a plugin tree composed at boot from ordered layers. A profile is a named composition (web and headless ship as templates); a bundle is a distribution format — config rows plus the code they mount (dsh-base is the first layer of every profile; dsh-web-app adds the browser; dsh-headless is a one-shot runner with no server). Layers apply to an empty entry list in order, and a patch targets a row by id and replaces its whole config, or inserts new rows. dsh --profile web --dump-config prints the tree your machine actually boots, and the docs' claim is total: "any row it prints can be replaced by a patch of your own." The model adapter, the tool registry, the session log, the agent loop itself: all rows.

The framework beneath is Cordis, in five ideas: a plugin is an object that implements Service; a context is a repository of services (ctx.sessions, ctx.tools, ctx.llm, ctx.agents, ctx.agentLoop); dependencies are declared via inject so load order is expressed as requirements; services communicate through typed events dispatched as emit, waterfall, parallel, or serial; and registrations are reversible effects — installed through ctx.effect() or ctx.on() so reload and teardown unwind them. The microkernel note records why: the alternatives (a koa-style middleware stack, an explicit phase state machine plugins insert into) would "re-implement dispatch, disposal, and reload semantics that Cordis's native event system already provides"; as Cordis effects, listeners get HMR and disposal for free. The loop itself is a plugin — @deepseek-ai/dsh-agent-loop is "the only concrete loop plugin and is itself swappable — nothing outside it may depend on it".

The comparison sharpens the wager. Claude Code's hooks are the closest mainstream analog — a fixed, documented surface of matcher-grouped extension points — but you cannot add an extension point without the vendor shipping it, and hooks are policy, not composition. LangGraph and AutoGen treat the loop as a graph the developer authors; DeepSeek treats it as a row the developer can disable (disabled: true on the loop's config rule means there is no agent). VS Code's extension host is the classic microkernel, and its "Developer: Reload Window" button is the price of dynamic composition without reversible effects — the exact problem the spatiotemporal paper formalizes. The trade is real, and the repo pays it in incident reports: twice, a quiet configuration mistake silently broke the product, and there are now 27 pre-release checks that catch that class of mistake.

Insight 3 — Policy runs in waterfalls; the final denial is a monotonic guard

Every tool call passes through a pipeline the docs render as a flowchart, and the ordering is the doctrine: waterfalls for extensible policy, guards for final authority. tools/pre-execute runs as a waterfall — hooks, permission, sandbox decisions; a listener that owns the decision short-circuits by returning without next(). Then monotonic guards run — they deny or abstain and can never force-allow, so owner policy that must not be reordered cannot be argued around. The approval seam is fail-closed: allowed-once is the only granting outcome; a missing, throwing, or non-conforming answerer resolves to unavailable. Then tools/execute wraps the tool body as around-dispatch (timeouts, retries, metrics), tools/post-execute may accept, block, or rewrite, and a definition-owned finalizeContent callback — snapshotted at the moment the call starts, so no later mutation can change what the outcome must be — enforces the last content-only invariant before the frozen tools/result.

Two details show the care. A call collapsed by code mode (see Insight 6) is denied before the policy pipeline — "pre-execute listeners, approval ask, and guards must never observe — or worse, approve — a call that can only fail". And cancellation is a contract, not a cleanup: the registry tracks whether the tool body started and distinguishes ABORTED_BEFORE_DISPATCH from ABORTED, fusing the caller's signal into any around-wrapper replacement so "cancellation never abandons the body". The enforcement layer hangs off the same pipeline: sandbox modes (read-only / workspace-write / danger-full-access, filesystem effects only, enforcement reported full or partial), permission presets (workspace-write+ask, danger-full-access+never), the scrubbed-env and private-temp-file rules from the defensive-patterns ledger. The local backend is worth one more sentence: it functionally probes competing confinement candidates — bwrap then Landlock on Linux, Seatbelt on macOS, a Windows ACL restricted-token runner — picks the first that actually works on this kernel, and fails closed if none does; on Windows, every workspace gets a standing SID grant while each live session receives a random private temp directory with its own capability, revoked on dispose.

The comparison: Claude Code's permission system (allow/deny/ask) and hooks cover the same roles, but they are configured surfaces; SWE-agent's ACI is a fixed, deliberately minimal interface; OpenHands routes policy through a security analyzer. The DeepSeek distinction is the ordering guarantee — extensible policy upstream, monotonic final denial downstream — plus a fail-closed approval contract with a single answerer.

Insight 4 — A capability is a seam, not an interface

A swappable capability has three roles that change at different rates: a Service Definition owning the ctx.<key> and the vocabulary, one or more Service Providers implementing it, and a Consumer (usually a model-facing tool) programming against it. The capability-seams note records why: "swapping a local executor for a sandboxed one would churn the tool schemas the model sees, even though the model-facing contract never changed." packages/shell is the reference template — dsh-shell (definition), dsh-bash-local / dsh-bash-sandbox (providers), dsh-tool-bash (consumer) — and the rule is to split only when roles evolve independently. The subagent seam shows the payoff: providers registered by name include in-process spawn, fork, ACP, Codex, Claude Code, and the dsh SDK itself, all behind one interface; a provider advertises its start-time capabilities statically, and a request needing one it lacks is rejected loud before any run exists.

The comparison: MCP is the industry's attempt to standardize the tool seam, and DeepSeek supports it — but treats it as one consumer family, not the seam itself; the seam is the three roles behind a stable context key. Codex and Claude Code each ship one implementation of each capability. The subagent registry's use of the vendors' own kits (Anthropic's agent kit, OpenAI's app server) is the inverse move: instead of reimplementing a rival harness, mount it as a provider.

Insight 5 — Interop as product strategy: adopt rivals' formats

The seam philosophy has a product-strategy face, and it is visible in three places where the harness deliberately implements other products' formats. The Claude Code hooks bridge reads a real hooks.json — the matcher-grouped configuration Claude Code itself uses — and runs unmodified hooks (SessionStart, PreToolUse, PostToolUse, Stop, subagent hooks) against DeepSeek's typed extension points, mapping Claude's decision vocabulary onto them. The compaction engine produces a checkpoint in the same eight-section structured Markdown that Claude Code's own auto-compact produces — "Primary Request and Intent", "Files and Code", "Next Step", and the rest — delivered as the trailing user message, so a session compacted by one harness can be resumed in the other's shape. The subagent backends start the vendors' own binaries and speak their own protocols. And the workflow engine's meta block "matches the Claude Code dynamic-workflows meta block" verbatim.

The strategy is consistent: when you adopt a rival's format, their files and their habits become portable into your product — the side effect Aaron's teardown names. But it cuts both ways, and the insight is the tension: the harness is a compatibility layer for the vendors' surfaces, not a standard-setter. The one format DeepSeek is not adopting is the one it hopes to set — the append-only, prefix-preserving history model. That is the bet with a deadline this post returns to in the reflection.

Insight 6 — Code mode: the tool list is a presentation, not the interface

The tool registry owns presentation modes — native, code, both — chosen by config. In code mode, the model gets a generated TypeScript SDK over the visible tools plus one reserved run_code transport: it writes a program that loops, branches, and runs several reads at once, and only what it prints or returns comes back into the conversation. The note's framing is borrowed openly from Cloudflare's Code Mode: "LLMs are better at writing code than at emitting tool calls, because they have seen millions of lines of real code and comparatively few contrived tool-calling traces." The program runs in a fresh worker thread with an empty environment, heap and wall-clock caps, and hard termination — and the trust posture is stated without hedging: run_code is "bash-equivalent by design — no unsafe-acknowledgement flags — because the harness already ships dsh-bash-local, which executes arbitrary model-written shell commands with strictly more ambient authority." Every sub-call traverses the full tool pipeline with the parent's token; deferred contexts are held until after the outer result so call/result adjacency survives.

The comparison: Cloudflare's Code Mode is the cited antecedent; SWE-agent's ACI research is the academic antecedent of "tool design is the product" — its authors found that the choice and shape of editing and search tools mattered more than the model. Most harnesses still present tools as JSON-schema lists and round-trip every intermediate result into context. The workflow seam takes the same principle one level up: the model writes an orchestration script — with agent() calls that spawn subagents under caps, executed in a vm realm inside a per-run worker thread — so the model curates not only its own context but the delegation tree.

Insight 7 — The type system is the runtime's mirror

Under the whole stack sits a mechanism no other harness in this comparison has: Typert, a compiler-independent TypeScript type-graph analyzer that extracts a model of the codebase's types, services, and events from the source and emits artifacts from it. The same analysis produces the Host↔Client RPC contracts (methods marked @Remote), the tool-schema catalog, the docs' byte-identical Cordis API sections, the code-mode SDK the model programs against, and the API catalog the cordis_inspect tool serves to the agent mid-session. One representation, five consumers — and the consumers include the model itself.

The comparison makes the move legible. Most harnesses hand-write their API docs or derive them loosely; MCP defines tools at runtime; TypeScript type reflection is usually spent on runtime validation (zod-style), not on generating the agent's own view of the runtime. DeepSeek's version means the docs page, the RPC boundary, the model-facing SDK, and the self-inspection tool cannot drift from each other or from the code — the freshness gates (verify-cordis-catalog, verify-type-equiv) are the enforcement. It is the mechanism that makes the "documentation is written to be read by agents" claim true: the agent reads the same generated contracts the docs print.

Insight 8 — The request is a frozen artifact; the bill is the assertion

In the loop source, every request is composed the same way: the header folds from the log (logged as request/header with reasons initial, resume, or change), the agent/request waterfall may propose the config, and the final GenerateOptions is deep-frozen and marked so the invariant checker can recognize conversation work. The invariant module — a separate companion plugin — replays the log in a fresh session on every request and compares its derivation against what the loop is about to send: "the live cache cannot vouch for itself." The rejected alternative, recorded in the note, is the telling one: detect-and-report (compare consecutive requests, warn on divergence) was refused because "a warning arrives after the bad request has already shipped." On top sits a paid test run against the real API that fails unless the second request in a conversation reports cached input tokens. The bill is the assertion.

The comparison: no mainstream harness ships an invariant checker over request reconstruction. Claude Code and Gemini use provider prompt caching, but the discipline is configuration, not a gate; providers report cache reads in usage, but harnesses do not fail builds on them. The bill-as-assertion is the design's most novel move — the test suite includes the price.

Insight 9 — Per-agent scope: registration is visibility and lifetime

The scope primitive makes one fact drive both: a registration made through an agent's agent.ctx is visible only to that agent and owned by that agent's lifetime. Scoped registrations shadow global ones — the per-agent persona and per-agent tool-variant mechanism — and scope-filtered dispatch carriers route an event about one agent's activity to that agent's listeners. The setup window — after the agent object exists, before it is published — is where a creator composes an agent's scoped world.

The comparison: VS Code scopes contributions to extensions, not per-instance; OpenHands sessions are per-conversation, but capability sets are largely global; LangGraph threads state explicitly through the graph. DeepSeek's per-agent plugin mounting is what makes the four presets (standard, code, minimal, creation) work as per-session compositions instead of global profiles — and it is what makes the "one row" claim in Insight 2 honest: the row can be scoped to a single agent.

Insight 10 — The training environment is the product

The minimal preset is a two-tool composition — a persistent shell plus str_replace_editor — with a system prompt of exactly one sentence: "You are a helpful software engineer assistant." The repo's own note names its purpose: the minimal preset owns the complete Claude SWE-compatible RL agent composition, with the persistent bash environment the RL harness uses. The harness produces the trajectories; the trajectories feed post-training; the trained model goes back to work inside the same harness. DeepSeek open-sourced a piece of that loop.

The comparison makes the decision legible. SWE-agent was built explicitly to produce RL training trajectories — the ACI paper is the academic origin of "the interface is the design lever". terminal-bench-rl trains long-horizon terminal agents with GRPO at 32×H100 scale and reports the sharpest version of the insight: harness-level improvements ("native tool calling, multimodal support, execution optimization") lifted scores without training. Meta-Harness (Stanford IRIS) reached 76.4% on Terminal-Bench 2.0 and was itself "discovered through automated harness evolution". The harness is not just the product — it is the curriculum, and the community is now evolving it like a hyperparameter.

Insight 11 — The harness builds the harness

The repository's AGENTS.md is a standing-order document for agents; decisions live in Agent Notes that must ship in the same PR as the decision, each with an "alternatives considered" section; generated catalogs are freshness-gated; keyless snapshot tests replay a recorded session log against expected output; per-file 100% coverage is the CI gate; and the self-referential toolset (cordis_inspect, cordis_mount, cordis_unmount) lets the agent inspect and mount plugins into its own live runtime, with unmount waiting for every owned effect to reach quiescence.

The comparison: CLAUDE.md and AGENTS.md instruction files are now industry standard — Codex, Cursor, and Gemini all adopted them — but the enforcement is the unusual part: notes as PR gates, verify-* generators that fail on drift, postmortems that do not count until their check is proven to turn red, word budgets per document tier. The teardowns' numbers — 12,293 commits in 64 days, more Markdown files than TypeScript files — are what that enforcement buys. And the self-referential toolset is the honest statement of the whole design's posture: the vm is an API narrowing, not a security boundary — "an opt-in development tool with bash-equivalent trust."

Two teardowns of the same codebase

Within two days of the release, two independent teardowns went up: Cloud Codes' 21-minute DeepSeek Harness Architecture: Insane Software Engineering Behind It (Aug 15) and Aaron — AI-native builder's 10-minute What I Learned From DeepSeek's Harness (Aug 16). Both read the same repository and converged on the same two findings: the session log is a billing design as much as a correctness design, and the harness — not the model — is the product. The insights above read the design the way its authors record it — docs, source, and decision notes. The teardowns read it the way a skeptic would: what is this worth, what does it cost, and what breaks? Both videos pin their claims to the repository, and I checked their key claims against the repo's own Agent Notes and the shipped config files before writing this section; the two videos corroborate each other on the facts that matter.

The golden rule is worth 120x

The Cloud Codes video opens with the rule it found buried in the codebase: "Once something has been sent to the model, you do not go back and change it. A wrong file path sitting in the history, you leave it there and append a new line saying it was wrong." That sounds like bookkeeping. On DeepSeek's own price list it is worth about 120 times.

The mechanism is prefix caching. Because the model forgets, every step resends the whole conversation from the top — a serious coding session pushes past 100,000 tokens through the pipe on one step, then does it again seconds later. Providers rescue the economics with prefix caching: if the leading tokens of this request are word-for-word identical to the last one, the provider restores the computation it already did and starts at the bookmark. Word-for-word is the entire condition — change one character on page three and the bookmark is worthless, the book gets read again. DeepSeek publishes exactly what that costs, which is unusual: at launch-week prices on the pro model, a cached input token runs about a third of a cent per million tokens; the same token uncached runs about 43.5 cents. That is the teardown's arithmetic — it rounds to 120x — for identical text in two neighboring columns of one price table, the difference decided entirely by whether the harness disturbed something it had already sent.

So the real design question for a harness is not which tools to offer or how to word the prompt; it is: can you run a 200-step session without ever going back and editing what you already sent? Most harnesses answer no, because agents edit their history — summaries replace old turns, bulky tool output gets trimmed, a stale file copy gets swapped for a fresh one. Every one of those is sensible; every one reaches backwards into the transcript; every one throws the bookmark away at exactly the moment the conversation is longest and rereading costs the most.

DeepSeek's answer is the append-only log this post already described, and the video's account matches the repo's own Agent Note (2026-07-05-reconstructable-requests) almost verbatim: model-visible ⟺ durably referenced — anyone holding the log, its referenced objects, and the pinned code version reconstructs every loop request byte-for-byte. The note adds the sentence that tells you this team understood their own design better than most write-ups of it: "Prefix-cache stability is corollary #1, not the headline" — "stability is emergent, not managed." They did not set out to build a cache optimizer; they built a log you cannot edit, and the prefix stability fell out the other side.

The note also records the enforcement they chose and the alternative they rejected. Derived messages are deep-frozen — mutate logged history through a projection and it throws, so breaking the rule stops being something you avoid and becomes something you cannot express. The rejected alternative was detect-and-report: compare consecutive requests and warn on divergence — rejected because a warning arrives after the bad request has already shipped. Instead they shipped a module whose entire job is to disbelieve the agent loop: on every request it builds a fresh session, replays the log from the beginning, derives the messages again from scratch, and compares its answer against what the loop is about to send — "so the live cache cannot vouch for itself." On top of that sits a paid test run against the real API with a real key that fails unless the second request in a conversation reports cached input tokens. The bill is the assertion. Cold cache, red test.

The video's best story is the compaction bug that shows the design paying for itself. When a conversation outgrows the context window, the harness must summarize the old part so the work can continue — and the first version of the summarizer did the obvious thing: sent a fresh "you are a summarizer" system prompt followed by the conversation to condense. The system prompt sits at the very front of the request, exactly where the cache starts keying; one differing first token invalidates the entire prefix. Every compaction paid full processing price for the whole replayed history twice — once for the request that tripped the limit, once for the summary, at exactly the moment the history was longest. The fix is in the repo's own Agent Note (2026-07-21-compaction-summary-prefix-cache-reuse): the summarization directive moved from the front of the request to the end — the auxiliary call now reproduces the last routed request's prefix verbatim and appends one trailing instruction, making it a genuine prefix-extension of the warm request. Tools ride along on the summarization call even though the summarizer never calls one, because dropping them would misalign every following token.

The four presets: from training to self-modification

The video also surfaces the presets — the four agents "wearing the same skin" — which I verified in the shipped config files under apps/cli/config/agent-presets/: standard, PTC/code mode, minimal, and creation. Code mode replaces the tool list with a generated TypeScript interface over the tools plus one run_code transport: the model writes a program that loops, branches, and runs several reads at once, and only what it prints or returns comes back into the conversation — the model curates its own context instead of drowning in it. The reasoning is borrowed openly from Cloudflare: models have read millions of lines of real code and comparatively few tool-calling traces, so ask them for the thing they have actually seen. The program runs in a fresh worker thread with an empty environment, a heap cap, a wall-clock cap, and hard termination — containment, the video notes, not a security boundary, with authority comparable to the bash tool.

Minimal mode is the one worth pausing on. Two tools — a persistent shell whose working directory and environment survive between turns, plus str_replace_editor — and a system prompt of exactly one sentence: "You are a helpful software engineer assistant." The repo's own Agent Note (2026-08-10-minimal-preset-owns-rl-composition) says why: the minimal preset owns the complete Claude SWE-compatible RL agent composition, with the persistent bash environment the RL harness uses. The video's reading is direct: the minimal preset is a training environment shipped to you unchanged as an option in a dropdown beside the coding agent you are going to use anyway. The harness produces the trajectories; the trajectories feed post-training; the trained model goes back to work inside the same harness. DeepSeek open-sourced a piece of that loop, with the notes describing why each service in it belongs there.

Creation mode is the self-modifying preset this post's earlier section already examined through the cordis_* tools; the video adds the product framing — it sits in the same dropdown, its documentation says "treat a session on this preset as shell access," and its stated purpose is that a person can ask an agent to write another agent, and the preset that agent writes becomes something other sessions can mount.

The subagent backends and the memos

Both teardowns were stopped mid-scroll by the same feature: the subagent registry ships backends for Claude Code and Codex — not reimplementations, not scraped protocols. The Claude Code backend calls Anthropic's own agent kit at a pinned version, resolves the real Claude binary installed on your machine, and hands the kit that exact path; the Codex backend starts OpenAI's own app server over stdio and speaks its protocol. A DeepSeek agent running a DeepSeek model can hand a self-contained task to Claude Code, which works in the same directory, returns one answer, and is torn down — process tree and all, with the teardown proven before the call returns. The rejected-alternatives note explains why the shortcuts were refused: talking to the model directly or hand-writing the command-line protocol would bypass each product's official integration surface and prove nothing about approvals, tools, or cleanup.

And the memos — the number Cloud Codes dwells on: 683 English design records in .agents/notes/, plus a Chinese translation of every one, organized by status (proposed, implemented, rejected, archived), with every non-trivial change required to add or update a note in the same pull request, and every note required to carry an "alternatives considered" section. "A decision recorded without what it beat invites re-litigation." A script validates the headers, cross-checks the status against the folder, and rejects proposal language inside a note claiming to describe shipped reality; archived notes are frozen in an append-only manifest and must not be treated as authority. Cloud Codes' best evidence that this works is the postmortem of a web agent that was asked to change the interface it was itself running inside: it edited the source, started a dev server on a second port, validated that, then started a third server on a third port — three servers, one user, and the agent checking the only one nobody was looking at. The incident is readable in that detail because every step is traced by sequence number through the same append-only log the cache rule exists to protect. The design that keeps the bill down is the design that made the incident legible.

Same model, eight harnesses: the harness is the product

The second video starts with the numbers that motivated it: the same model ran thirty real work tasks through eight different harnesses — task success swung from 46.7% to 66.7%, and cost per finished task varied by a factor of seven. Nothing about the intelligence changed; what changed was the layer between you and the model. The video reports that the creator of the top-scoring harness read the DeepSeek repository and said it was the first time something new in this space made him want to revisit his own choices — when the winner reads a rival's homework and starts rethinking his own answers, the homework is worth reading.

Its four designs are the cache discipline, the event log, the one-row loop, and the process. The cache discipline: many frameworks write the current time into the top of the system prompt, so the prefix never matches and every request runs at full price forever; DeepSeek keeps the clock out of the prompt, sorts tool descriptions in one fixed order so nothing reshuffles, and runs a live test that flatly asserts every request after a session's first must hit the cache — "if any change breaks the prefix, the build goes red before the money burns." The event log: 44 kinds of events, exactly three visible to the model (user messages, assistant messages, tool results); the system never stores the conversation it sends — it recomputes the model's context from the log before every request, and a runtime check compares the outgoing request against what the log says it should be and refuses to send. The everyday superpower of that design is debugging: when an agent does something inexplicable, you stop guessing — replay the log to that step and the exact context the model saw is in front of you; crash at step 80, recompute and continue, same log, same context, as if nothing happened.

The one-row loop makes the everything-is-a-plugin claim legible in config: the loop that drives the agent — calls the model, runs tools, decides whether to continue — is one ordinary config rule, and disabled: true on that rule means there is no agent. The main loop and a tiny badge plugin are equals in the eyes of the config. Code mode is standard mode plus one appended rule; that rule alone flips how tools are presented to the model. The price of that flexibility is written in the repo's own incident reports: twice, a quiet configuration mistake silently broke the product; once, 178 green tests and a full coverage set on top of a system that died the moment a real editor connected. Their answer both times was a pre-release check that catches the class of mistake — there are 27 of those checks now. That is the bill for everything-is-a-plugin: pay it one crash at a time.

The process numbers are the fourth design and the thing that most surprised both teardowns: 12,293 commits in 64 days; the top contributor made about 5,000 of them; the branch names in the merge history count "worktree" 210 times and "codex" 209 times; there are more Markdown files in the repository than TypeScript files. The previous section's notes and checks are the mechanism behind those numbers — and the video sharpens the theory: this process is bureaucracy in a human team; in an agent team, it is guardrails, because the writer never gets tired.

Both videos end with the same honest caveats from DeepSeek's own known-limitations pages — the runaway-loop guard only sends reminders and eventually goes quiet, the file tools have no timeout at all, and early testers say daily experience still trails Claude Code and Codex. If you need work done this week, neither video recommends switching. And both end on the business model. Cloud Codes notes that on August 16, three days after the harness went free, DeepSeek's pricing page introduced peak and off-peak billing — uncached input goes from 43.5 cents to $1.32 at peak, output from 87 cents to $3.96: the harness gets cheaper and the tokens get dearer in the same week. The append-only design is what makes that survivable: a harness that keeps your prefix warm keeps most of your traffic in the cached column, at a fraction of the uncached price. Aaron's reading is the same shape: Anthropic keeps its harness closed and wired to a subscription — a moat around the model — while DeepSeek gives its harness away and it reads everyone else's files: a funnel for the thing they actually sell. And the side effect he names is worth keeping: when a vendor adopts its rivals' formats, your files become portable, whichever harness you run.

That last point connects to what this blog argued in Every Token Has a Price Tag: the unit got cheaper but the task did not, and the shape of the bill is a design decision. DeepSeek Harness makes the shape of the bill a first-class architecture property — the append-only log is not only a correctness design and an audit design; it is a billing design, worth roughly two orders of magnitude on the input side when the harness respects its own golden rule.

Reflecting: what the design buys, where it stops

The bet. Building the whole product on a plugin framework with reversible effects is a wager that harness engineering is, at bottom, a dynamic-composition problem: the hard parts of an agent runtime — adding capabilities, swapping providers, reloading policy, cleaning up after a failed experiment — are the hard parts of runtime plugin management. The wager is coherent, and the evidence base is not trivial: the framework underneath shipped in Koishi with 4,000+ community plugins before the theory was written down. The paper's own conclusion is the honest version of the story: the theory was extracted from a working system, not written first and applied later. What the formalization buys is the second product — dsh did not have to re-solve plugin lifecycle, HMR, dependency resolution, or teardown; it inherited them as a vendored, formalized substrate and spent its own complexity budget on agent concerns: the session log, the seams, the pipeline, the policy. That is exactly the economics this blog keeps returning to in harness-engineering-best-practices-for-ai-agents and go-is-good-for-harness-pipelines: the harness is where composition complexity concentrates, and the team that treats composition as the product wins the cost curve.

The harness is the product. Both teardowns end on the sentence this blog has been circling for months, and the numbers are finally there to back it: the harness is the product. Cloud Codes reads the public Terminal-Bench board the same way — the same weights score 83.8% under one major harness and 80.4% under another, 3.4 points decided entirely by software with no weights in it — and Aaron's own benchmark found the same model finishing between 47% and 67% of real tasks across eight harnesses while cost per finished task varied sevenfold. No weights changed in any of those comparisons. The wrapper changed. The comparison research in the insights above makes the point stronger, not weaker: SWE-agent's ACI paper argued the interface is the lever; Meta-Harness reached 76.4% on Terminal-Bench 2.0 and was itself found by automated harness evolution; terminal-bench-rl reports that harness-level improvements lifted a Qwen3 agent to the top of its class without training. That is why a lab publishing its harness under an MIT license is giving away something much closer to the product than the announcement suggests: the harness is not the part with the intelligence, and it is the part with the leverage.

The guarantees stop where the paper's do. Observational equivalence, not literal restoration — unplugging a component does not restore the heap's exact layout, only what the declared dependencies observe. The sandbox vocabulary covers file effects only; network and process visibility are out of scope by declaration. The self-modification toolset is bash-equivalent trust, explicitly not a security boundary. And the deeper caveat survives from the paper: recovery guarantees clean removal, and for agents the interesting failure is the one where a faulty self-modification disables the very process needed to recover — the calculus makes removal safe, but removal still has to be invoked.

The training loop is the product, too. The minimal preset is the sharpest thing either teardown found, and it deserves its own reflection. The harness DeepSeek hands you for free is the same environment its models are trained in: a two-tool, one-sentence-prompt composition whose Agent Note names its purpose outright — the Claude SWE-compatible RL agent. The harness produces the trajectories; the trajectories feed post-training; the trained model goes back to work inside the same harness. That closes a loop most labs keep private, and it is the strongest form of this blog's agent-harnesses-need-tasks-that-fight-back claim: the tasks a harness runs are not only an evaluation, they are the curriculum. It is also why "everything is a plugin" is not a design aesthetic but a training-infrastructure decision: the row that defines the training environment is the same row you can edit in the shipped product. And the reversible-effects guarantees matter beyond the product for the same reason: a training run is millions of agent steps, and the promise that teardown fully undoes what a component did is what keeps one experiment's state from leaking into the next run's trajectories. Cloud Codes ends with the question the loop raises: "The model is learning your harness. Is your harness learning anything back?" The honest answer, as with every guarantee in this post, is that the loop optimizes whoever runs it — which is why the same week the harness goes free, the tokens get dearer.

The preview caveat. More than 149,000 stars in four days is a demand signal, not a validation of production readiness. The README's first declaration is "developer preview... THERE WILL BE COMPATIBILITY-BREAKING CHANGES." The session log carries SESSION_FORMAT_VERSION at 0 with no compatibility promise; backends reject old on-disk formats. The release cadence is remarkable — 0.1.0-rc.7 and 2,600+ merged PRs by day four — but that velocity is exactly the argument for treating the docs as the product's present shape and the code as a moving target. The single-process runtime is another boundary worth naming: everything runs in one shared process, so the compositional guarantees are process-internal; cross-process isolation is delegated to the sandbox providers and the subagent seams, which is where the real blast-radius questions live.

The bet with a deadline. Cloud Codes ends by making the sharpest claim in either video falsifiable: within a year, at least two of the major harnesses — Claude Code, Codex, Cursor's CLI, Gemini's, Aider, the LangChain stack — will publicly document an append-only or prefix-preserving history model. If the bet holds, the append-only log stops being DeepSeek's signature and becomes the industry baseline, and this post's cache arithmetic stops being a curiosity and becomes the reason every harness documents its history discipline. If it fails, the repository's discipline was an outlier, not a direction — and the difference will be visible in the same place the videos looked: the bill.

What to steal regardless. The session log as single source of truth with a logged-surface invariant; the seam discipline (definition / provider / consumer, one role is not a capability); the tool pipeline as a waterfall of policy with monotonic guards for final denial; the docs-as-machine-checked-artifact practice with freshness-gated generated catalogs; the defensive-patterns page as a bug-class ledger; the honest scope declarations (file effects only, bash-equivalent trust, per-call policy). The teardowns add two more items to the list. First, the cache trio: keep the clock and anything else volatile out of the prompt prefix, sort tool descriptions in a fixed order, and run one test that asserts cache hits — the bill is the assertion. Second, the rejected-folder discipline: a decision recorded without what it beat invites re-litigation, so make "alternatives considered" a gate, not a habit. Any harness team can adopt any one of these without adopting Cordis.

The project's most distinctive move — and the reason this blog's earlier spatiotemporal-composability coverage connects to it directly — is that it makes the plugin runtime itself the product surface: dump-config prints your machine's tree, any row is replaceable by a patch, and the agent that runs inside the tree can inspect, mount, and unmount its own components. Four days after the calculus appeared on arXiv-style GitHub, it was the shipping substrate of a ~150,000-star harness. The theory mattered; the harness is what the community voted for — and the community's own teardowns of it are already teaching the rest of the industry which parts of the architecture are portable and which are the product.

References

• DeepSeek Harness documentation (English) — https://deepseek-harness.github.io/deepseek-harness/en/
• DeepSeek Harness repository — https://github.com/deepseek-ai/deepseek-harness
• README.md — "Everything is a Plugin", powered by Cordis
• docs/architecture.md — profiles, bundles, the turn flow, capability seams
• docs/cordis-primer.md — Cordis in five ideas; dispatch modes; waterfall semantics
• docs/agent-lifecycle.md — turn and step sequence diagram
• docs/tool-execution-pipeline.md — the guarded pipeline
• docs/defensive-patterns.md — the bug-class ledger
• docs/AGENTS.md and AGENTS.md — documentation tiers, standing orders
• Subsystem pages: session, scope, tools, shell, sandbox, approval, permission-presets, compaction, skills, subagent, workflow, commands, goal, schedule, plan, invariants, session-telemetry
• Agent Notes: microkernel event taxonomy (2026-06-11), capability seams (2026-06-13), code mode (2026-06-15), reconstructable requests (2026-07-05), agent-scope runtime design (2026-07-12), canonical tool output (2026-07-20), compaction prefix-cache reuse (2026-07-21), per-session agent presets (2026-08-03), minimal preset owns the RL composition (2026-08-10)
• .agents/notes/implemented/feature/2026-07-08-self-referential-cordis-toolset.md — the cordis_* toolset design
• docs/user/guide/python-sdk.md — deepseek-harness-sdk, bundled runtime
• A Programming Paradigm for Spatiotemporal Composability (Shi, Zhang, Cui; PKU + DeepSeek-AI) — https://github.com/cordiverse/paper
• This blog's coverage of that paper — Spatiotemporal Composability: The Missing Calculus for Self-Evolving Agents

Other harnesses referenced in this post

• OpenHands — https://github.com/All-Hands-AI/OpenHands — event-stream backbone, replay and event search
• MiniCode — https://github.com/FuSC24/MiniCode — the LLMClient reference shape behind reconstructable requests
• SWE-agent — https://github.com/SWE-agent/SWE-agent — "Agent-Computer Interfaces Enable Automated Software Engineering" (Yang, Jimenez, et al.)
• Claude Code — https://code.claude.com/docs/en/hooks — hook matcher groups, permissions; the protocol DeepSeek bridges
• Codex — OpenAI's agent CLI; DeepSeek's subagent backend starts its app server over stdio
• Aider — https://github.com/Aider-AI/aider — git as history, repo map
• Cloudflare Code Mode — https://blog.cloudflare.com/code-mode/ — the cited antecedent for code mode
• Harbor / Terminal-Bench — https://github.com/harbor-framework/terminal-bench — the Terminus-2 harness family
• Terminus-KIRA (KRAFTON AI) — https://github.com/krafton-ai/KIRA — harness-level improvements on Terminus 2
• Meta-Harness (Stanford IRIS) — https://github.com/stanford-iris-lab/meta-harness-tbench2-artifact — 76.4% on Terminal-Bench 2.0, found by automated harness evolution
• Terminal-Bench-RL — https://github.com/Danau5tin/terminal-bench-rl — GRPO training of terminal agents at 32×H100
• Gemini CLI — https://github.com/google-gemini/gemini-cli — conversation checkpointing, GEMINI.md context files, MCP
• Claude Code checkpoints — https://code.claude.com/docs/en/checkpoints — git-based working-tree rollback
• OpenHands event service — https://github.com/All-Hands-AI/OpenHands — event history search and confirmation API
• LangGraph — https://github.com/langchain-ai/langgraph — the loop as an explicit graph
• Typert — packages/typert in the DeepSeek Harness repo — the compiler-independent type-graph analyzer behind RPC contracts, tool catalogs, and the agent-visible API catalog
• packages/hooks/hooks-claude-code — the real-hooks.json bridge
• packages/compaction/compaction-basic/src/summarizer.ts — the Claude-shaped eight-section checkpoint
• packages/workflow/workflow-worker-thread — model-written orchestration scripts in a vm realm
• packages/sandbox/sandbox-local — the bwrap → Landlock → Seatbelt → Windows-ACL confinement chain with functional probing

Videos

• Cloud Codes. DeepSeek Harness Architecture: Insane Software Engineering Behind It (2026-08-15, 21:27) — the append-only golden rule, the ~120x prefix-cache discount, the invariant module that disbelieves the loop, the compaction-prompt fix, the four presets, and the 683 agent notes.
• Aaron — AI-native builder. What I Learned From DeepSeek's Harness (2026-08-16, 10:06) — the eight-harness benchmark (47%–67% success, 7x cost), the 44/3 event log, the one-row agent loop, and the agent-built process behind 12,293 commits.

On August 13, 2026, an 88-page paper appeared on GitHub: A Programming Paradigm for Spatiotemporal Composability, by Yifan Shi and Wei Zhang of Peking University and Tianyi Cui of DeepSeek-AI, published from the cordiverse repository. Within two days it had over 1,500 GitHub stars — an unusual reaction for a paper whose tools are monads, coeffects, and operational semantics.

The paper answers a question every engineer has felt but nobody has formalized: how do you safely remove a piece of software from a running program? Every program that supports plugins has a shameful button — in VSCode it is "Developer: Reload Window," a command that restarts the entire extension host so you can remove one extension. The button exists because the alternative is too hard: there is no safe way to unload a single extension's code, undo what it did to the program, and keep everything else running.

This post does two things. First, it lays out the paper's key insights the way the authors present them — their own contributions, quoted and translated into plain language. Then it reflects on each insight in turn: what it really buys, where its guarantee stops, and what it means for the problem this blog keeps coming back to — agents that modify their own harnesses.

The problem the authors start from

The paper's motivation is a gap, not a bug report. Composition — assembling complex systems from simpler parts — is the most-studied topic in software engineering, but almost entirely in its static form: function calls, module imports, class inheritance, resolved at compile time and fixed for the life of the process. Dynamic composition — components loaded, unloaded, and reconfigured at runtime — has "theoretical foundations... underdeveloped, compared to the rich formal frameworks available for static composition."

The evidence that this is a real gap, not an academic one, is measured: among the top 100 VSCode extensions by install count, 87 contain executable code and require a host restart to remove; only 7 declare dependencies on other extensions at all. The industry's answer to the gap is the coarse-grained workaround: restart the process to get rid of a bad module, let the container orchestrator manage service dependencies. The workaround's costs are real and structural — every restart discards process-local state (caches, connections, partial computations) and rebuilding takes seconds to minutes; orchestration cannot express dependencies between components that share an address space, and turns local calls into network calls.

The authors' framing claim: the field has a rich theory of static composition and none of dynamic composition — and the industry papers over the hole with restarts.

The authors' key insights

The paper's own structure makes its claims explicit. One framing insight (the two dimensions) and five formal contributions, each building on the last.

Insight 1 — Dynamic composition needs two dimensions that static theory never had to face

"To characterize the requirements of dynamic composition, we identify two orthogonal dimensions beyond the well-studied algebraic aspects of composition." The first is temporal composability: "upon removal of a component, the modifications the component made to the shared environment must be completely and safely reversed." The second is spatial composability: "components must be able to declare, discover, and resolve their dependencies on one another in a structured and verifiable manner."

The authors are careful to anchor both in familiar static settings: temporal composability reduces to lexical scoping — RAII, bracket patterns — and spatial composability reduces to module import resolution. The move is not to invent new requirements, but to notice that the old guarantees stop holding the moment components arrive and depart at runtime. A plugin's effects can outlive any function call, so the lexical scope that once ran destructors automatically is gone; a dependency can vanish mid-execution, so the one-time wiring the linker performed is no longer enough.

Insight 2 — Effects can be made revertible (contribution 1)

The authors' first contribution: "We formalize revertible effects: every context transformation carries an explicit inverse that the runtime tracks, and both tracking and recovery preserve composition, so the context is recovered upon component removal."

In plain language: effects are what a component does to its world — allocating memory, registering a callback, writing to a store. The insight is that each such action should carry its own undo, and the runtime should log which component performed which effects, in what order. On removal, the runtime plays the inverses in reverse order — last effect undone first, like unwinding a stack. Because the inverse of a composite effect is the composition of the inverses, cleanup is derived, never written by hand. The author of a component supplies one line per atomic operation — the operation and its inverse — and the runtime composes them into correct, ordered teardown. The consequence the authors draw: this "establishes local temporal composability."

Insight 3 — Coeffects can be made reactive (contribution 2)

The second contribution: "We formalize reactive coeffects: a component declares the coeffects it requires as a specification, and each change of the context notifies the component against that specification as activating, deactivating, or neutral."

In plain language: coeffects are what a component needs from its world — a database, a filesystem, an adapter. A component declares "I require a storage backend," and the runtime does the rest. Every change to the world is classified against each component's specification: activating (your need was just satisfied — start), deactivating (your provider was removed — wind down), or neutral (nothing you declared changed — don't react). A component whose dependency is missing stays inactive; it does not error. When the dependency appears, it activates. This "establishes local spatial composability."

Insight 4 — Effects and coeffects are one context, and that is a paradigm (contribution 3)

The third contribution is the paper's boldest claim: "We unify the effect context and the coeffect context into a single context type, in which an observational equivalence on the coeffects supplies the effects with independence, constituting a programming paradigm for spatiotemporal composability."

The unification is not cosmetic. Because the context type is recursive and its coeffect part unconstrained, "any state the system needs to share across components can be encoded as a dependency with an appropriate value type — Σ subsumes all shared mutable states, not just inter-component dependencies." Every interaction between a component and its environment passes through a single object carrying three things: the current state, the undo log, and the dependency map. The paper's metaphor is literal: "loading a component corresponds to executing its effects (plugging in); unloading a component corresponds to recovering its effects (unplugging, without affecting other running components)," with hierarchical contexts enabling arbitrarily nested composition.

The paradigm claim is situated between the two poles of side-effect handling: functional programming threads state explicitly through every call (traceable, equational, and boilerplate-heavy), while imperative programming hides it (ergonomic, and effectively untraceable — React's useEffect registers a persistent side effect that appears in no parameter; Spring's getBean pulls from a process-wide registry with casts at every call site). The context paradigm, the authors write, "combines the traceability of the functional approach with the ergonomics of the imperative approach," and the payoff is their most important sentence: "In both directions, correctness that would otherwise rest on developer discipline becomes a structural property of the paradigm."

Insight 5 — Local guarantees can be proven to compose (contribution 4)

The fourth contribution upgrades the paradigm from a feature to a foundation: "We give a calculus of dynamic composition, which combines the two mechanisms into the notion of a component and equips its lifecycle with an operational semantics. Its metatheory carries spatiotemporal composability from a single component to a whole system of interleaved components."

The calculus models components through a full lifecycle — loading, iteration, withdrawal, asynchrony, failure — and the metatheory proves the properties that matter: preservation, temporal composability, spatial composability, progress, and confluence. The point is compositional in the strongest sense: if every part can be removed cleanly and reconnects correctly, then a whole system of interleaved parts can. "Each part is safe to swap" is a local statement; "the system stays consistent through a storm of swaps" is the global one, and the metatheory is what connects them.

One honesty note sits inside this contribution, and it matters: recovery is guaranteed up to observational equivalence, not literal equality. The authors are explicit that unplugging a component does not restore the heap's exact layout — free releases a block without restoring the arrangement malloc left. What is guaranteed is that "no observer can distinguish" the recovered state from the original, where the observers are defined by the declared dependencies. What you expose as dependencies is what recovery promises to restore.

Insight 6 — It is a shipped system, not a proposal (contribution 5)

The fifth contribution: "We implement these ideas in Cordis, a meta-framework of spatiotemporal composability that provides a core library realizing the formal model with effect tracking and coeffect resolution, as well as a declarative component loader with configuration reconciliation and hot module replacement."

And the implementation is not a demo. Koishi, the chatbot framework built on Cordis, has accumulated over 4,000 community-contributed plugins over four years. The case study makes three claims: temporal composability "without cognitive overhead" (even an inexperienced plugin author gets ordered cleanup without writing an uninstall path); spatial composability across an open ecosystem (switching the storage backend reactivates only the dependents whose resolved dependency changed; a plugin whose dependency is unavailable stays inactive until it appears); and expressiveness plus generality (Koishi's web console is a second, independent Cordis application, the same model in a wholly different runtime). The paper concedes the threats to validity — a single ecosystem, a single host language, observational rather than controlled evidence — but the existence result is the point: the theory was extracted from a working system, not written first and applied later.

Reflecting on the insights

The authors' contributions are the skeleton. What follows is the reflection — where each insight is genuinely important, and where its guarantee stops.

On naming: the first deliverable is the two dimensions

The most undervalued thing the paper does is name the problem. "Reload Window" existed for decades as an accepted tax — nobody called it a symptom of missing theory, because nobody had a vocabulary for what was missing. Naming temporal and spatial composability, and grounding both in their static analogues (RAII, module imports), converts a felt inconvenience into a designable requirement. The restart workaround survived precisely because it was the only available mechanism at the right granularity; once the finer-grained requirements have names, the granularity mismatch stops being an accepted cost and becomes a problem with a theory attached.

This is also the right frame for the agent conversation. Every agent harness that "adds a tool" or "replaces a module" is doing dynamic composition — usually badly, by appending to lists and restarting processes. The two dimensions give agent engineers a checklist: when the agent removes something, is everything it did undone (temporal)? When the world changes, do the things that depended on it reconnect (spatial)? Most harnesses fail both checks, silently.

On revertible effects: structure beats discipline — but only the orchestration is free

The deep move in contribution 1 is the inversion of responsibility: cleanup moves from the author, who must remember and usually gets it wrong, to the structure, which derives it. This is the same move as RAII — the destructor is automatic — extended from lexical scope to runtime lifetime. For autonomous agents this is not a quality-of-life improvement, it is the only realistic option: an agent cannot be instructed into remembering to clean up; a teardown derived from the load is the only teardown an autonomous system will reliably perform. Guarantees you must remember are guarantees an agent will, at some point, not.

But it is worth being precise about what the paradigm makes free and what it does not. The author still writes the inverse of each atomic operation. The paradigm eliminates the composition burden — the ordering, the bookkeeping, the edge cases of interleaved effects — not the semantics burden. If an effect's inverse is wrong, the recovery is wrong, and no amount of structure detects it. This is a quiet but important boundary: revertible effects guarantee that the teardown you supplied is executed, completely and in order; they do not guarantee the teardown you supplied is correct. The structural guarantee is about mechanics, not meaning.

On reactive coeffects: availability becomes a lifecycle state, not an exception

The insight hidden inside contribution 2 is the failure-model change. "A missing dependency means inactive, not error" replaces an exception with a state. Most plugin systems discovered this organically through events and hooks; the paper's contribution is to make availability a first-class, typed, composable property of a component's lifecycle, with a notification language (activating / deactivating / neutral) that the runtime — not the component — drives.

For agents, this is the difference between a harness where a vanished tool crashes the agent, and one where the tool's dependents deactivate and reactivate as tools come and go. An agent that picks tools dynamically is going to experience provider churn constantly; a lifecycle that treats "your dependency is not here" as a normal state rather than a failure is a precondition for agents that gracefully lose and regain capabilities. It also quietly answers a question the blog has asked before about always-on agents: state that survives its providers.

On the one door: auditability, policy — and trust

Contribution 3's unification is the most consequential and the least flashy. If every interaction passes through one context, then the context is simultaneously the undo log, the dependency resolver, and — because declared dependencies are known before a component runs — the access-control chokepoint. The paper draws the security conclusion itself: the dependency declaration "acts as a capability request, and the context proxy acts as a capability mediator," with the complete capability set known statically, before execution. For agent harnesses, whose components are not merely untrusted but machine-written, access control that is structural rather than inspected is the only kind that scales — this is the same conclusion this blog reached about sandboxing (Sandboxing AI Agents, Zero Overhead Is Zero Attack Surface).

But "one door" cuts both ways, and the reflection should say so. A single context is a single point of trust: the most security-critical object in the system is now one object, and the paper's own Section 6.3 concedes the limit — capability mediation is access control over dependencies, not isolation of code. "The second requires an external sandbox," the authors write, and that admission matters: the paradigm makes every effect attributable and every dependency mediated, but arbitrary machine-generated code still needs a real sandbox around the whole room. The context is the door; the door is not the walls.

On observational equivalence and the system boundary: composability ends where the world begins

The most important thing to internalize is the least discussed: recovery means indistinguishability, and the boundary of what can be made indistinguishable is a design decision. The paper develops this as the system boundary: a location lies "inside" when the system can modify it exclusively and restore it; everything else lies "outside," and a coeffect moves the boundary by reifying an external location — confining access to operations that carry inverses, so that a file or a connection can become trackable.

For agents, this is where the theory meets the hard wall. Dynamic composition can make an agent's harness self-consistent — its in-memory registrations, its connections, its caches can all be undone. It cannot undo the world: an email sent, a payment moved, a file written outside the boundary. The guarantee is exactly as wide as the reification. The system boundary is where composability ends and accountability begins — and every agent engineer should read Section 6.1 as the map of that line. "What you expose as dependencies defines the boundary of what recovery can promise" is the paper's deepest design pressure, and it applies with double force when the code doing the exposing is generated by an agent.

On compositionality and sufficiency: the mechanics of change, not the intelligence of change

The metatheory (contribution 4) is what upgrades the paradigm from "nice plugin framework" to "foundation," and it is the property self-modifying systems need most and get least: most agent harness engineering is empirical iteration, not compositional guarantee. But the reflection must end with what the paper does not claim. Spatiotemporal composability makes change safe; it does not make change right. An agent still needs to know what to build, whether it built it correctly, and whether removing it was the right call — the intelligence of change, which is a verification problem, not a composition problem. The blog's own line of argument applies (Verifiers Are King, The Verification Horizon): composition gives an agent the ability to modify its harness without breaking it; verification gives it the ability to modify its harness correctly. A self-evolving agent needs both, and the paper has built — with proofs — one of the two halves. That is why it matters: it is the first half of the foundation, finished, proven, and shipped in production, with 4,000 plugins as the evidence.

And the other half is now a well-posed problem, which is the highest compliment a theory can pay: the paper does not close the question of self-evolving agents, it makes the remaining question answerable.

Bottom line

A Programming Paradigm for Spatiotemporal Composability is organized around the authors' five contributions — revertible effects, reactive coeffects, the unified context as a paradigm, a calculus whose metatheory composes local guarantees into system-wide ones, and a shipped implementation validated by 4,000 production plugins — built on the framing insight that dynamic composition has two orthogonal dimensions, temporal and spatial.

The reflections that matter for agentic design: the two dimensions are the checklist; structure beats discipline but only the orchestration is free; availability-as-state is the failure model agents need; the one-door context is the policy chokepoint but also the trust boundary, and it is not a code sandbox; recovery is an observational promise whose boundary the system must design; and composition makes change safe while verification makes change right. The paper is the mechanics of self-modification, proven and shipped — and the intelligence of self-modification is now a question with a theory behind it, instead of a button marked "Reload Window."

References:

• Yifan Shi, Wei Zhang, Tianyi Cui. A Programming Paradigm for Spatiotemporal Composability (Peking University / DeepSeek-AI, 2026) — the paper; 88 pages; paper.pdf. The author quotes in this post are from Sections 1.1, 1.3, 3.3, 4.4, 5.3, and 6.1–6.3.
• Cordis — the meta-framework of spatiotemporal composability: core library (effect tracking, coeffect resolution, isolation, interception) and declarative component loader (configuration reconciliation, hot module replacement).
• Koishi — the chatbot framework built on Cordis; 4,000+ community plugins over four years; koishi.chat.
• D. L. Parnas. On the criteria to be used in decomposing systems into modules (Communications of the ACM, 1972) — where the paper's composition story begins.
• D. Birsan. On Plug-ins and Extensible Architectures (ACM Queue, 2005) — plugin systems as the canonical instance of dynamic composition.
• OpenAI. Harness Engineering: Leveraging Codex in an Agent-First World — the harness as the product surface for agents.
• Anthropic. Harness Design for Long-Running Application Development — harness engineering for long-running agents.
• C. Packer et al. MemGPT: Towards LLMs as Operating Systems — the agents-as-operating-systems framing.
• L. Wang et al. A Survey on Large Language Model Based Autonomous Agents (Frontiers of Computer Science, 2024) — the agent landscape the paper cites.
• E. Moggi. Computational lambda-calculus and monads (1989) — the monadic model of effects the paper lifts to runtime.
• G. Plotkin, J. Power. Algebraic operations and generic effects (2003) — algebraic effects, the other pillar.
• T. Petricek, D. Orchard, A. Mycroft. Coeffects: A Calculus of Context-Dependent Computation (2014) — the coeffect pillar the paper operationalizes.
• Related: Sandboxing AI Agents — structural access control for agent components; Zero Overhead Is Zero Attack Surface — the coordination layer should add nothing beyond the shared room.
• Related: Verifiers Are King, The Verification Horizon — why guarantees must be structural, not remembered.
• Related: Every Token Has a Price Tag, Always-on agents — the restart tax: state loss, warm-context loss, and the cost of the coarse-grained workaround.
• Related: Agentic-first CLI design — the harness as the agent's interface to the machine; Software dark factories — agents generating the components this paradigm can compose.

dic.mcit.gov.qa is the home of Qatar's Digital Incubation Center (DIC) — the startup incubator run by the country's Ministry of Communications and Information Technology (MCIT). Its pitch, as of the 2025 snapshot of its own homepage, is short: "0% Equity. 100% Enablement."

That claim is the most important fact about the program. DIC does not take equity, it does not charge for its services, and AI is one of its named focus areas. That makes it a genuinely unusual on-ramp for AI startups: a government-funded, free, no-dilution incubation program in a Gulf state that is spending seriously on becoming an AI hub.

What the DIC is

The Digital Incubation Center is Qatar's national incubator for technology startups. It has been operating since the mid-2010s — its first intake of young entrepreneurs was announced for 2016 — originally under the Ministry of Transport and Communications, which later became MCIT. Its own words, from the 2023 snapshot of the site:

The Digital Incubation Center (DIC) was created to boost ICT innovation in Qatar, particularly among young people at the critical early stages of starting or growing a technology-related business. ... We offer startups free office space, technical support, training and guidance, mentors who can help new businesses avoid the typical start-up pitfalls...

It is funded by the state, takes no equity, and receives no payment for its services — all confirmed in the incubator's own FAQ. The homepage counters, identical in the March 2023 and May 2025 snapshots, tell the scale story:

Read the counters as directional marketing, not audited statements — and do the arithmetic once before you plan around them. "Total investment" (205.4M) divided by "average per startup per year" (3.614M) is ≈ 57, almost exactly the 60 "current startups": the "total" is a snapshot of roughly the current cohort, not a cumulative figure since 2016. Jobs work out to ≈ 4 per startup, and 76 graduates of 160 incubated is a 47% graduation rate — real, but small-team, incubation-scale. The currency is almost certainly the Qatari Riyal (pegged at 3.64 to the dollar), which puts the headline 2019 matchmaking event at QAR 22.6M ≈ US$6M.

The program funnel

The DIC's own materials describe a funnel from idea to funded company: four core tracks plus two investment-readiness programs.

IdeaCamp — the entry point: a three-week bootcamp where entrepreneurs, developers, and designers turn tech ideas into validated business plans, ending in a final pitch. The named technology areas are exactly three: IoT, AI, and Advanced Analytics. Historic outcomes: 27 of 31 competing ideas were incubated in the January 2018 cohort; 25 startups came out of the second edition in 2019.

Direct Incubation (Startup Track) — two years for early-stage startups with a market-ready product or prototype: year one takes a startup from prototype to registered business in Qatar; year two is the Growth Track.

Growth Track — one year for businesses that have already launched, "positioning startups for accelerated growth."

Coworking Space — free hot desks, internet, and facilities for entrepreneurs and small businesses.

Make the Deal (MTD) — the investor-startup matchmaking event held on the sidelines of QITCOM, Qatar's annual ICT conference. Its own page names the target technologies explicitly, with "artificial intelligence" first among IoT, smart home, augmented reality, cybersecurity, and big data. In the 2019 edition, 228 startups pitched, 15 walked away with deals, and QAR 22.6 million (≈ US$6M) was committed by 110 investors. The top single deal was US$2M.

Angel Investor Bootcamp and Startup Investment Readiness Program — the two newest tracks, visible in the site's navigation from 2024 onward: the DIC increasingly positions itself on the funding side of the funnel, teaching founders how to take investment rather than just how to build products.

The funnel is explicit: IdeaCamp turns ideas into startups. Startup Track turns startups into registered companies. Growth Track scales them. Make the Deal connects them to money. You can enter at the stage you are at.

What an AI startup actually gets

From the DIC Services page, incubation provides training, dedicated mentorship (each company gets at least one mentor, sometimes two), networking, industry contacts, investor access, internships from Qatari universities — and free office space whose details matter for AI startups: cloud hosting, a 5G WiFi network, and software licenses are listed as included facilities. The relevant parts for an AI startup are the free cloud hosting and compute-adjacent infrastructure, the 5G connectivity (Qatar is an early and aggressive 5G market), and the investor matchmaking — because the DIC itself does not write checks.

AI is a named focus area

AI is written into the program materials, not incidental to them. IdeaCamp's technology areas are exactly IoT, AI, and Advanced Analytics; Make the Deal lists AI first among its emerging-technology focus areas; the Startup Track FAQ's preferred technologies lead with cloud computing, big data, and analytics. The portfolio reflects it — the 2023 and 2025 intake lists include Ellogy AI, Speechzy (AI/ML for speaking skills), Tahado (AI-based cervical cancer diagnosis from 3D scans), Ceena Lab / BizPlanner (AI-assisted business plan generation), Ferasah (machine-learning prediction of asset failure), and Sensorways (IoT + ML equipment monitoring).

The honest caveat: most of the portfolio is marketplaces, delivery apps, and vertical e-commerce — the classic Gulf SaaS pattern. The genuinely AI-first startups are a minority. You are not joining a DeepSeek or a Mistral; you are joining a state-backed incubator where the realistic winning category is an AI application with a Qatari distribution problem — healthcare, logistics, smart city, education — not a foundation model.

The market you are actually building for

Qatar has roughly 3 million people (World Bank, 2025: 2,972,215), of whom only a few hundred thousand are citizens. No startup in this program will scale on the domestic market alone; the DIC's real value is a zero-cost base inside a well-capitalized state with an open door to regional and international investors. The strategy that fits the market:

• Arabic-language AI is the open niche. The Gulf's Arabic-capable foundation models come from the neighbors — the UAE's TII Falcon, Saudi Arabia's SDAIA ALLaM — and Qatar ships no frontier Arabic model of its own. The opening is application-layer: Arabic-first products built on someone else's model, with a local distribution problem.
• The state is the anchor customer. TASMU Smart Qatar is a national program explicitly seeking smart solutions in healthcare, transport, and environment, and the government-services layer is where Digital Agenda 2030 money flows.
• The talent pool is thin, so plan to import. QCRI/HBKU graduates are the local edge; most engineering hires will come from abroad — which the DIC's residency rule (no citizenship, no Qatari partner required) accommodates.
• Use Doha as the beachhead, not the destination. Web Summit Qatar has run in Doha since February 2024, and QITCOM carries the investor matchmaking; both are exposure channels into the wider GCC. The winning pattern: pilot with a Qatari government or enterprise customer, prove it in a small rich market, then export across the Gulf.

The money question

Three facts define the economics:

1. Zero equity, zero fees. FAQ question 20, verbatim: "No, DIC is a government-funded program. We do not take equity or receive any payment in return for our services." This is the whole point of the "0% Equity. 100% Enablement." rebrand.
2. DIC does not directly fund startups. FAQ question 5: "potential funding is available through the Qatar Development Bank and other financial institutions." The DIC is a connector, not a fund; the money comes through QDB and the investor network built around events like Make the Deal.
3. The numbers are real but modest. QAR 22.6M (≈ US$6M) across 15 startups in the best-documented Make the Deal edition (2019); QITCOM-adjacent awards pay in the QR 25,000–125,000 range. This is early-stage, incubation-scale money — enough to build and pilot, not enough to fund a frontier-lab compute bill.

Who can apply

• Residency in Qatar is the requirement — "any innovative entrepreneur with residency in Qatar." No Qatari citizenship and no Qatari partner needed.
• Idea-stage is fine. No product required to enter the pipeline; that is what IdeaCamp is for.
• Existing startups are fine. Companies with a product already launched enter the Startup Track at the appropriate stage.
• Applications are accepted year-round, with the Startup Track process taking up to three months.
• Evaluation criteria (FAQ question 10): original idea in a focus area, market opportunity, target customers and validation, initial cost structure and financial plan, team profile.

The application form asks the one question that matters: "If you require funding, please estimate the amount, and how you would use the funding."

The Qatar AI context

The DIC sits inside a state that has spent the last half-decade positioning itself as the Gulf's neutral, well-capitalized AI hub: the 2019 National AI Strategy made AI an explicit national priority; Digital Agenda 2030 is MCIT's umbrella for the digital transformation, with the DIC as the startup-facing layer; Web Summit Qatar has run in Doha since February 2024, bringing international investors to the market. Around the DIC sit the Qatar Development Bank (funding), QBIC (explicitly named as a collaborator in the DIC's FAQ), Bedaya, Qatar University, and the research layer of QCRI at HBKU with its Qatar Center for AI (QCAI).

The strategic logic of the zero-equity model: the state wants technology companies formed and staying in Qatar, so it underwrites the incubation cost rather than taking a stake. For a founder, that is the best possible terms sheet — provided you actually want to build for the Qatari market.

Bottom line

The DIC is a real, well-documented, zero-equity incubator that names AI among its focus areas, offers free office space with cloud hosting and 5G, and funnels startups toward Qatari money through the Qatar Development Bank and its own investor matchmaking. For an AI startup willing to build for the Qatari market — healthcare, logistics, education, government services, Arabic-language applications — the terms are genuinely good.

Keep the frame honest: this is a local-market incubator with an AI label and excellent terms, not a research lab. The winning move is an AI application with a Qatari distribution problem to solve — Arabic-language and vertical applications, not foundation models and not consumer scale.

References:

• DIC homepage (Wayback, 27 Mar 2023) — mission, stats counters, program tracks, startup lists.
• DIC homepage (Wayback, 29 May 2025) — "0% Equity. 100% Enablement", current program descriptions, 2025 intake list including Ellogy AI.
• Startup Track page with full FAQ (Wayback, 10 Jun 2023) — eligibility, evaluation criteria, no-equity policy, Qatar Development Bank funding, application process.
• IdeaCamp page (Wayback, 10 Jun 2023) — technology areas (IoT, AI, Advanced Analytics), workshop schedule.
• DIC Services (Wayback, 9 Jun 2023) — training, mentorship, networking, investors, office space (cloud hosting, 5G WiFi, software licenses).
• Make the Deal (Wayback, 10 Jun 2023) — AI among focus technologies, matchmaking format.
• Over $6 million invested into tech startups at QITCOM (Wayback, 10 Jun 2023) — QAR 22.6M / US$6M, 228 startups, 15 winners, investor names.
• MoTC Announces Winners of Entrepreneurship Zone Awards (Wayback, 10 Jun 2023) — QITCOM 2019 awards and cash prizes.
• 27 New Ideas Win Incubation (Wayback, 10 Jun 2023) — 2018 cohort outcome.
• Digital Incubation Center to Welcome First Intake for 2016 (Wayback, 10 Jun 2023) — founding-era framing and service list.
• Qatar population, World Bank Open Data — 2,972,215 (2025).
• Qatar Center for Artificial Intelligence (QCAI) — QCRI's AI center: foundations & systems, precision health, social good.
• Qatar Computing Research Institute (QCRI) — the research layer for AI and Arabic NLP at HBKU.
• TASMU Smart Qatar — national smart-solutions program (healthcare, transport, environment).
• Falcon LLM (TII, UAE) — the Gulf's open Arabic-capable foundation model.
• Qatar — National AI Strategy (2019) — national AI strategy context.
• Related: The UAE's Human Stack — the neighbor's education-first sovereign AI play; Hangzhou AI City — the exception that proves the dependency-stack rule; AI Sovereignty Is Freedom.

In 2011, a software team at Hunter Industries in Southern California needed to restart a project that had been on hold for months. A few members and a contractor had worked on it; most of the team had not. They gathered in a meeting room to review the code and decide how to take the work on — and somewhere in that review, out of a habit of pair programming and TDD practice sessions, they started passing the keyboard around. After several hours another group needed the room, so they moved, held a mini-retrospective, and agreed the day had been remarkably productive. They booked the meeting room again. Two weeks later they were still working that way, and they had a name for it: mob programming. Woody Zuill presented it to the Agile Alliance in 2014.

Fifteen years later, teams gather again — not around a projector and a single keyboard, but inside a shared live agent session: the same files, the same terminal, the same browser preview, open to everyone at once, anyone able to steer. The products call it multiplayer AI. The name is new. The shape is not.

Multiplayer AI for coding agents is not a new way of working. It is mob programming, remastered — with the driver replaced.

This sounds like marketing fluff until you take the architecture seriously. Mob programming's entire structure — one shared surface, a driver and navigators, the strong-style rule, single-piece flow, continuous code review — maps one-for-one onto the shared agent session. And the objection that dogged mob programming for fifteen years — "how can five developers be productive on one computer?" — has reappeared, word for word, as the objection to shared sessions: "why not just run more agents in parallel?" The data answers both the same way, because the bottleneck was never typing. It was review.

The mob's lineage

The 2011 meeting room was not a beginning. It was the latest turn in an evolution that had been running for more than a decade — the story of an idea that kept getting re-housed: many minds on one surface, and only one pair of hands on the code at a time, so that everyone else had to think out loud. Follow that constraint, and the whole history unfolds in acts.

1999 — the pair. Kent Beck's Extreme Programming Explained made "two programmers, one computer" the centerpiece of a new way of building software: one person's hands on the keyboard, the other's eyes and voice on the code — the split mob programming would later formalize as Driver and Navigator, carrying the claim, radical at the time, that two minds on one task beat two minds on two tasks. XP gave the idea its first vehicle. The pair was the smallest possible mob.

2005 — the dojo. Six years later, in Paris, Laurent Bossavit and Emmanuel Gaillard founded the Coding Dojo, borrowing the language of martial arts on purpose: the dojo is the training hall, the kata is the practice form, randori is free-form sparring. Groups met to practice on a single computer with a projector, passing the keyboard every few minutes the way sparring partners trade roles. The dojo's discovery was that the constraint itself teaches: with one keyboard and many people, no idea enters the code until it has been spoken. It was practice, not production. But the seed was planted.

2011 — the mob gets its name. Zuill's team at Hunter Industries had been running TDD and pair-programming practice sessions as dojos, and when they gathered to restart a project that had been on hold for months, the habit took over — "we started passing the keyboard around," Zuill later wrote. What began as a review meeting became two weeks of meetings, became a way of working. "All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer" — that was how the team described what they had stumbled into, and someone proposed the most memorable name anyone could offer: mob programming. It stuck, which was the practice's first taste of its own marketing problem; the word "mob" would spend the next decade being fought.

2014 — the canon. Zuill's Agile2014 experience report gave the practice its founding text: the Driver/Navigators pattern adapted from Llewellyn Falco's strong-style pairing — "for an idea to go from your head into the computer it MUST go through someone else's hands" — the list of problems that simply "fade away," and the claim that the team delivered roughly ten times as many projects the year after adopting the mob. Then came the tour: Zuill and Falco crisscrossed conferences and code retreats, mobbing live on stage. It was the practice's peak of visibility, and it was still a niche — the name was winning and losing at the same time.

2018 — the rename. Maaret Pyhäjärvi proposed "ensemble programming." Mob carried baggage — crowds, violence, mob rule — and ensemble named what the practice actually was: the whole team, all its skills, one surface, playing together. The rename is the tell that the practice had matured into a discipline with a canon and a community — and an identity problem it could not quite solve. Ensemble stuck in the corners where the practice survived: agile meetups, code retreats, the teams that refused to give it up.

2020 — the remote mob. Simon Harrer, Jochen Christ, and Martin Huber systematized the distributed mob: cameras always on, a ten-minute typist rotation, git handoff at every interval, decisions made by the group. They claimed the distributed version was "superior to anything we ever tried before." But the discipline tax was heavy — cameras on, voices metered, a handoff every ten minutes — and most teams paid it for a sprint, not for years.

The plateau. By the late 2010s, mob programming was a conference-circuit staple that never became mainstream. Not because it failed on its own terms — the teams that mobbed kept mobbing — but because its benefits were structural and its costs were visible, and management's arithmetic counted only the costs. Five minds on one keyboard looked like waste from the outside, and the practice remained what it had been since the dojo: a discipline of believers.

2026 — the remaster. And then the constraint that mob programming had enforced socially became the architecture of a tool. The shared live agent session is one surface, many navigators, a single driver — with the driver now a model that types at machine speed. The line of evolution completes itself. Every step kept the surface singular and made the driver more mechanical: a pair of people, a passing keyboard, a rotating typist, a remote screen-sharer — and finally an agent.

A remaster does not rewrite the song. It takes the original master tape and re-engineers it with modern tools — same performance, cleaner delivery, new instruments. The industry calls multiplayer AI a new way of working, which is like calling a remaster a new song. The master tape is mob programming, and the master tape was always the point.

What mob programming actually is

The Agile Alliance's glossary defines mob programming as "a software development approach where the whole team works on the same thing, at the same time, in the same space, and on the same computer." One work item at a time. Continuous code review, whole team involvement, self-organizing teams. Almost all work happens in "working meetings" — defining stories, designing, testing, even working with the customer.

The operational core is the Driver/Navigators pattern. Two roles. The Driver sits at the keyboard and types — "a much more mechanical job" — and must trust the Navigators. The Navigators discuss the idea and guide the Driver "in a slow, metered approach," speaking "at the highest level of abstraction that the Driver is able to digest" at that moment. A timer rotates the driver every ten to fifteen minutes. The result, Zuill writes, is "a sort of collective intelligence of the Navigators."

The benefits are best stated negatively. Mobbers don't claim the mob adds productivity; they claim problems "fade away": communication problems (waiting for answers, back-and-forth email, misunderstanding via documentation); decision-making dysfunctions (reluctance to decide, the need to defend decisions); the waste of doing more than barely sufficient; technical debt, because "many sets of eyes" sit on the current work as it is written; thrashing, because single-piece flow means no one is switching contexts; workplace politics; and "management by meetings," with its separation of decision-making from knowledge creation.

And then there is the question everyone asks. Zuill quotes it directly: "How can 5 or 6 developers be productive while working this way? Wouldn't it be more productive to have them working on different things?" His answer, offered with appropriate caveats: the year after the team adopted mob programming, it delivered roughly ten times the number of projects it had delivered the year before. The point was never that five people on one keyboard is fast at typing. It was that typing was a rounding error against the cost of misunderstanding, and the mob spent its effort where the money was.

What multiplayer AI actually is

By 2026 the single-player agent is the incumbent. Claude Code, Codex, Cursor: each is a private channel between one developer and one model — one person, one terminal, one context window, one transcript. Work exits the channel as a package: a diff, a pull request. The agents are everywhere — installed in 75 percent of Linear's enterprise workspaces, per The Register — which is exactly why the layer around them is now the bottleneck. The industry's first answer to the coordination problem was to run more of them: parallel runners, worktree managers, cloud agents, fleets. Coshell's verdict on that strategy is the sharpest one-sentence critique in the space: "That is more parallelism, not more collaboration. It is still single-player, just with more players who cannot see each other."

The 2026 multiplayer wave is a different bet: make the session itself the shared place. AQ — the "multiplayer coding harness" — defines the category as "AI coding agents whose working sessions are shared, live places that a whole team can enter: everyone sees the same running agent, the same terminal, the same code, and the same app preview, and anyone can steer." Coshell: "Multiplayer AI coding is when several engineers prompt one shared, live AI agent working in a single cloud workspace"; the analogy the industry keeps reaching for is "closer to a Google Doc than to git." collab, a small open-source Go CLI, does it peer-to-peer: "Two devs. Two agents. One session" — each developer keeps their own agent and their own API key, and the two agents share a conversation log and a ./shared/ directory across the wire.

AQ's test for what counts is the right one: a tool is multiplayer when the running session, not just its output, is shared — the same live session (not a replay, not a read-only transcript); anyone can steer mid-run, "the way anyone can grab a marker at a whiteboard"; handoff without re-setup; roles beyond engineers (a PM or designer can watch the preview and push feedback without touching a terminal); outsiders can look. Screen sharing fails the first test — one person still owns the session. Shared tmux over SSH passes the first two and fails the rest.

Why this exists is a measured fact, not a pitch. A July 2026 LeadDev analysis of 25,264 agent-generated pull requests across 2,361 popular repositories found that in 79 percent of agentic PRs, the same developer both reviewed and modified the agent's contribution — and only about one in eight agentic workflows involved more than one human at all. The loop closed structurally, in three steps: the agent session lives in one person's private transcript; the PR is the only artifact that escapes it; and the prompter becomes the reviewer, reading the diff through the memory of their own prompt. As AQ puts it: "The decisions that determine whether agent work is good live in the session, not in the diff. A review process that cannot see the session is auditing the residue of the work rather than the work."

The self-review problem is not new. It is the pre-mob problem set — one person's cubicle, one person's understanding, one person's review — recreated at scale by the tool that was supposed to give everyone a teammate. Mob programming was invented precisely because that arrangement has a ceiling. Multiplayer AI is the industry rediscovering the mob's answer, in the medium that forced the question.

Why the shared layer exists at all is an industry-structure question, and it is worth being clear-eyed about. The model vendors are structurally disincentivized from building it: Anthropic shipping Agent Teams, and the steady drift toward "Claude Code for teams," point toward collaboration inside one model's session on one vendor's terms. The layer between people — many models, many providers, your own git — has to be neutral to be useful. That is why the multiplayer products are an independent layer (Coshell, built on the open-source OpenCode engine; AQ; the peer-to-peer collab) rather than a vendor feature. The mob needs a room, and the room cannot belong to the driver.

Why the mob is back now

If multiplayer AI is the mob's endpoint, why is the endpoint arriving in 2026 and not in 2018, when mob programming was a conference-circuit staple? Three forces.

The waste objection died. The mob's killer objection — five minds, one keyboard — assumed the driver's time was the scarce resource, and management arithmetic said it was. The agent era inverts the mob's cost structure. The driver is now a model that types at machine speed, never tires, and never gets bored; the scarce resource is what the navigators contribute — the articulation, the judgment, the verification. "One agent, many navigators" is no longer five salaries idle; it is five minds loaded onto a machine that works faster than any of them. The objection that kept mob programming out of the enterprise was an accounting artifact, and the accounting changed.

Remote work killed the room. Mob programming was a room practice, and the remote mob that kept it alive demanded more discipline than most teams had. The shared agent session is the first mob room that is easier to enter than a video call: a link, and the environment is already there, loaded, warm. The remote mob's hardest problems — handoff, shared state, who sees what — are precisely the problems the session solves mechanically.

The single-player agent recreated the disease the mob was invented to cure. This is the one nobody chose. The tool that was supposed to give every developer a tireless teammate instead recreated the cubicle: one person, one private transcript, one self-review, 79 percent of agentic PRs. The industry ran a fifteen-year control experiment on the null hypothesis — everyone in their own session, working on their own thing — and measured the result at scale. The null hypothesis lost. The mob is back because the alternative failed on its own terms.

Same shape, new driver

Run the mapping and it holds at every layer.

Same surface. The mob's rule was "all code that enters the code base is input through this single computer." The multiplayer rule is that all code enters through the session. One place, many minds, everyone watching the same thing at the same time.

Same roles. The agent is the driver; the humans are navigators, permanently. Read Zuill's description of the navigator's job and it reads like instructions for prompting an agent: express the idea "in a slow, metered approach," speak "at the highest level of abstraction that the Driver is able to digest," guide without touching the keyboard. In mob programming you could not type because the keyboard belonged to the driver. In a shared agent session you cannot type because there is no keyboard — there is a prompt. The social role has become the interface.

The industry files this under pair programming, and the categories say otherwise. AQ's FAQ: "Pair programming shares a human's editor. Multiplayer coding agents share an agent's working session: the humans present are steering an AI that does the typing." But pair programming is two people, one editor, one conversation. Mob programming is the whole team on one surface, one work item at a time — and the multiplayer test's own criteria, roles beyond engineers and outsiders in the room, are mob criteria, not pair criteria. What AQ described is mob programming's Driver/Navigators pattern with the rotation removed. Call it multiplayer if you like; the architecture is a mob room, not a pair table.

Same constraint. The strong-style rule — an idea must go through someone else's hands — was mob programming's hardest discipline, and it was social: the team enforced it on itself, person by person. In multiplayer AI it is architectural. The only hands on the code belong to the agent. You cannot drift, you cannot grab the keyboard, you cannot produce output you did not first articulate. This is the least noticed and most profound property of agentic coding: mob programming needed a norm to guarantee what the agent tool provides by construction.

Same objection, same answer. "Why not parallel agents?" is "why not have everyone in their own cubicle?" with better branding. It fails at the same point: the work is generated in private and reviewed at the end by whoever generated it. The 79 percent figure is the quantified version of the problem set the mob was built to make fade away.

Same fading problems. Communication: the session is the artifact — "what is it doing?" questions die because everyone watched it happen; there is no back-and-forth email, there is the scrollback. Decision-making: the whole team steers, in the open, with the current information, and the transcript preserves the reasoning. Waste: single-piece flow on one work item. Technical debt: many sets of eyes on every line, live, not at PR time. Thrashing: nobody re-ingests the codebase from cold — Coshell's point that a shared warm context is loaded once for the team rather than re-read per person is the token-economics version of the mob's anti-thrashing argument.

The two figures above are the whole argument in pictures: the mob's topology, and the cost of abandoning it.

What the remaster changes

A remaster keeps the original; it also changes the delivery. Five deltas are genuinely new.

The driver never rotates. In mob programming, the rotation existed so everyone got the driver's seat — the learning and the engagement, not just the typing. In multiplayer AI the driver is always the agent, so the humans are all navigators, all the time. That is a pedagogy change with a measured price, and this blog has covered it: in You Don't Learn What You Delegate, a pre-registered randomized trial found that delegating to an AI cut learning by 17 percent (d ≈ 0.74) — and the damage concentrated exactly where the mob's navigators need skill most: debugging. The mob's driver rotation was how a team learned by doing. A mob with a permanent driver must learn by articulating and reviewing instead. The mob still teaches — it teaches navigation, not typing. But the team that lets the agent drive while the humans spectate has stopped mobbing and started watching.

The mob admits non-human navigators. Zuill's navigators were all people. A shared session's navigators can be agents: a verifier subagent that checks the diff as it lands, a reviewer agent that reads the session's scrollback, an always-on agent that patrols the repo overnight. This is the direction Anthropic's multi-agent research system pointed at in 2025 — subagents with their own context windows, exploring in parallel, compressing their findings back to a lead — with the observation that "groups of agents can accomplish far more." Mob programming at that scale is mob programming where the mob itself has scaled past human attention. And it makes the navigator's job, verification, the expensive and decisive one — the thesis of this blog's Verifiers Are King and The Verification Horizon. In a mob of agents, the driver is cheap; the navigators are the product.

The mob has perfect memory. Face-to-face mob memory was perishable: what the team agreed at the whiteboard at 10 a.m. lived in their heads at 4 p.m., if it survived at all. The shared session is the memory — the transcript, the scrollback, the dead ends, the decisions. AQ's review guidance is blunt about why this matters: "Dead ends are signal: they mark the parts of the codebase the agent found confusing, which is where the surviving code deserves the closest reading." collab's motivation is the same point from the loss side: "By the time the diff lands in a PR, the chain of thought that produced it is gone." The mob's knowledge no longer leaves at 5 p.m.; it stays in the room, reviewable.

The mob never sleeps. The session persists. A teammate joins from another timezone mid-run and finds the work where it was left, environment, history, and running processes intact — the "handoff without re-setup" test. This is the always-on agent economy this blog has written about before (Always-on agents), except the always-on entity is the mob itself, and humans are the visitors.

The one-keyboard rule must be re-imposed in software. This is the deepest point. The physical mob's single-writer guarantee was hardware: one keyboard. The moment agents run in separate sessions over the same repo, the guarantee disappears — two agents can reach for the same lines of the same file, and the engine underneath is last-write-wins. Coshell's overlap control is exactly the mob's rule rebuilt as a protocol: "the second edit is held before it lands, and a coordinator steers that agent to proceed if the changes are compatible, or to take other lines, wait, or let the first land first." The mob's most important property is no longer enforced by furniture; it is a design problem, and it is the entire job of the coordination layer. Multiplayer agents relate to mob programming the way flying machines related to bird flight: the constraint that made the original work — one writer at a time — had to be rediscovered in the new medium before anything could fly.

The Society of Mind

In 1986 — forty years before the shared agent session, twenty-five years before the mob got its name — Marvin Minsky published The Society of Mind, and in doing so described the mob's architecture in advance. Minsky's claim is that intelligence is not one big thing. It is a society: many small, mindless parts, which he called agents, interacting until the whole does what no part can do alone. There is no homunculus, no little person inside the head doing the thinking. "What magical trick makes us intelligent?" he asked. "The trick is that there is no trick. The power of intelligence stems from our vast diversity, not from any single, perfect principle."

Run that thesis against the mob and it reads like a design document for what Zuill's team stumbled into in 2011:

• The navigators are Minsky's agents. Each holds part of the problem and knows almost nothing about the rest — that is the point. The mob's "sort of collective intelligence of the Navigators" is the society doing what no single member can: no navigator builds the product alone; the product is what the connections produce.
• The strong-style rule is Minsky's communication problem made social. An idea only enters the code through someone else's hands — through articulation. Minsky spent most of the book on how agents connect, because intelligence is not in the parts; it is in the connections. The one-keyboard rule exists precisely to force the connection.
• The driver is the anti-homunculus. Minsky's core methodological warning was the homunculus fallacy — explaining the mind by hiding a smaller mind inside it. The mob's driver is explicitly "a much more mechanical job": hands without a mind. In the session era it is genuinely mechanical — a model. Nobody explains the mob's intelligence by pointing at the driver, because there is no intelligence there to point at. It all lives in the society. That is the whole point of the exercise.

Then notice the vocabulary. The word Minsky chose for his mindless parts — agent — is the same word the industry uses for the things now sitting in the mob's navigator seats. The lineage runs from Minsky's 1986 agents through the software-agents literature of the 1990s to the model agents of the 2020s, and the session is where the metaphor stopped being a metaphor: the society is now a literal one, human navigators and model agents in one room — subagents with their own context windows, verifier agents, always-on patrols, the Anthropic multi-agent system referenced above. Minsky's society got machines in it. And the discipline that keeps mindless parts from producing a mob in the bad sense is the same in all three rooms: checking. Mindless parts do not make a mind until something verifies them — which is the navigator's job, and the reason the session's scarce resource is verification, not generation (Verifiers Are King, The Verification Horizon).

The man who named the mob has spent the years since 2011 telling this story in person. At DDD Europe in 2024 — forty years after Minsky's book, thirteen years after the mob got its name — Zuill gave Advanced Software Teaming, the full account from the founder: the dojo lineage, the Driver/Navigators pattern, the problems that "fade away," and why the practice outlived its objections. It is the primary source for this post's central claim — that the shared agent session is mob programming, remastered, with the society of mind run as an actual society.

Forty years after the theory, the society of mind is no longer hypothetical. It is a room you can join, the driver's seat held by a machine, the mind spread across everyone and everything in the session — checking each other, which is the only way mindless parts ever made anything intelligent.

How to run an agent mob

Mob programming's fifteen years of practice boil down to a small set of disciplines, and each has a direct translation into the session era. The cheat sheet:

One session, one work item. Single-piece flow survives unchanged: start, work on, deliver one item before the next. The session is the unit of flow now — when the session wanders, the mob wanders.

Invite the reviewer before the code. In mob programming, review happened because everyone watched every line. In the package model, review happens at PR time and fails (the 79 percent). The translation: the second set of eyes should be in the session, not on the diff. Make "someone other than the prompter ran the result" the definition of done. Where to spend that attention is the mob's instinct made explicit: review effort concentrates where the session shows the agent struggled, not where it sailed through.

Prompt at the highest level the driver can digest — then verify the step. This is Zuill's instruction for navigators, verbatim, now the interface: express the next step at the right abstraction, and do not let the driver run ahead of your ability to check it. Small steps, metered, the way the mob did it.

Rotate the navigator roles, not the driver. The driver no longer needs the rotation; the humans do. Rotate who steers the session, who verifies the agent's work, who reads the scrollback for dead ends, who speaks for the customer. The mob's learning loop — everyone takes the seat — moves from the keyboard to the roles around it.

Hold the retrospective on the transcript. The mob's "turn up the good" ritual has a new artifact to review: the session itself. Where did the agent go wrong, and how did we steer it back? Which prompts were unclear? What did we almost ship that looked right and was not? The transcript is the first mob memory that can be reviewed by people who were not in the room.

Keep it chosen. The mob's first rule transfers intact: it only works if the team chooses it. A session that is imposed is not a mob; it is a panopticon.

The honest costs

Mob programming's glossary entry comes with a pitfalls section, and it transfers almost unchanged. Constant collaboration all day is not for everyone. And above all: "Mob Programming will only work if the team sees value in this approach and chooses to work in this manner... the change will not be nearly effective if people feel they are being forced to make the change." The same is true of shared sessions. The moment a shared session is imposed for surveillance — who steered, who typed the prompt, who was idle — the navigators stop navigating and start performing. The mob's first sign of use is "kindness, consideration, and respect"; a multiplayer tool that tracks instead of hosts will earn the 79 percent problem back, now with dashboards.

And the discipline is not optional. A swarm of parallel agents in one repo without single-piece flow is a mob in the bad sense: uncoordinated, clobbering, review by firehose. Mob programming's norms are precisely what keep a multi-agent session from degenerating into chaos — one work item at a time; anyone can steer; continuous review; frequent retrospectives, because the team "always turn[s] up the good"; participation that is chosen, not coerced. The practice has fifteen years of accumulated thinking about how to make many minds work on one thing. The products are months old. The products will need the practice more than the practice needs the products.

And a new contagion replaces the old one. The glossary warns that a mob working in close physical proximity spreads illness; the session mob has its own epidemiology. Shared context is shared attack surface: a prompt injection in one transcript, or a poisoned artifact in the shared workspace, travels to everyone who joins the session — and unlike a cold, it is engineered, and it is aimed. Sandboxing the room is not optional infrastructure; it is the mob's hygiene (Sandboxing AI Agents, Zero Overhead Is Zero Attack Surface).

The mob was never about the keyboard

Mob programming was dismissed for years as a waste of five minds and one keyboard. The five minds were the point. The keyboard was the constraint that forced them to think out loud — that made articulation, and therefore review, and therefore shared understanding, unavoidable. Every artifact of the mob's discipline — the driver who cannot act on an unspoken idea, the navigators who must speak at the highest level the driver can digest, the many eyes on every line as it is written — is the same constraint doing its work from a different angle.

Multiplayer AI re-imposes that constraint in software — mob programming, remastered: a driver that never tires, navigators who never have to wait their turn, a session that remembers everything, and a mob that does not go home. The industry is calling it multiplayer because the tooling changed. The reason it will matter is that the practice did not change — it was waiting for a driver that never needs to be rotated. In 2026, the driver arrived. The mob is back, and this time it never leaves.

References:

• Marvin Minsky. The Society of Mind (Simon & Schuster, 1986) — intelligence from the interaction of mindless agents; the homunculus warning; the word "agent."
• Kent Beck. Extreme Programming Explained: Embrace Change (1999) — pair programming, the seed of the Driver/Navigator split.
• Laurent Bossavit, Emmanuel Gaillard — the Coding Dojo (Paris, 2005): groups practicing kata on a single computer with a projector, keyboard passed in randori style. The dojo is the direct ancestor of the mob's one-keyboard constraint.
• Agile Alliance. What is Mob Programming? — glossary entry: definition, expected benefits, common pitfalls, signs of use, origins (Hunter Industries, 2011; Zuill's Agile2014 report). Source of the definition and pitfalls quoted in this post.
• Woody Zuill. Mob Programming — A Whole Team Approach (Agile Alliance Experience Report, 2014) — the Driver/Navigators pattern, the strong-style rule, fading problems, and the ~10x projects-delivered comparison.
• Woody Zuill. Advanced Software Teaming [Mob Programming] (DDD Europe, 2024) — the founder's full account of the practice; the primary source for this post.
• Llewellyn Falco — strong-style pairing: "for an idea to go from your head into the computer it MUST go through someone else's hands," as adapted by Zuill.
• Maaret Pyhäjärvi — Ensemble Programming Practiced (Pragmatic Bookshelf, 2023): the "ensemble programming" rename (2018), emphasizing the whole team, all skills, one surface.
• Simon Harrer, Jochen Christ, Martin Huber. Remote Mob Programming — the distributed mob: cameras always on, ten-minute typist rotation, git handoff; "superior to anything we ever tried before."
• AQ. What are multiplayer coding agents? (updated Aug 2026) — the definition, the "package vs place" distinction, the multiplayer test, the July 2026 vendor map, and the Linear/Register adoption figure.
• AQ. The self-review problem (Jul 2026) — LeadDev's analysis of 25,264 agent-generated PRs; session review as the fix; "auditing the residue of the work."
• Coshell. Why multiplayer — shared live sessions, overlap control, warm shared context, "more parallelism, not more collaboration," and why the layer between people has to be neutral.
• collab. Multiplayer for AI coding agents — peer-to-peer shared sessions across Claude Code/Codex/Cursor: "Two devs. Two agents. One session."
• Anthropic. How we built our multi-agent research system (Jun 2025) — subagents, parallel context windows, "groups of agents can accomplish far more."
• Related: You Don't Learn What You Delegate — the 17% learning cost of delegation (d ≈ 0.74), concentrated in debugging, when the agent does the typing.
• Related: Verifiers Are King — in agent work, verification is the bottleneck the mob's navigators must fill.
• Related: The Verification Horizon — why verifying agent output is harder than generating it.
• Related: Always-on agents: state, memory, and the governance gap — the session as persistent state.
• Related: Sandboxing AI Agents — the mob room's hygiene: shared context is shared attack surface.
• Related: Zero Overhead Is Zero Attack Surface — why the coordination layer should add nothing beyond the shared room.
• Related: Software dark factories: specs in, software out — the factory the mob now runs.
• Related: Every Token Has a Price Tag — why the shared warm context is also a shared budget line.

About 250 years ago, something spectacular happened to the way we make things. We started using machines on a large scale. Mechanization, the division of tasks, the steam engine, the power loom — and the technologies came together in a single physical space where workers operated them in a system of distinct tasks. The factory stood at the center of the Industrial Revolution, and the countries that industrialized surged ahead at a pace never witnessed before. Jostein Hauge, a development economist at Cambridge, opens The Future of the Factory with this history to make a deliberately unfashionable claim:

The main ingredient [in the recipe from poor to rich] has always been the same: industrialization. Countries that have undergone this transformation have strengthened their capabilities in manufacturing and factory-based production. Industrialization has come to be seen as the foundation of technological progress, innovation, international competitiveness, and rapid growth in productivity.

And then the question his book exists to answer: is that still true? "Megatrends" — trends in technology, economy, society, and ecology with global impact — are changing how countries develop, what technological progress means, and whether traditional industrial policy still works. Hauge identifies four that matter, and his verdict on them is the most useful thing in the book: some change industrialization less than people fear, and some change it for real.

The rise of services: complement, not replacement

The first megatrend is a paradox: most of today's "industrialized" countries do not have much industry, measured as a share of output. Services now represent more than sixty percent of world GDP. The world's largest and most profitable companies — Amazon, Google, Walmart — hardly manufacture anything, and even the great manufacturing firms get most of their profits from activities classified as services: research and development, industrial design, retail, marketing. Apple is the world's most valuable manufacturing company and owns essentially no factories. Countries in the global South are riding on service-led growth — India, Kenya, the Philippines, Rwanda.

The conventional reading says this overturns the old model: if services can drive growth, why bother with factories? Hauge's reading is the opposite. The rise of services was driven largely by ICT, which made productivity growth achievable in digital services and made services tradable — the cost of trading services has fallen to the level of trading goods. But services do not replace the manufacturing sector's special properties: the scope for productivity growth, innovation, spillovers, and trade that manufacturing provides to the whole economy. Tapping services for innovation and trade is right; treating them as a substitute for industrialization is a category error. The backbone does not move.

Digital automation: reorganization, not apocalypse

The second megatrend is the one this blog obsesses over: AI and digital automation. The worry is that automation will displace jobs at a pace not seen before, and that manufacturing-led growth is therefore dead as a development strategy. Hauge's reading is more historical. For decades, computer-based automation was limited by the need to codify every operation — it struggled with abstract thinking, manual adaptability, situational awareness. AI relaxes that constraint, but the historical pattern of technological change has been reorganization of the labor force rather than mass displacement: machines eliminate some tasks, create others, and change the skills in between. The fourth industrial revolution, he insists, is not a fourth industrial revolution — it is continuing developments in digital technologies.

There is a genuine concern buried in the reassurances, and it is the one that matters for development: studies consistently find that jobs in the global South are at higher risk of automation than jobs in the global North, precisely because routine manufacturing jobs are the most automatable. The reorganization will not be distributed evenly. The countries that industrialized on labor-intensive manufacturing — the classic late-development path — are the ones whose comparative advantage automation targets first. The factory is not dying, but the specific deal that let East Asia industrialize — cheap labor doing routine assembly — is a deal whose terms are expiring. This blog's own evidence base makes the point at the level of individual workers: the trial covered in You Don't Learn What You Delegate found programmers who delegated their learning scored 17% lower on what they were supposed to learn. Automation does not merely replace the task; it can remove the learning the task used to provide.

Globalization of production: the real challenge

The third megatrend is where Hauge's argument sharpens from contrarian to critical. Production systems have become globally fragmented: tasks and activities dispersed across networks of firms in many countries. The iPhone is "made" by Apple, which owns no factories of consequence; the parts come from Japan, South Korea, and Taiwan — Toshiba, Samsung, Intel, Sony, SK Hynix, LG, Qualcomm — and the assembly happens in China, performed by Taiwanese contract manufacturers like Foxconn. Complex value chains like this now produce practically all the stuff consumed in the global North. And despite the deglobalization headlines of the post-COVID, post-Ukraine era, the globalization of production is still going strong.

The consequences are not neutral. Global value chains exacerbate power asymmetries in the world economy in favor of the transnational corporations that govern them, and they squeeze profit margins for the workers, firms, and countries at the bottom of the chain.

The smile curve makes the structure visible: value added is high at the ends of the chain — R&D, design, branding — and low in the middle, where assembly happens. And the smile is deepening: the ends are capturing more, the middle less. Assembly is where the global South sits in the chain, and its share of the value is falling. The globalization of production is not the neutral spread of opportunity its promoters promised; it is a structure of governance in which the rules favor the rule-setters. This is the megatrend that genuinely makes traditional industrialization harder — not because factories are obsolete, but because the value they capture is being concentrated at the design and brand ends of the chain, which are not where late industrializers start.

Ecological breakdown: the other real challenge

The fourth megatrend is the one most development economics ignores and the one Hauge insists must be faced. We are living in an age of ecological breakdown: climate change, driven mainly by the emission of greenhouse gases in energy use, plus the quieter plunder of the planet's resources — biomass, fossil fuels, metals, non-metallic minerals. Even if the world fully decarbonized, that would do little to reverse deforestation, soil depletion, overfishing, unsustainable extraction, and mass extinction, which have more to do with the constant growth in material output than with the carbon content of energy.

The uncomfortable implication is that industrialization and ecological sustainability may be in tension. The countries that industrialized first got there by burning the planet's budget; the countries that want to industrialize now face the bill. Hauge's proposal is not to deny the tension but to discuss it honestly, including the possibility of giving some countries more "ecological policy space" than others, given how unequal national responsibility for ecological breakdown is. The global North caused the breakdown; the global South bears the worst of its impact, and the constraint falls hardest on the accumulation and productivity growth that late industrialization requires.

Power and politics over technology

The book's core contribution is the lens, not the list. Hauge deliberately analyzes the megatrends not only through mainstream economics but through heterodox economics, political economy, innovation studies, sociology, and political ecology — and the conclusion that falls out is that power asymmetries in the world economy have as much, if not greater, impact on industrialization pathways than new technologies in and of themselves.

That is the sentence worth taking seriously in the age of AI. The dominant framing of technological change is technological: models improve, automation spreads, productivity rises, and countries adapt. Hauge's framing is political: the question is not only what the technology can do, but who governs the chain, who sets the rules, who owns the design end of the smile, and who is left with assembly. The same lens this blog has applied to AI — who owns the compute, who captures the value, who sets the rules of the agent economy — is exactly the lens Hauge applies to manufacturing. The factory is a governance structure as much as a production structure, and it has always been.

Industrial policy for the future

Which is why his final chapter is about industrial policy, not technology. If power shapes industrialization, then the state's role is not optional. Hauge charts pathways for a new industrial policy: targeted, capability-building, willing to use the full instrument set — not the generic "improve the business climate" advice that dominated the last era of development orthodoxy. And it must operate in the ecological space: industrial policy that ignores the planetary budget is designing for a world that no longer exists. The future factory, in his conclusion, is not the factory of robots replacing everything; it is the factory remade — cleaner, more automated, embedded in value chains whose governance is contested rather than assumed, and still the place where countries build the capabilities that prosperity is built on.

The software factory

The book is about physical manufacturing, and it is worth ending by pointing the lens at the next factory. The software industry has already industrialized: code is produced in factories — the dark factories this blog has documented, where agents take specs in and software comes out. Apply Hauge's four megatrends to the software factory and the pattern repeats almost exactly.

The term itself is older than the AI era, and its history carries the same pattern. "Software factory" appears explicitly in the official report of the 1968 NATO Software Engineering Conference in Garmisch (7–11 October 1968), where Robert W. Bemer's working paper Machine-controlled production environment was described as the most ambitious tooling proposal presented — Bemer called it a "machine-controlled production environment, or software factory." His factory was supposed to provide a controlled environment in which program construction, testing, and use occurred: a file system, compilation, test-system construction, final-system building and distribution, documentation, software indexes, dependency graphs, quality control, instrumentation, scheduling, and costing. The Computer History Museum's archive of Bemer's papers describes the 1968 contribution as the "First design document for a Software Factory."

One historical qualification: saying the term was coined at NATO in 1968 is slightly stronger than the evidence warrants. Bemer had been developing this production-oriented thinking before the conference — the same NATO report reproduces his Checklist for planning software system production, explicitly dated August 1966. The safer statement is that the software factory concept received one of its earliest explicit and detailed formulations from Robert W. Bemer at the 1968 NATO Software Engineering Conference.

And the same conference contained M. D. McIlroy's famous argument for mass-produced, reusable software components. So 1968 already contains the two ideas that later become central to software industrialization: factory-controlled production and reusable components. The dark factory era is recombining exactly those two poles — agents as the interchangeable production machinery, prompts and skills as the components.

• The rise of services — software's answer to "manufacturing is dying" is SaaS and AI-as-a-service: the product becomes the service, and the firms that win capture the service end of the value chain. The backbone doesn't move; it becomes invisible.
• Digital automation — agents automate the routine work of software production, and the risk concentrates exactly where Hauge says it does: the routine jobs of the global periphery, which is why the offshore software industry is the first to feel it.
• Globalization of production — the software smile curve is as deep as the hardware one. The assembly — the code — is written wherever labor is cheapest; the value is captured at the ends: data, compute, distribution, and brand. The "AI colony" dynamic this blog has written about is the deepening smile applied to models: the South provides the data and the labor, the North owns the platform.
• Ecological breakdown — AI's constraint is no longer only labor but energy: training and inference have a material footprint, and the same question Hauge poses for steel applies to GPUs.

The pattern is the proof of the thesis. Industrialization is not over; it is being remade, and the countries that will matter in the next era are the ones that treat the new factory — the software factory, the AI factory — as a place to build capabilities in, rather than a place to rent labor to. The factory is not dead. It is being rebuilt, and the question is who builds it, who owns it, and who gets the design end of the smile.

References:

• Jostein Hauge. The Future of the Factory: How Megatrends are Changing Industrialization. Oxford University Press, 2023. — the four megatrends, the smile curve, and the case for a new industrial policy. Quotes and figures in this post are drawn from the book's introduction (Chapter 1) and figures 4.3 and 5.1.
• Jostein Hauge. How the West Was Won and Where It Got Us, 2020. — the earlier book on globalization and the myth of free trade.
• Related: AI sovereignty or AI colony: why domestic capability matters — the deepening smile applied to AI: data and labor in the South, platforms in the North.
• Related: AI Sovereignty Is Freedom — capability-building as the industrial policy of the AI era.
• Related: Software dark factories: specs in, software out — the software factory Hauge's lens applies to.
• Software Engineering: Report on a Conference Sponsored by the NATO Science Committee (Garmisch, 7–11 October 1968) — Bemer's Machine-controlled production environment ("or software factory") and his August 1966 Checklist for planning software system production; McIlroy's mass-produced software components.
• Published Papers of Robert W. Bemer (Computer History Museum archives) — describes the 1968 contribution as the "First design document for a Software Factory."
• Related: The economics of the dark factory: what happens when code is free — automation reorganizing the software labor force.
• Related: You Don't Learn What You Delegate — what automation removes when it replaces the task.
• Related: Hangzhou AI City — a regional industrial policy for the AI factory in practice.
• Related: UAE Sovereign AI: First, Train the Humans — capability-building before capability-having.
• Related: Plano Brasileiro de Inteligência Artificial (PBIA) — a late industrializer writing industrial policy for the AI era.
• Related: Every Token Has a Price Tag — the metered input cost of the new factory.

There are two answers to the question "how many blockchains do we need?" The first says one — a single general-purpose chain that everyone rents, like a city where every business operates in the same building. The second says many — a city where each business owns its own building and a road network connects them. The Cosmos SDK is the framework for building the second answer, and the reason it exists is that the first answer has a ceiling.

The general-purpose chain is a commons problem wearing a blockchain costume. Everyone rents the same blockspace, votes on the same governance, pays the same fee market, and suffers the same congestion. The app-chain thesis is the claim that the ceiling is not worth the network effects — that the correct unit of blockchain design is the application, and the correct way to connect applications is a protocol, not a platform.

The question is live because the two obvious answers already have visible failure modes. The one-chain answer congests: when one popular application dominates a shared chain, everyone else's fees spike and their transactions queue — the gas wars of 2021 were this failure at full volume. The many-chains-with-bridges answer leaks: most bridges are custodians, a handful of trusted keys on each side, and custodians get hacked — Wormhole lost three hundred million dollars in early 2022, Ronin six hundred million a few weeks later. IBC exists because both answers fail at the same point: they introduce a shared resource or a trusted party. The interchain's bet is that you need neither.

What the Cosmos SDK is

The Cosmos SDK is a framework for building application-specific blockchains in Go. "Application-specific" is the whole point: instead of deploying a smart contract into a generic virtual machine shared with every other app, you compile your application's logic directly into a chain. The chain is the app. Validators run your binary, not a bytecode interpreter.

The lineage matters because the design is old and the deployment is new. Tendermint's 2014 paper made the case for BFT consensus "without mining" — proof-of-stake, immediate finality, no energy arms race. The Cosmos whitepaper two years later named the goal: an "internet of blockchains," heterogeneous ledgers connected by protocol rather than absorbed into one. IBC went live in 2021. And the framing that a chain should be an application rather than a public square — the app-chain thesis, named by Osmosis co-founder Sunny Aggarwal — is what turned the infrastructure into a strategy.

A chain built on the SDK has three layers, and this is where the modularity lives: Consensus: CometBFT. CometBFT (formerly Tendermint Core) is Byzantine-fault-tolerant consensus with immediate finality — no probabilistic confirmations, no reorgs. It is deliberately application-agnostic: it orders transactions and doesn't care what they mean. The interface between consensus and application is ABCI — the Application Blockchain Interface. Your chain is a state machine that implements DeliverTx, BeginBlock, EndBlock, and answers CometBFT's calls. If you can write a Go program, you can write a blockchain.

State and application: the module system. The SDK provides modules for everything a chain needs: auth (accounts), bank (tokens), staking (validators and delegation), slashing, governance (proposals and voting), mint, distribution, plus the IBC stack. Each module owns a slice of the chain's state, exposes message handlers and queries, and composes with other modules through defined interfaces. Your application logic lives in custom modules. The composition is the chain.

Interoperability: ibc-go. The SDK's IBC module implements the Inter-Blockchain Communication protocol — the road network between buildings. A chain that imports ibc-go can connect to any other chain that implements IBC, regardless of consensus algorithm, programming language, or who runs it. That's the property that turns "many chains" from a fragmentation problem into an internet.

Why many blockchains are needed

The case for many chains is not aesthetic. Each argument below is a real cost that the shared model imposes, and a real capability that the app-chain model grants.

Sovereignty. On a shared chain, your application is a tenant. Its governance can change the rules — raise fees, alter opcodes, redeploy consensus — and you have no recourse. On your own chain, you set the governance. Nobody changes your execution environment without your consent. Sovereignty is the property that converts an application from a renter into an owner, and ownership is what you want when the application controls assets.

Specialization and performance. A general-purpose chain is tuned for the average app: one block time, one fee schedule, one execution model. An app chain is tuned for your app. A DEX can choose fast blocks and a swap-focused module set; an order-book exchange can build native matching logic that no generic VM could run efficiently; an oracle can put price feeds in the protocol itself. dYdX moved its order book off a general-purpose layer-2 onto a Cosmos app chain specifically to stop competing for shared throughput. Osmosis is a DEX that is its chain. Specialization is not a luxury; it is what "application-specific" means.

Fee markets and tokenomics. On a shared chain, your users pay the chain's fee market, and the chain captures the value. On your own chain, you design the fee policy, the staking curve, the inflation schedule, and the token's role in the application. The chain is an economy, and you get to be the central bank. Newer SDK versions even let application data ride inside consensus itself — Vote Extensions turn things that used to be off-chain heuristics (oracle prices, MEV policy) into protocol features.

Upgrade independence. A shared chain upgrades by governance vote, and every tenant waits for the vote. An app chain releases its own binary, runs its own upgrade, on its own schedule. This is the difference between being able to ship and being able to wait.

Failure isolation. A bug in a smart contract on a shared chain affects only that contract — usually. A bug in the consensus layer, the fee market, or a privileged module affects everyone. On an app chain, the blast radius of a bug is the chain. The application does not take down the network, and the network does not take down the application.

Security and compliance choice. Different applications have different security requirements, and a validator set can be chosen to match. A high-value settlement chain wants large, independent validators; an enterprise chain wants permissioned, KYC-compliant validators; a small chain that cannot bootstrap its own security can borrow it — Interchain Security lets a consumer chain inherit the validator set of a provider chain like the Cosmos Hub, getting shared security without shared governance. And when regulators need isolation — as with the CBDC proof-of-concepts built on this stack — the chain itself can be permissioned, without touching the public interchain.

The honest objection is fragmentation: many chains means split liquidity, split users, and a security bootstrapping problem. The interchain's answer is that interoperability is the mitigation. IBC connects the liquidity. Interchain Accounts gives users one wallet controlling accounts on many chains. Interchain Security pools the security. The hub routes the traffic. The objection is real, and it is exactly what the protocol layer exists to solve.

How the interchain works

IBC answers a genuinely hard question: how do two independent blockchains — different validators, different state machines, different consensus rules, no shared trust — exchange assets and data without a custodian in the middle?

The answer is light clients plus a packet protocol, and it is worth unpacking because it is the cleanest trust-minimized interoperability design in production.

Light clients. Each chain runs a light client of the counterparty it wants to talk to. A light client is a compact verifier: it tracks the counterparty's validator set and verifies headers, so the chain knows the counterparty's consensus state without downloading its history. Chain B does not trust Chain A's word; it verifies Chain A's claims against its own copy of Chain A's consensus rules.

Relayers. Nothing is broadcast; packets must be carried. Relayers — anyone, any party, often many parties — observe one chain, submit headers and proofs to the other, and carry packets back and forth. The crucial property is that relayers are trustless: they cannot forge a packet, because the receiving chain verifies every packet against the commitment stored on the sending chain. A relayer can only delay — and delay is detectable and bounded by timeouts. You trust the counterparty's validators, never the courier.

This is the entire difference between IBC and a bridge, and it is worth being blunt about. Most "bridges" in crypto are not protocols; they are custodians — a small set of trusted operators holding assets on each side and honoring each other's attestations. That design has a single point of failure, and it fails: Wormhole lost three hundred million dollars in 2022 through a forged signature, Ronin six hundred million when five of nine validator keys were compromised a few weeks later. IBC has no custodian to hack. The assets are escrowed in the sending chain's own bank module, the counterparty verifies the claim against a light client of the sender, and the relayer has no keys and no power. You can attack an IBC relayer's infrastructure and delay packets; you cannot steal them. The difference between "a bridge run by trusted parties" and "a protocol verified by light clients" is the whole security argument of the interchain.

Connections, channels, ports, packets. The protocol layers the abstractions: a connection is an authenticated link between two chains' light clients, opened by a four-step handshake; a channel is a transport pipe on a port, with ordering semantics (ordered or unordered); ports let many applications multiplex over one connection. Packets carry the data, a sequence number, and timeouts expressed in height or timestamp. Every packet gets an acknowledgement returned by the destination — success or failure — and unrelayed packets expire.

What a transfer actually does. ICS-20, the fungible token transfer standard, is the simplest complete example. Sending 100 ATOM from Chain A to Chain B: Chain A's bank module escrows the 100 ATOM (they are locked, not moved); the transfer packet commits a hash to A's state; the relayer carries the proof to B; B's light client verifies A's header, B's ibc-go verifies the packet proof, and B's bank mints a voucher — a new token with the denom ibc/<hash>/ATOM that encodes the token's origin. To return, burn the voucher on B and unlock the escrow on A. The original tokens never leave; ownership does, and the bookkeeping is on-chain and auditable.

Topology. The original design is hub-and-spoke: the Cosmos Hub (ATOM) as a central routing hub, each zone connecting once to the hub instead of N times to every other zone — N connections instead of N². Modern interchain is more flexible: chains connect directly (full mesh) when they are few, route through hubs when they are many, and the Packet Forward Middleware lets a single transaction hop through multiple chains atomically. The hub is an option, not a requirement — but the N² problem is why hubs exist.

What the stack buys. Interchain Accounts let Chain A control an account on Chain B through IBC — one wallet, many chains, no extra keys. Interchain Security lets a consumer chain rent the provider's validator set. Fee middleware pays relayers out of the packet itself, so relaying becomes self-sustaining instead of charitable. The design goal throughout is the same: keep each chain sovereign, make cooperation a protocol, and never introduce a party that must be trusted.

IBC went live in 2021, and the network it connects has grown to well over a hundred chains moving billions of dollars through this packet protocol. The framing the Cosmos project has used from the start — "the TCP/IP of blockchains" — is the right one. TCP/IP does not require everyone to share a machine; it connects machines. IBC does not require everyone to share a chain; it connects chains.

Building one

If you want to see how far the tooling has come: you can scaffold a working chain with Ignite (formerly Starport) in one command, and a bare SDK chain is a few hundred lines. The shape of a chain is remarkably small:

// app.go — the chain is a Go program that wires modules together
func NewApp(...) *App {
    app := &App{}
    // consensus talks to the application through ABCI
    app.BaseApp = baseapp.NewBaseApp("myapp", ...)
    // each module owns a slice of state and registers its handlers
    app.BankKeeper = bankkeeper.NewKeeper(...)
    app.IBCKeeper = ibckeeper.NewKeeper(...)
    // your custom logic is just another module
    app.MyKeeper = appmodulekeeper.NewKeeper(..., app.BankKeeper)
    return app
}

// keeper — your application logic: validate, execute, emit, return
func (k Keeper) Swap(ctx sdk.Context, req *types.MsgSwap) (*types.MsgSwapResponse, error) {
    // 1. validate the request
    // 2. execute the application logic against your module's state
    // 3. emit events (indexed, on-chain, auditable)
    // 4. return the response — CometBFT commits it in the block
    return &types.MsgSwapResponse{AmountOut: amount}, nil
}

The pattern is consistent: modules, keepers, message servers, protobuf types, genesis state, and CometBFT wiring. The SDK gives you the scaffolding; you provide the business logic; a validator set you choose runs it; IBC connects it to everything else. The last time software had this property — "build the specialized thing, connect it with a protocol" — it was called the internet.

I built a chain this way once, for my dissertation: SWEChain-SDK, a local-first blockchain-native SDK for simulating decentralized software-agent markets. The experience confirmed the property that matters most — the chain is just a Go program, and your state machine is yours. Scaffold it, wire the modules, write the keeper, run it, and the rules you wrote are the rules that execute: no shared fee market, no landlord governance, no waiting on someone else's upgrade vote. The app-chain thesis stops being a slogan the first time you ship your own state machine.

The interchain vision

The app-chain thesis has a reputation for being a preference. It is closer to an inevitability. General-purpose chains will keep existing — a city needs a public square as well as private buildings — but the marginal blockchain is increasingly application-specific, because specialization, sovereignty, and isolation are properties that only an app chain can grant. What makes this sustainable rather than fragmenting is the protocol layer: IBC makes many chains usable as one system, and the SDK makes building a new chain cheap enough that the choice is no longer "join a chain" but "own one."

The honest boundary: most applications should not build an app chain. If you do not need sovereignty — if someone else's governance, fee market, and upgrade cadence are acceptable — a shared chain is cheaper in every dimension: no validator bootstrapping, no security budget, no infrastructure to run. App chains are for applications that would otherwise pay a recurring tax or accept a recurring risk: a venue whose latency is the product, an exchange whose matching engine is the product, a system whose rules must not be voted on by strangers. The test is not "can I build a chain" — the SDK makes that cheap. The test is "would renting blockspace cost me more than owning it." When the answer is yes, you build. When it is no, you rent — and IBC still connects you to the chains that chose to own.

There is a direct line from this to the economics of metered computation this blog has been tracking. Blockspace, like tokens, has a price, and the interesting question is who sets it. On a shared chain, someone else sets it and everyone rents. On an app chain, you set it and you own. The interchain is the bet that the future is many owners of many blockspaces, connected by a protocol nobody owns — an internet of blockchains, in the most literal sense.

References:

• Cosmos SDK Documentation — modules, keeper pattern, app wiring.
• CometBFT Documentation — BFT consensus and the ABCI interface.
• IBC Protocol Specification — ICS standards: clients, connections, channels, packets, ICS-20 transfers, ICS-27 interchain accounts, ICS-28 replicated security.
• The App-Chain Thesis — application-specific chains as the correct unit of design.
• Tendermint: Consensus without Mining, Jae Kwon & Ethan Buchman, 2014 — the BFT foundation.
• Cosmos: A Network of Distributed Ledgers, 2016 — the "internet of blockchains" framing.
• dYdX v4: building an order book on the Cosmos SDK — the specialization case in production.
• Related: Cosmos SDK is the substrate for AI agents — the same stack, argued from the agent's side: sovereign execution and protocol-level automation.
• Related: Blockchains for Agentic Software — blockchains as implementations of economic mechanisms with visible rules.
• Related: Agentic Markets: Mechanism Design and Network Economics — rules as the design surface.
• Related: Design the Game — tokenomics as mechanism design.
• Related: libp2p is the internet, rewired — the peer-to-peer transport layer under the interchain.
• Related: The Unix philosophy is the only software engineering theory that works — many small sovereign programs, one uniform interface.
• Related: Every Token Has a Price Tag — metered computation and who sets the price of blockspace.

On a Tuesday in July 2026, engineers across Microsoft opened an internal email from Jay Parikh, the company's executive vice president, and read a sentence they will remember: "tokenmaxxing is not what we are optimizing for." The memo, first reported by 404 Media and then by The Next Web, arrived with its machinery already installed. Every division now carries a formal AI token budget. A dashboard shows each employee their monthly usage — token counts, dollar figures, trend lines — the way a utility statement shows kilowatt-hours. In May, most Claude Code licences inside the Experiences and Devices group had been cancelled and engineers told to migrate to GitHub Copilot CLI. In July, the default internal model was switched to a cheaper one.

Microsoft is not broke. Its most recent quarter beat Wall Street expectations on revenue, operating income, and net income. The company is profitable by every conventional measure. The caps are not an austerity measure. They are the moment the enterprise AI market grew up: the moment the free AI stopped being free.

The story of enterprise AI's last eighteen months is the story of a resource that everyone agreed was priceless, and the day its price became visible. Microsoft's token budgets are not about Microsoft. They are about what happens to any technology when the meter arrives.

Seats were the unit finance knew

The core problem is a mismatch of units. Software for the last forty years has been sold by the seat: a license per user per year, a number finance can multiply in a spreadsheet. A seat is a fixed cost. Budgets, contracts, procurement rules, chargeback systems — the entire institutional machinery of enterprise IT spending is built on the seat.

AI tooling is sold by the token, and a token is a marginal cost. It is not a number you can multiply; it is a number that grows with behavior. Two engineers with identical licenses can generate bills that differ by an order of magnitude, depending on how they prompt, how long their sessions run, how often the agent loops, whether they use autocomplete or agentic mode.

Finance teams discovered this the hard way. TNW has tracked the pattern since June: AT&T, Meta, Uber, Walmart, and Amazon all began capping or throttling employee AI spending after the same discovery — that token-priced tools "behave nothing like the seat-based software licences finance teams know how to budget."

The seat is a budget line. The token is a behavior. You cannot budget a behavior you cannot meter, which is why the meter had to come first.

The meter is the original model

None of this is new. The first era of computing was metered. In the mainframe age, compute was sold by the CPU-second and billed to departments — a practice that data-processing organizations of the 1970s and 1980s knew as chargeback, and it worked exactly like Microsoft's token budgets: a meter, a dashboard, a division allocation, a finance team that could finally budget the thing. A token is a CPU-second with a language model attached. The accounting problem is the same problem from 1970.

What interrupted the meter was the personal computer. Compute moved to the desk, its marginal cost fell to near zero, and software went by the seat for forty years. The seat was the anomaly, not the meter. Finance built its entire institutional machinery on the anomaly — which is why the token budget feels like a new invention inside a company that has been metering things forever.

The history also says what the meter is for. A century ago, Samuel Insull bet the electricity industry on it: price by consumption, he argued, and consumption will explode; flat rates were what capped the market. He was right, and it is the same logic as the Jevons paradox — cheap marginal units, metered, grow total use. The token caps feel like rationing, and in the short run they are. But the metering infrastructure Microsoft is building — budgets, dashboards, cheaper defaults — is the precondition for letting every employee use AI sustainably. The token budget is not the opposite of AI for everyone. It is the way AI for everyone gets funded.

The Jevons paradox has arrived

The numbers behind the crackdown are the cleanest demonstration of the Jevons paradox in modern economics. Per-token prices have fallen roughly 98 percent since late 2022. Cheaper should mean smaller bills. Enterprise AI bills have instead tripled.

The math behind the chart is worth doing slowly. If the price fell to 2 percent of its 2022 level and the bill still tripled, then token consumption grew about 150-fold. Demand for tokens is so elastic that a 98 percent price cut produced roughly a 15,000 percent increase in consumption. This is exactly what William Stanley Jevons observed about coal in 1865: as efficiency improves, total consumption rises, because the resource becomes economical for uses it could never before serve.

The second chart explains why the price collapse never reached the bill: the unit that got 98 percent cheaper is not the unit of work. Autocomplete — the interaction that shaped 2022's pricing — consumed a few hundred tokens per action. An agentic task consumes millions: the plan, the edits, the test runs, the debug loops, the retries. Ten thousandfold, give or take. A task that would have cost roughly a hundred dollars at late-2022 prices costs roughly two dollars at 2026 prices — the unit is 98 percent cheaper, and the task is still two hundred times the price of the autocomplete action it replaced. The bills did not triple because AI got more expensive. They tripled because work was redefined in units of millions of tokens.

Add always-on agents — assistants that watch the repo overnight, monitor the inbox, pre-empt the next task — and the meter never stops. The token is the first software input priced per unit of attention, and attention, once metered, is expensive.

The commons inside the firm

The deeper economics is the tragedy of the commons, staged inside a single company. An uncapped AI resource is a common-pool resource: rivalrous in consumption (every token costs the firm money) but free to each individual user. The employee's rational strategy is to maximize usage — to tokenmaxx. The extra tokens cost the engineer nothing and buy the engineer faster work, fewer keystrokes, better demos. The bill goes to the division.

This is a textbook principal-agent problem with a measurement gap. The firm wants the productivity gain but cannot observe it directly; the engineer observes it and does not pay for it. With the price invisible at the point of use, demand is unconstrained by definition. Microsoft's dashboard and division caps are the standard answer to the standard problem: make the marginal cost visible, then allocate it.

The dashboard alone does part of the work. Metering changes behavior before any budget binds — what gets measured gets managed — and the caps do the rest. For companies that have gone further, the caps have meant throttling and slower models at the margin. The precise mechanism matters less than the meter itself: the meter is what makes any mechanism possible. The company has effectively become a miniature economy with a scarce resource and an internal allocation mechanism, which is the most honest description of what a budget is.

Spend is measurable; productivity is not

The most revealing sentence in the reporting is that uncapped token spending "can spiral faster than the productivity gains it delivers." Read it carefully: no one knows what those productivity gains are. The spend is metered to the token; the gain is not metered at all.

This asymmetry is the engine of the whole story. Any technology that generates measurable cost and unmeasurable benefit will, in the absence of a productivity measurement, be governed by its cost. The budget caps are not a verdict on whether AI makes engineers more productive. They are a verdict on whether the firm can prove it — and it cannot, so it controls what it can measure.

The evidence base for AI productivity is thin and contested; this blog has covered a randomized trial that found programmers who delegated their learning to an AI scored 17% lower on what they were supposed to learn. Until the benefit side of the ledger is metered as well as the cost side, the accounting department will set the pace — and the accounting department can only count tokens.

The substitution game

The caps have a competitive edge to them. In May, Microsoft quietly cancelled most Claude Code licences inside its Experiences and Devices group and told engineers to migrate to GitHub Copilot CLI by the end of the fiscal year. In July, the default internal model became a cheaper OpenAI alternative.

This is platform economics working as designed. When tools are metered, demand at the margin is elastic, and firms will arbitrage their spending across vendors — which means the vendor that owns the platform can win twice. Microsoft owns GitHub and Copilot; the integrated tool can be bundled, subsidized, and made the default, while the third-party tool is priced at its marginal cost and looks expensive by comparison. The token budget makes the comparison explicit, and the default does the rest.

The quietest price instrument in the whole episode is the default itself. Microsoft did not order anyone to stop using expensive models; it changed the default and let behavior follow. This is behavioral economics' most reliable lever: defaults are a stronger instrument than prices, because accepting the default costs nothing and deviating costs attention. The cheapest way to cut a token bill is not a budget. It is a default. The budget says how much you may spend; the default decides how much you actually do.

The same dynamic is playing out across the industry: Amazon, Adobe, Atlassian, and Citi have all introduced throttling or spending visibility. Every metered enterprise is a market for tokens, and in a market, buyers substitute.

The ultimate admission

Do the arithmetic first, because it changes what the caps mean. Engineers were spending hundreds to a few thousand dollars a month in tokens — call it $6,000 to $36,000 a year. A fully-loaded US engineer costs a company $250,000 a year or more. The token bill is two to fourteen percent of the labor it serves.

Even if every one of Microsoft's two hundred thousand employees spent at the top of that range, the annual bill would still be a rounding error against hundreds of billions of revenue. Microsoft can afford to keep paying. The caps were never about affordability. They were about the shape of the bill: unbudgeted, unbounded, superlinear — a line item that grows with agentic adoption and arrives with no measurement of what it bought. A cost you can absorb is not the same as a cost you can predict, and a cost you cannot predict is not a cost at all; it is a risk.

That is what the anonymous employee's "ultimate admission" really says. Microsoft is not a customer of its AI stack; it is a platform owner with privileged access, enormous scale, and one of the strongest balance sheets in the industry. If the meter binds even there, it binds everywhere: the company that owns the stack has the best marginal economics in the industry, and it still will not let its own people use the product un-metered. At current cost structures, un-metered AI is not sustainable for anyone — and the caps are how Microsoft says that out loud.

That is a signal to the entire market, and it arrives at the end of the "AI for everyone" phase. Eighteen months ago the posture was encouragement: subsidize adoption, remove friction, let a thousand use cases bloom. The experimental phase had a purpose — discovering what AI is for — and subsidies are how you pay for discovery. The procurement phase is what comes after: every token has a price tag, every division has a ceiling, and the message to employees is "use AI, but know what it costs."

Conclusion

The tokenmaxxing memo is the least surprising economic event of the decade and one of the most consequential. The unit of software pricing changed from the seat to the token — or rather, it changed back. The meter is computing's original model, the seat was the forty-year detour, and tokens are the meter's return. The Jevons paradox made the bills grow even as prices collapsed, because the unit that got cheap was the token and the unit of work had become millions of tokens. The commons made the growth unbounded until the caps; the defaults turned the price into behavior; and the measurement asymmetry made cost control the only available policy while the productivity question stayed unresolved.

The meter does not answer whether AI is worth it. It only makes the question possible — which, given how the question had been avoided for eighteen months, is the whole point. None of this means the AI boom is ending. It means the free-lunch phase is, and the free-lunch phase was never sustainable anyway: markets that grow, grow on meters. From here on, the enterprise AI story is an accounting story as much as a technology story: metering, budgets, chargebacks, and the slow, contested work of measuring whether the tokens buy what they are supposed to buy. The next great advance in AI productivity may not be a model at all. It may be a ledger.

References:

• Ana Maria Constantin. Microsoft tells employees to stop tokenmaxxing, sets division-level AI budgets. The Next Web, August 4, 2026. — primary source for this post; the internal email was first reported by 404 Media.
• 404 Media, original report of Jay Parikh's internal email, July 2026.
• William Stanley Jevons. The Coal Question, 1865. — the paradox: efficiency gains increase total consumption.
• Garrett Hardin. "The Tragedy of the Commons." Science, 1968. — the common-pool dynamic inside the uncapped firm.
• Samuel Insull — the electricity-industry bet that metered, consumption-based pricing grows markets instead of rationing them.
• Mainframe-era chargeback — computing's first metering regime: CPU-seconds billed to departments, the direct ancestor of the token budget.
• Richard Thaler & Cass Sunstein. Nudge, 2008. — why defaults are a stronger price instrument than prices themselves.
• Cost-per-task chart: illustrative order-of-magnitude figures (autocomplete ~500 tokens/action; agentic task ~5M tokens, $100 at 2022 prices vs ~$2 at 2026 prices).
• Related: Agentic Era: An Economic System — agents as an economy, now with a price on their input.
• Related: Always-on agents: state, memory, and the governance gap — always-on agents are the token burn behind the tripled bills.
• Related: Software dark factories: specs in, software out — when agents replace labor, tokens become the cost of production.
• Related: The economics of the dark factory: what happens when code is free — the price of code moves from labor to compute.
• Related: Task automation economics: why an agent run is not automation — the unit cost of an agent run decides what gets automated.
• Related: You Don't Learn What You Delegate — why the benefit side of the ledger stays empty.
• Related: RBF: The Collateral Is Your Code — AI spend meets finance in the cost structure of startups.
• Related: Sellers & Buyers — the procurement phase is a market, and markets substitute.

In 1924, André Breton published the Manifesto of Surrealism and defined the movement with a single phrase:

SURREALISM, n. Pure psychic automatism, by which one intends to express verbally, in writing or by any other method, the real functioning of the mind. Dictation of thought, in the absence of any control exercised by reason, and beyond any aesthetic or moral preoccupation.

Breton meant writing without deliberation — letting the mind speak in its own currents, then seeing what had been said. The Surrealists called it automatic writing, and they treated the results as messages from a deeper agency: the unconscious, the irrational, the "real functioning of the mind."

A century later, the same idea has become the most consequential mode of software production on earth. A coding agent is an automatic writer: it generates code by sampling from a latent distribution of everything it has read, without deliberation, without a plan in the way a programmer plans — and certainly "beyond any aesthetic or moral preoccupation." When Andrej Karpathy named the purest form of this in 2025, he described it in words Breton could have signed: "you fully give in to the vibes, embrace exponentials, and forget that the code even exists." Forget that the code even exists — that is the dictation of thought, with the reason filtered out. Automatic writing, automatic code.

Agentic coding is automatism industrialized, and vibe coding is automatism at its most literal. Everything strange about working with agents — the wonder, the unreliability, the editing, the anxiety — is the strangeness the Surrealists met a hundred years ago. Their answer to it is the most useful theory of vibe coding I know.

The first automatic writers

The manifesto's definition was written as a dictionary entry — as if the movement already existed and only needed documenting. It was not a theory drawn from nothing. Breton had run the experiment five years earlier, with Philippe Soupault: The Magnetic Fields (1919), written in a few weeks in cafés, as fast as the hand could move, never looking back. The result read like nothing in print: images that did not follow from each other, syntax that kept its shape while sense dissolved. They were not trying to say something. They were trying to let the dictation happen — and when they stopped, they had the movement's founding method.

The practice spread to drawing, and the drawings are the closest thing the tradition has to a picture of how vibe coding feels. Masson sat at the paper and let the pen move without an image in mind — the line wandered, crossed itself, tangled — and only afterward, in the looking, did he read what his own hand had produced. Miró built canvases from the same improvisations; Ernst pressed frottage and scraped grattage to let the material itself suggest the image. The method was always the same: produce automatically, then look. The looking was not optional. It was the second half of the method — the half that made it art instead of noise.

The automatic, controlled

Jackson Pollock belongs in this lineage. In the late 1930s, in the drawings he made during his Jungian analysis, he practiced exactly this method: letting the line run without intent, then reading the drawing for what it revealed. A decade later, the method scaled from the page to the floor, from the line to the pour. No. 5, 1948 — the painting that would later become the most expensive ever sold at auction — is the pure product of that method: four by eight feet of enamel and paint poured from above, the automatist gesture at full scale.

When I am in my painting, I'm not aware of what I'm doing. It is only after a sort of "get acquainted" period that I see what I have been about... the painting has a life of its own. I try to let it come through.

That is an automatist's account of his own method. But Pollock added the half the lay view always forgets:

It is only when I lose contact with the painting that the result is a mess.

And when asked directly whether the pours were accidents: "I deny the accident. I can control the flow of paint."

The automatic was the source; control was the craft. The two were not opposites. The pour only worked while the body that produced it stayed in the loop — acting, stepping back, seeing, acting again. The same gesture, without the control, was just paint on canvas.

Pollock himself traced the floor method to an older lineage: "This is akin to the method of the Indian sand painters of the West." The sand painters also worked on the ground, in ceremony — with one decisive difference. When the ceremony ended, they erased the image. Pollock kept the trace. And the floor of his studio kept a trace even the canvases did not: the overflow of every session — the misses, the overpaints, the drips that never made it onto a canvas — preserved in the wood like a log. The floor is the first process record, the ancestor of the action stream and the replay: decades later you can still read what happened in that room, including the paintings that no longer exist.

What an agent is

A coding agent is the most literal automatic writer ever built, because its generation is genuinely opaque to deliberation. When the model emits code, no part of it reasons the way a programmer reasons. It samples from a learned distribution of tokens — a statistical unconscious containing the accumulated text of the world. The output issues "in the absence of any control exercised by reason," exactly as Breton prescribed, and with no aesthetic or moral preoccupation whatsoever.

The "dictation of thought" is literal too, and the thought being dictated is not the engineer's. It is the training distribution's — the aggregate of every repository, every discussion, every pattern the model absorbed. The agent is an unconscious at scale, and it writes.

This is why vibe coding feels the way automatic writing felt. The output is real, sometimes astonishing, and consistently unreliable in ways that defeat introspection. The model cannot tell you why it wrote what it wrote. Neither could Masson's hand. It writes like someone, and it is no one — which is why the interesting part is what you do next.

The editor's craft

The Surrealists discovered within a decade that pure automatism produces mostly mediocrity. The Magnetic Fields was astonishing; the practice of magnetic fields, repeated, was not. What saved the movement was editing: Breton curated relentlessly — cut, revised, chose which dictations to keep — and the painters composed and corrected after the automatic pass. The art lived in the relation between the automatic and the deliberate.

The same discovery is being made, at industrial scale, about agents. The pure-automatist version of the practice — accept the output, skip the looking — is vibe coding in its purest form, and it is The Magnetic Fields repeated: astonishing once, mediocre as a method. The prompt is the séance — the conditions under which the dictation happens. The harness is the editing table: the tests that cut what fails, the evals that rank what survives, the sandbox that keeps the automatic from doing damage while it works. The engineer's craft has moved entirely into that relation. You cannot make the automatic better by staring at it. You make it better by changing its conditions and editing its output.

The Surrealists had a game that made the same point visible. In the cadavre exquis — the exquisite corpse — each player drew a section of a body on folded paper, blind to everyone else's, and the sheet was unfolded at the end. The game took its name from the first sentence it produced: le cadavre exquis boira le vin nouveau — the exquisite corpse will drink the new wine. The results are the movement's best argument and its best joke: heads that belong to no body, syntax that belongs to no one.

Multi-agent workflows are the exquisite corpse at scale: each context writes a fragment blind to the whole, and the whole is only ever assembled at the end — by the harness, or not at all. Automatic output has no single author and no single intention. Coherence has to be imposed from outside, by the spec, the contract, the game master. The spec is the architect; the agents are the automatic; the editor is you.

Judgment without introspection

The hardest question automatism poses is: how do you know the automatic output is good? Neither the artist nor the model can answer by consulting intention — there was none. The Surrealists answered with an external test: the image — the sudden resonance of distant realities meeting. The image could not be explained, only recognized.

Surrealism's own history contains the warning, painted in the movement's other half. Magritte was the counterweight inside the group: where Breton sought the unconscious through unpremeditated marks, Magritte built each image with the deliberation of a cabinetmaker, and the tension between the two poles ran through the movement's entire history. His most famous painting is a manifesto against mistaking representation for reality:

Ceci n'est pas une pipe. Of course it is not a pipe. It is paint arranged to look like a pipe. The treachery is that it works anyway: you read it as a pipe and only the sentence beneath it — itself another representation — breaks the illusion. Magritte's whole point is that resemblance is precisely what makes the lie possible, and that representation is not identity.

This is the trap vibe coding sets. The agent's output is not engineering. It is a representation of engineering — tokens arranged to look like code, sampled from everything code has ever looked like. It resembles working software the way the painting resembles a pipe. Accept the resemblance without testing and you are doing what Magritte's sentence stops you from doing: taking the picture for the thing. The eval is the act of trying to smoke the pipe. The test is the treachery broken.

Code has the advantage that its external test is sharper: does it run, does it pass, does the system behave? The eval and the test suite are the criterion the automatist tradition never had. But a residue remains that evals cannot reach — the judgment of whether the automatic solution has the right shape, whether the surprise is a genuine find or a seductive artifact. For that you need the record of the making: the plan, the action stream, the replay — the trace of what the agent did, not just what it produced. You judge the dictation by its process as much as by its product.

The danger of losing contact

The Surrealists' history is a caution about what happens when the relation degrades. Automatism hardened into a style; Breton spent the 1930s excommunicating members over how much control the method allowed. When the automatic is trusted wholesale, the output becomes mannerist — fluent, plausible, empty. When it is distrusted wholesale, the source dries up.

The equivalent failure in agentic coding is delegation without judgment — vibe coding practiced without the looking half. Vibe coding is fine for throwaway scripts, the automatist sketch, the one-session Magnetic Fields; as a permanent mode it is the loss of contact. The engineer who accepts whatever the agent produces stops exercising judgment, and judgment, once unused, decays. The trial covered on this blog found exactly this — programmers who delegated their learning to an AI scored 17% lower on what they were supposed to learn.

Pollock's own arc is the cautionary tale, and it is more literal than it sounds. After the 1950 season — the year Namuth filmed him — the great pours stopped. In the last six years of his life he painted comparatively little, drank heavily, and destroyed or abandoned much of what he made. The technique was intact. The contact was gone — and without the contact, the automatic produced nothing worth keeping. His rule is the law of the whole practice: the result is a mess when you lose contact with the painting. The automatic needs the contact.

Conclusion

Breton wanted to hear the mind speak without the interference of reason. A century later, we have built a machine that does it — at the scale of whole codebases. Automatic writing has become automatic code — vibe coding, in the culture's word — and the discipline that makes it work is the discipline the Surrealists spent a decade learning: produce automatically, then look; control the conditions, edit the output, judge by external criteria, keep the surprises worth keeping, and never lose contact.

The dictation is automatic. The engineering is not. That is the whole art.

References:

• André Breton. Manifesto of Surrealism, 1924. — the definition of "psychic automatism... in the absence of any control exercised by reason."
• Automatism — Art Term, Tate. — the canonical definition: the term borrowed from physiology for bodily movements that are not consciously controlled (breathing, sleepwalking), via Freud's free association to Breton's dictation of thought.
• André Breton & Philippe Soupault. The Magnetic Fields (Les Champs Magnétiques), 1919. — the first automatic text, written in cafés as fast as the hand would move.
• André Breton, photograph by Henri Manuel — public domain; embedded in "The first automatic writers."
• Automatic drawing by André Masson (c. 1925) — public domain reproduction; embedded in "The first automatic writers."
• André Masson, Joan Miró, Max Ernst — automatic drawing, frottage, grattage, and the method of producing automatically then looking.
• Astonishing Examples of Automatic Drawing, Artsper Magazine. — the drawing-side companion to the automatic writings: the practice of bypassing conscious control, with examples.
• Andrej Karpathy. Vibe coding, February 2025. — the coinage of the practice this post reads as automatism's purest form: "you fully give in to the vibes... and forget that the code even exists."
• René Magritte. The Treachery of Images (La trahison des images), 1928–29. — "Ceci n'est pas une pipe": the deliberate pole of Surrealism and the standing warning that representation is not identity. Los Angeles County Museum of Art. Embedded above; low-resolution fair-use reproduction via Wikipedia, upscaled for display. (See also Michel Foucault, This Is Not a Pipe, 1973.)
• Jackson Pollock. My Painting. Possibilities I (1947–48), ed. Harold Rosenberg. — the get-acquainted period; "the painting has a life of its own"; "it is only when I lose contact with the painting that the result is a mess"; the kinship with "the method of the Indian sand painters of the West."
• Pollock, "I deny the accident. I can control the flow of paint" — interview with William Wright, 1950 (recorded for radio, aired posthumously).
• Hans Namuth photograph of Pollock painting on glass, 1950 — public domain; embedded at the top of this post.
• Jackson Pollock, No. 5, 1948, 1948 — oil and enamel on fiberboard, 121.9 × 243.8 cm, private collection. Embedded above; low-resolution fair-use reproduction via Wikipedia, upscaled for display.
• Pollock-Krasner House studio floor, photo by Rhododendrites — CC BY-SA 4.0; embedded in "The automatic, controlled."
• Cadavre exquis drawing, photo by DIYLILCNC — CC BY-SA 2.0; embedded in "The editor's craft."
• Related: Finding David in the Marble — the strike-assess loop, and the same act-then-look rhythm.
• Related: You Don't Learn What You Delegate — what delegation costs the actor's judgment.
• Related: Harness Engineering (Martin Fowler) — the harness as the editing table.
• Related: Agent Harnesses Need Tasks That Fight Back — the automatic needs resistance to mean anything.
• Related: Codebases in the Era of Agentic Software Engineering — the spec is the architect, the agents are the builders.
• Related: Conceptual Integrity and the One-Mind Rule — coherence imposed on multi-authored output from outside.
• Related: OpenWorker: Outcome Layer — the record of the making as a first-class artifact.
• Related: LLMs Can't Jump — what the automatic cannot do: the leap from experience to axioms.
• Related: Sandboxing AI Agents — securing the vibe coding stack, in Replit's phrase.
• Related: Harness Engineering Best Practices for AI Agents — tests are better than vibes: the looking half, made explicit.

The agent is a new kind of end user, and the interface is the environment it lives in. That is the founding claim of SWE-agent (Yang et al., 2024), the paper that coined the term agent-computer interface (ACI):

"Just as humans benefit from powerful software applications, such as integrated development environments, for complex tasks like software engineering, we posit that LM agents represent a new category of end users with their own needs and abilities, and would benefit from specially-built interfaces to the software they use."

Everything in this post follows from treating that sentence literally. The CLI has a new user, and it never blinks: it reads every byte of help text and output, remembers all of it, cannot answer a prompt, cannot see color, and pays for every token it reads. Most CLIs were designed for the old user — a human who can squint, scroll, and improvise. The agentic-first CLI is designed for the user who actually exists.

The thesis: the interface is a first-class performance variable for agents, and the CLI is the right substrate for it — if designed with the discipline of a versioned public API. The evidence comes from the benchmark literature and the interface-design papers; the theory comes from Brooks's The Design of Design.

The interface is a performance variable

The SWE-agent result is the strongest single number in the field: with the same underlying model (GPT-4), a custom agent-computer interface achieved a 12.5% pass@1 on SWE-bench and 87.7% on HumanEvalFix — "far exceeding the previous state-of-the-art achieved with non-interactive LMs." No new model, no new prompting trick: a better interface. The paper's conclusion is explicit: the design of the ACI changes agent behavior and performance.

Two benchmarks set the floor and the ceiling for the CLI specifically. InterCode (Yang et al., 2023) formalized interactive coding as a reinforcement-learning environment with "code as actions and execution feedback as observations" — the observation channel is the interface. Terminal-Bench 2.0 (Merrill et al., 2026) built 89 hard, real-world terminal tasks and found that frontier models and agents score under 65% — then devoted an error analysis to why, because terminal interfaces, as they exist today, are bad ACIs: ambiguous output, interactive prompts, hidden state. AgentBench (Liu et al., 2023) reached the same conclusion across eight environments: how the agent observes and acts determines more of the outcome than the model's raw capability.

The practical translation: every line your CLI emits is an observation your agent reasons over; every prompt it waits on is a stall; every hidden default is a hallucination risk. The design of the interface is not a UX nicety. It is the agent's model of the world.

The design space: four ways to expose a tool to an agent

Anthropic's Building Effective Agents (Dec 2024) is the most-cited engineering guidance on exactly this choice, and its conclusion favors the boring option: "the most successful implementations use simple, composable patterns rather than complex frameworks." Function calling and MCP solve real problems — typed I/O and cross-tool discovery — but each is a layer the tool must implement and maintain. The CLI already exists, is observable by construction, composes through pipes, and needs no new protocol. The agentic-first CLI is the low-friction ACI: the discipline of a versioned API applied to the interface you already ship.

What the research says about CLI design

Each practice below is anchored to a source, not to taste.

Structured output is the observation channel. InterCode's framing — execution feedback as the observation — implies the feedback must be unambiguous. Prose output is a lossy observation: an agent that reads "Build succeeded. 12 targets, 3 warnings." will guess about the warnings, and its guesses are confident. Git solved this in 2009 with status --porcelain, a byte-for-byte stable machine format that ships alongside the human format; every state-producing command should offer the same: --json, data on stdout, nothing else.

Determinism is trust. An agent cannot satisfice — Herbert Simon's term, adopted by Brooks — a nondeterministic tool: if the same command yields different output, it must verify, and verification is the most expensive thing an agent does. So: no interactive prompts (detect non-TTY and fail fast, or provide --yes/--no-input); no hidden state (flags over config inference); sort by default; --check and --dry-run before anything destructive. An agent that trusts the tool runs once; an agent that does not runs three times.

Help is the documentation the agent reads. Anthropic's ACI guidance is the sharpest sentence in the field: "Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing." SWE-agent's ACI shipped documentation for its custom commands, and the paper credits it. An agent that trusts --help saves a full exploration cycle; a lie in help text is the most expensive bug an agentic CLI can have.

Exit codes and stderr are the contract. The interface has three channels — stdout (data), stderr (diagnostics), exit code (verdict) — and agents read all three. The checklists of the terminal benchmarks exist because agents misallocate effort when the channels are mixed: banners on stdout, logs where data belongs, exit 0 on failure.

Consistency is learnability. SWE-agent found interface design changes agent behavior; Brooks's conceptual integrity explains why: a system that feels like one mind designed it lets the agent's learned model of one subcommand transfer to the next. A CLI with five flag styles is a committee design, and the agent pays for it in tokens and mistakes.

Quiet by default is the budget. Brooks on budgets — design within time, memory, cost — applied to the agent's context window: verbose-by-default is a tax on every invocation, forever, at scale. --verbose opts in.

Why the CLI, and why not a protocol

The counter-argument is worth taking seriously: if agents need good interfaces, build the interface from scratch — a purpose-built ACI, like SWE-agent did. The rebuttal is economics. A purpose-built ACI for your tool is what MCP servers and function schemas already are: another layer to write, document, and keep in sync with the actual tool. The CLI is the one interface that already exists, already documented, already versioned, already composable. The agentic-first discipline makes it also correct for agents — without inventing a protocol.

The exception is cross-tool discovery: when an agent must discover and bind tools at runtime across many systems, a protocol like MCP earns its layer. But the interface underneath still needs the same design discipline — MCP tool descriptions and output schemas are the same contract as --help and --json, wearing a different hat. Anthropic's guidance applies at the layer you control: "reduce abstraction layers and build with basic components" in production.

The checklist

• stdout is data only; stderr is diagnostics; logs to file
• --json on every state-producing command, stable documented schema
• exit codes: 0 = success, non-zero = failure, distinct code for "not run"
• no prompts: --yes, --no-input, TTY detection
• no color when piped; honor NO_COLOR
• deterministic: sorted output, no timestamps unless asked, no hidden config
• idempotent: --check, --dry-run, --apply
• quiet by default, --verbose opt-in
• complete, honest --help with examples
• one convention set across every subcommand
• versioned, additive contract

The test

Run your CLI the way the benchmark environments run it: --help, one command, --json, another command — and read the output as a reader who never blinks, never asks, and never forgets. If any line could mean two things, the agent will choose the wrong one half the time, and it will do so confidently. The terminal benchmarks exist because that failure is measurable; the fix is the discipline above.

The agent is a new kind of end user, and the interface is its environment. The contract is the architecture; the output is the model; determinism is respect; tokens are the budget; one mind owns the whole thing. Design for a user that never blinks — and every human at the terminal benefits too.

References:

• John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan. SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering. arXiv:2405.15793, 2024. — Agents as a new category of end users; custom ACI; 12.5% SWE-bench / 87.7% HumanEvalFix pass@1; interface design changes agent behavior.
• Mike A. Merrill, Alexander G. Shaw, Nicholas Carlini, Boxuan Li, Harsh Raj, Ivan Bercovich. Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv:2601.11868, 2026. — 89 terminal tasks; frontier agents under 65%; error analysis.
• John Yang, Akshara Prabhakar, Karthik Narasimhan, Shunyu Yao. InterCode: Standardizing and Benchmarking Interactive Coding with Execution Feedback. arXiv:2306.14898, 2023. — Interactive coding as an RL environment: code as actions, execution feedback as observations.
• Xiao Liu et al. AgentBench: Evaluating LLMs as Agents. arXiv:2308.03688, 2023. — Eight agent environments, including the operating system and terminal.
• Building Effective Agents. Anthropic Engineering, Dec 2024. — "Carefully craft your agent-computer interface (ACI) through thorough tool documentation and testing"; simple, composable patterns over frameworks.
• Claude Code — Best practices for agentic coding. Anthropic. — Tool and interface design guidance from the team shipping the most-used agentic CLI.
• Model Context Protocol. Anthropic, 2024. — The protocol alternative for cross-tool discovery.
• Git — Plumbing and Porcelain and git status --porcelain. — the machine-stable output contract, in production since 2009.
• Frederick P. Brooks Jr. The Design of Design. Addison-Wesley, 2010; and The Mythical Man-Month, 1975. — Models, the design tree, budgets, satisficing (after Herbert Simon), the separation of architecture from implementation, conceptual integrity, the one-mind rule.
• NO_COLOR — the environment variable for disabling color output.
• Related: Brooks on Software Design: Conceptual Integrity — the property the agentic contract depends on.
• Related: Brooks on Software Design: One Mind — who owns the CLI contract, and why committees fail at it.
• Related: The Unix Philosophy Is the Only Software Engineering Theory That Works — stat for data, ls for rendering; the outside-in view.
• Related: CUPID: Properties, Not Principles — composability, predictability, and the Unix property as directions, not rules.
• Related: Task Harness Engineering — the other half of the agent's toolchain: how harnesses consume CLI contracts.

The collateral for a revenue-based financing (RBF) loan is not an asset. It is your telemetry — the data your software produces about the revenue it generates. The lender underwrites a revenue stream, read through your APIs, your metering, your books: everything it knows, your code told it; everything it cannot trust, your code hid. That makes RBF the financing instrument most legible to software engineers, and the one whose terms are engineering outcomes — margin, usage, data quality. The cost of capital is a performance metric, set by the codebase.

The thesis: the company that builds its revenue legibility like a system gets financed like a system — the code you write sets the price of your money.

The mechanics

The terms are a protocol. A lender advances capital sized against your recurring revenue — commonly several months of it. You repay a fixed percentage of monthly revenue, typically 5–8%, until cumulative repayments reach the advance plus a multiple (typically 1.5–2.5x) or the term limit passes, whichever comes first; in most structures the balance is forgiven at the limit. No equity, no board seat, no fixed payment that can sink a bad month. Lenders may still take a lien at the small end — telemetry is the underwriting collateral, not the only legal one. Reported volume: $9.8B in 2025 (Lighter Capital, Capchase, Pipe, Wayflyer, Founderpath, Recur Club).

The arithmetic nobody does

The cap is the price, and duration sets the rate. A $1M advance at a 1.8x cap costs $800,000 — roughly 40% a year over 24 months, half that over 48. Sellers quote the percentage of revenue, never the rate, because the rate depends on growth, the one number the lender cannot know. And the arithmetic cuts against fast growth: repayment is a share of revenue, so the cap is hit fastest when revenue grows fastest. At $100k MRR, 6% repayment, 1.8x cap: 10% monthly growth caps out in ~3 years (~25% annualized); 3% growth takes 6+ years (~half). The rate was never in the contract; it was in the roadmap. The fastest-growing product is the one where equity would have been cheapest — the instrument is cheapest, in rate terms, for the companies that need capital least.

Where engineering decides the terms

The term sheet is written in your code, in four places.

Gross margin is an architecture decision. For an AI product, margin is set in the serving layer — routing, batching, caching, prompt compression. Every point of margin recovered is a point the repayment cannot consume.

Revenue quality is a data problem. Recurring vs one-off, churn — outputs of your metering, billing, and analytics. "Is this revenue recurring?" is an instrumentation decision. Clean revenue data is the company's credit file.

Usage-based pricing is fragile revenue. Readable in real time, cancelable in real time — a config change, a model switch, an agent contract lapse. Contracted MRR survives board meetings; usage revenue survives until the next API call.

The repayment schedule is your usage curve. Every revenue-generating agent call is a drip into the repayment — free-tier usage is not collateral.

The lender is a software system

The counterparty is a system, not a banker: live revenue feeds, ML credit models over churn, automated checks; diligence is an API integration. Its model asks what your analytics stack asks — is this usage real? — and in the AI age real and manufactured usage look alike: agent-driven signups, inflated usage, subsidized pilots, card stacking. Revenue-quality detection is an adversarial ML problem; lenders who skip it underwrite the AI economy's subprime.

The fit test

Perfect fit: a high-margin API product with clean metering — 80% gross margin, a year of revenue history. Take $1–3M, buy growth, repay from the usage growth creates.

Wrong fit: the compute and training layer — capex with delayed revenue, nothing to underwrite.

Tricky fit: below ~60–70% gross margin or pass-through revenue — repayment eats real cash flow and the lender cannot trust the stream.

What the honest critics say

Three objections survive. The cap can cost more than the equity you saved — 1.8x on a fast-growing product can exceed the dilution of a modest round. Revenue is the tax base and the north star — RBF takes a cut of the metric you optimize, hardest in the quarter when it repays fastest. And revenue can be manufactured, more easily in the AI age — revenue quality (recurring, diversified, contract-backed, human-signed) becomes the new credit score.

The test

Six questions, asked the way an engineer reviews a design:

• What is the annualized cost of the cap at your actual growth rate? (If you cannot answer, you are signing a rate you do not know.)
• What is gross margin per feature, and who owns it?
• Is revenue recurring or usage-based, and does your metering make the difference visible?
• Is the capital for growth rather than R&D capex?
• Does the cap cost less, in real dollars, than the equity you would give up?
• Will the revenue still be there, and still real, in month 24 — and would your own data prove it?

The first question is the one sellers never ask; the last is the one the AI age added. If the only thing generating the revenue is the same machinery that reports it, the lender is underwriting a mirror.

RBF prices what you have built, not what you might build. The collateral is your code, the repayment is your usage, and the cost of the loan is whatever you failed to compute about your own growth. Do the arithmetic before the lender does.

References:

• Revenue-based financing — definition and terms (5–8% of monthly revenue; 1.5–2.5x caps). Investopedia.
• Global RBF market surpassed $9.8B in 2025, 129+ active lenders. HubSpot Sales Blog.
• Lighter Capital — the largest dedicated RBF lender for SaaS.
• Capchase — subscription and revenue financing.
• Pipe — the revenue exchange.
• Founderpath — RBF for bootstrapped SaaS.
• Recur Club — revenue-based financing for growing companies.
• Plaid — the data layer RBF underwriting runs on.
• Stripe — revenue data via API.
• Related: Engineering Is Art and Philosophy, Grounded in Economic Law — the margin structure that makes AI startups financeable, as an engineering property.
• Related: Task Automation Economics — why an agent run is not automation, and how the AI product's economics differ.
• Related: Data Quality and the Problem of Truth — revenue quality is a data-quality problem; truth is borrowing capacity.
• Related: Always-On Agents: State, Memory, and the Governance Gap — the agentic operations layer that makes startup finance legible.
• Related: Lending Protocols — credit is 3,800 years old; the Code of Hammurabi knew the trade-offs RBF rediscovered.

A rare thing: a pre-registered randomized controlled trial of how AI assistance changes what workers learn. Shen and Tamkin (Anthropic), How AI Impacts Skill Formation. Fifty-two professional and freelance Python programmers were randomized, asked to learn a library they had never used (Trio, an async I/O library), complete two coding tasks, and then take a quiz on what they actually learned. One group had a GPT-4o chat assistant that could write the entire correct solution; the other had no AI at all.

The headline, in two numbers: the AI group scored 17% lower on the quiz — about two grade points (Cohen's d = 0.738, p = 0.010) — and gained no significant time in return. The productivity miracle measured in prior work (55.5% faster with Copilot; 26.8% more pull requests) did not show up when the task required learning. That is the paper's contribution, and the thesis of this post: AI assistance doesn't just complete the task — it removes the part of the task that teaches. You don't learn what you delegate, and the trial shows exactly which behaviors turn delegation into learning and which into a 17% toll.

The experiment

Participants made this a hard test of "AI helps novices most": more than a year of Python, weekly use, prior AI experience, never Trio (Fig 17). A warm-up task, then 35 minutes for two Trio tasks: a concurrent timer and a record-retrieval function with error handling. Then a 14-question, 27-point quiz over 7 Trio concepts in three skill types — conceptual understanding, code reading, debugging (Fig 20); code-writing was excluded, since syntax is what AI fixes cheapest.

The treatment assistant was no toy: GPT-4o with access to the participant's code, able to produce the full correct solution to both tasks. Four pilot studies tuned the design — the first platform had 35% non-compliance (controls using AI anyway); a later pilot (Fig 5) showed the effect so strongly (d=1.7) that the pre-registration assumed a conservative d=0.85 for power. Integrity controls included pledges and screen recordings of every participant (Figs 21–24; Figs 25–27 show both platforms).

Results: the 17% toll

The main results (Fig 6): a 4.15-point gap on 27 points — 17%, two grade points — with no significant difference in completion time; the effect survives controlling for warm-up speed (d=0.725, p=0.016). Fig 7 shows the control group scoring higher at every experience level, and Fig 8 shows where the damage concentrates: the largest gap is in debugging, the smallest in code reading. Both groups read code; only the control group had to fix it.

That debugging gap is the paper's most important sentence in disguise. The industry case for human oversight of AI-written code rests on humans being able to debug what AI produces — and this trial suggests the mechanism that builds that skill is exactly what AI assistance removes.

Why there was no speedup

The qualitative analysis explains the missing speedup: heterogeneity. Watching every screen recording, the researchers found six AI-interaction personas (Fig 11), with completion times and quiz scores that barely overlap:

• AI Delegation (n=4) — handed the whole task to the AI, finished fastest (19.5 vs 23 min), scored 24–39%.
• Progressive AI Reliance (n=4) — started with a question, then delegated everything; lost the second task's concepts entirely.
• Iterative AI Debugging (n=4) — used AI to fix code without understanding it; slowest of the low scorers.
• Generation-Then-Comprehension (n=2) — generated code, then asked follow-ups to understand it. 65–86%.
• Hybrid Code-Explanation (n=3) — asked for code with explanations, and read them.
• Conceptual Inquiry (n=7) — asked only conceptual questions, hit errors, resolved them independently. Second-fastest overall.

The gap between worst and best usage is the real story: 24–39% vs 65–86% on the same quiz with the same assistant. The difference is not whether AI was used; it is what happened after the AI answered. The time side confirms it: some participants spent up to 11 minutes composing queries and asked 15 questions (Fig 12); debugging-heavy query mixes correlated with slower times and lower scores (Figs 18–19). And the paste-vs-type analysis (Fig 13) has a twist: pasting AI output was fastest, manually copying it was as slow as control — but the two scored the same on the quiz. Spending time typing doesn't build understanding.

Errors are the curriculum

The mechanism the paper lands on is the most old-school finding in it: errors teach. The median control participant hit three errors; the median AI participant hit one (Fig 15). Of the twelve error-free completers, only two were control. The errors that matter are the Trio-specific ones — RuntimeWarning (a coroutine never awaited), TypeError (a coroutine passed where an async function was expected) — because they force exactly the conceptual knowledge the quiz tests (Fig 14). The control group did not learn despite the errors; the errors were the lesson plan. Active coding time tells the same story from the other side (Fig 16): AI shifted time from writing to reading AI output. The AI group's own feedback confirms it — they felt "lazy" with "gaps in (their) understanding."

What this means

Three implications, stated as plainly as the paper allows.

First, the chat interface is the best case. A chat assistant at least forces the user to compose a query — some spent six minutes on a single one, and that thinking correlates with learning. An agentic tool that writes, runs, and fixes code itself removes even that. If this trial is the lower bound on cognitive offloading, agentic settings are below the floor.

Second, the supervision argument inverts. "AI writes code, humans verify" assumes humans have debugging skill to spend. This trial suggests that skill is built by the exact experience AI removes. Companies adopting AI-assisted onboarding for juniors are not just changing throughput; they may be choosing which generation holds the verification skill.

Third, the dark-factory argument applies to skills, not just complexity. When automation removed factory labor, complexity moved into supervision. When AI removes implementation, the question is where the learning goes — and this trial's answer is: out of the worker, unless the worker keeps engaging. Delegation is a productivity strategy and a learning strategy simultaneously; you cannot have both.

The six personas are the practical deliverable: the difference between treating the model as a chauffeur and as a tutor.

The productivity view asks: how much did AI finish? The skill view asks: what did you keep? This trial shows the two questions now have different answers. The 17% is what you pay when you confuse them.

All figures

Every figure from the paper, thumbed. Substantive results first; study artifacts last.

References:

• Judy Hanwen Shen, Alex Tamkin. How AI Impacts Skill Formation. arXiv:2601.20245v2, 2026. — Pre-registered RCT of AI assistance on learning the Trio async library; quiz deficit d=0.738, p=0.010; the six interaction personas.
• Study pre-registration and annotated transcripts.
• Summary infographic of the study (LinkedIn, August 2026) — embedded at the top of this post.
• S. Peng et al. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, 2023. — 55.5% faster task completion.
• Z. Cui et al. The Effects of Generative AI on High Skilled Work: Evidence from Three Field Experiments with Software Developers, 2024. — 26.8% productivity boost.
• T. Wu et al. The Value of AI Assistance? Evidence from the Performance and Learning of Knowledge Workers, 2024. — performance gains did not persist after AI was removed.
• Related: The Dark Factory Doesn't Eliminate Complexity — It Moves It — AI removes the work; the question is where the skill goes.
• Related: Empirical Software Engineering: What the Studies Actually Say — why RCTs in software are rare, and how to read them.
• Related: Empirical Software Engineering: How to Think Empirically — pre-registration, effect sizes, and the discipline behind this trial.
• Related: LLMs Can't Jump — what models cannot do is exactly what the control group had to learn.
• Related: Always-On Agents: State, Memory, and the Governance Gap — agentic AI removes the query-composition step this paper found valuable.

Five people have been named Satoshi Nakamoto. All five times, the answer collapsed.

Dorian Nakamoto. Newsweek's 2014 cover, on little more than a shared name. Satoshi's account answered: "I am not Dorian Nakamoto."

Hal Finney. The first person to receive a bitcoin, the man who built RPOW. He denied it and died in 2014; the case died with him.

Nick Szabo. Bit gold, the closest thing to Bitcoin before Bitcoin. He denied it; stylometry never closed it.

Craig Wright. He sued everyone who said he wasn't. In March 2024 the UK High Court ruled in COPA v Wright that he is not Satoshi and had forged his evidence.

Peter Todd. HBO's Money Electric (2024) built its finale on a forum-post coincidence; he denied it, and the theory jumped the shark.

Five verdicts, five collapses. The pattern is the point: the field keeps looking at suspects instead of at citations. The whitepaper names its sources — and one of them fits everything: the inventor of Bitcoin's core mechanism, British, a distributed-systems PhD, a founding-generation cypherpunk, denying it with the consistency of a man who has rehearsed the answer for fifteen years.

The thesis: Adam Back is the only suspect whose entire career was the design document for Bitcoin — and the strongest evidence against him is his own denial.

Exhibit A: the citation

The whitepaper's first technical move is proof-of-work, and proof-of-work is not Satoshi's invention. It is Adam Back's:

"To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash [6]."

Back invented hashcash in 1997 as an anti-spam device: force the sender of an email to burn CPU on a partial hash collision. The 2002 papers turn it into Bitcoin's economics — "Hashcash - A Denial of Service Counter-Measure" and, the title that should be on a plaque, "Hashcash - Amortizable Publicly Auditable Cost-Functions." Publicly auditable cost functions is mining. Bitcoin's difficulty adjustment, halving, and "one-CPU-one-vote" consensus are the hashcash paper extended from spam defense to money.

Back's own homepage says it plainly: hashcash is "the mining function in bitcoin," and under "Bitcoin Related," "how bitcoins uses hashcash fractional difficulty, automated inflation control." The inventor of the mining function publishing a note on how Bitcoin uses its fractional difficulty — every other suspect had to learn proof-of-work. Exactly one person in the world did not.

Exhibit B: the emails

In August 2008, weeks before the whitepaper, someone using the name Satoshi Nakamoto emailed Adam Back. Five emails from the correspondence are now in the public record, entered in COPA v Wright; Satoshi referenced hashcash and said he was preparing to release a whitepaper.

For the defense, this is the whole case in one exhibit: the inventor of hashcash would not email himself about hashcash.

For the prosecution, read it as stagecraft. A real Satoshi needed hashcash as the whitepaper's foundation — and needed, at some future point, to be able to say: look, I contacted the inventor before I published. The August 2008 email is that alibi, insurance taken out before the crime.

And look at what Back did with the email. He kept it, and built his company's brand around it: Blockstream produced a commercial dramatizing a young Adam Back reading the historic email from Satoshi. The man who, if he were anyone else, would be the greatest living witness to Bitcoin's creation made the email a marketing prop. People do not make their alibis into commercials.

Exhibit C: the signals

Everything about Satoshi is UK-shaped. The genesis block — January 3, 2009 — embeds a UK newspaper headline: "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks." His posting hours cluster in the British evening; his writing mixes British spelling and idioms with American expressions — the profile of a Brit steeped in US tech. Adam Back is British, a University of Exeter distributed-systems PhD (1995), on the Cypherpunks list since the mid-1990s. He has maintained since 1995 exactly the profile the signals describe.

Exhibit D: the resume is the design document

Open cypherspace.org/adam — the page this post is named after — and read it as a requirements list:

• hashcash — proof-of-work. ✓ (Bitcoin's consensus)
• credlib — "chaum and brands ecash/credentials" — anonymous e-cash. ✓ (Bitcoin's premise)
• The Eternity Service — a censorship-proof document store, Phrack, 1997. ✓ (Bitcoin's promise)
• Cebolla — IP anonymity. ✓ (Bitcoin's network layer)
• The Crypto Hacks page — breaking Netscape's SSL challenges (the second in 32 hours), extracting NSA keys from Microsoft's CAPI. ✓ (the conviction that the old money systems are broken)

The man who spent the 1990s breaking the financial internet, exposing government backdoors, and writing the theory of publicly auditable cost functions is the only candidate who does not need to be explained. Then note what he did next: between hashcash (1997) and 2014, no major protocol design. In 2014 — the year he founded Blockstream — he co-authored the sidechains paper. The first new Back protocol in seventeen years arrived exactly when Bitcoin needed its next layer, from the CEO of a company whose entire business is Bitcoin. The two 17-year gaps are the same gap.

Exhibit E: the candidate pool

Bitcoin required simultaneous mastery of proof-of-work, public-key crypto, P2P networking, incentive design, monetary economics, and C++. Every named suspect was strong in three or four: Finney had crypto and RPOW but no monetary economics; Szabo had economics and bit gold but no proof-of-work innovation and no C++; Wright had none of it. Back is the one candidate strong in all six, at inventor level in one — and his next act was to build a company on the protocol, which is the most Satoshi thing anyone has ever done.

The denial

Adam Back has said, repeatedly, for fifteen years, that he is not Satoshi. A real Satoshi must deny. The asset is destroyed: Bitcoin's value is not the coins; it is the neutrality. "Satoshi is Adam Back, CEO of Blockstream" converts the most valuable neutral protocol on earth into a company's project overnight. The exposure is existential: a pseudonymous creator of a trillion-dollar asset faces every regulator, litigant, and hacker; the Wright trial showed what happens to people who merely claim the identity. The performance is uniform: Back denies it in the same flat, unvarying way — no outrage, no legal threats, no "let me prove it."

And here is the part that keeps the case alive. The tell is not the denial; it is what Back does around it. His homepage caches Satoshi's deleted Wikipedia article, under the note "cache of Satoshi Nakamoto's wikipedia page which the editors deleted??", the double question mark doing visible work. His company dramatizes the moment he received Satoshi's email. He has played the "I'm not Satoshi" line as a bit for a decade. A man falsely accused, whose company would benefit from the rumor dying, keeps a candle lit on it.

The case for the defense

The strongest counter-argument is the emails, from the other side: a real inventor contacted the real author of his foundational reference, cited him properly, and the two exchanged professional notes. The whitepaper over-credits — Dai, Szabo, Finney, Haber and Stornetta, Merkle — unusually generous prior art. Both readings survive; stylometry has convicted no one. And the deep counter: the deception would be enormous — fifteen years, sustained through his own company's marketing. That is either impossible, or it is exactly the discipline of a man who already kept the biggest secret in technology for two years while everyone in his field discussed it in front of him.

Verdict

The case cannot be closed, and that is the strongest evidence of all. Satoshi engineered the identity to survive forensic pressure — anonymous email, no PGP key, pattern-averaging hours, a silence chosen at the moment Bitcoin stopped being a hobby. The protocol was designed so its creator could never be proven, and so anyone could build on it.

You cannot prove Adam Back is Satoshi. Neither can anyone else. But every other suspect needs a theory of how they did it; Back is the only one who needs a theory of how he did not.

The citation. The emails. The signals. The resume. The denial. Five exhibits, none conclusive, all pointing one way. It's Adam Back — and the denial is part of the evidence, not the answer.

References:

• Adam Back's home page — cypherspace.org/adam — hashcash ("used as the mining function in bitcoin"), the Satoshi Wikipedia cache, the publications list, the Crypto Hacks page, the Exeter PhD.
• Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash System. — "a proof-of-work system similar to Adam Back's Hashcash [6]"; "proof-of-work is essentially one-CPU-one-vote."
• Adam Back. Hashcash - A Denial of Service Counter-Measure, 2002; and Hashcash - Amortizable Publicly Auditable Cost-Functions, 2002.
• Adam Back. The Eternity Service, Phrack 7(51), Sep 1997.
• Adam Back et al. Enabling Blockchain Innovations with Pegged Sidechains, Oct 2014.
• COPA v Wright — UK High Court judgment, March 14, 2024. — Wright is not Satoshi; the Satoshi–Back email correspondence entered into the record.
• Leah McGrath Goodman. The Face Behind Bitcoin, Newsweek, March 2014.
• Money Electric: The Bitcoin Mystery, HBO, October 2024. — the Peter Todd conclusion.
• Bitcoin genesis block — the embedded Times headline, January 3, 2009.
• Related: The Decentralized AI-Agent Experience — the cypherpunk lineage: Eternity Service → Freenet → the distributed future.
• Related: Agentic Markets: Mechanism Design and Network Economics — incentive design is Bitcoin's real invention; the hardest problem Satoshi had to solve.

Dan North's CUPID: for joyful coding (2022) starts with the reader's body memory. As a rookie he cracked open a large C codebase, expecting to drown; within minutes he was deep in a nest of calls and knew exactly where the bug was. Structure, naming, and flow so obvious they felt like architecture he already knew.

The vocabulary escalates: Fowler's "code that humans can understand" is too low a bar; Gabriel's habitability — "to change it comfortably and confidently" — gets closer; the word North actually wants is joyful. If you work in code, the codebase is your user experience, programmed in by people you have never met, one of whom may be future you.

CUPID is his account of what makes code joyful, a five-letter backronym aimed at SOLID: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based. It is usually filed under "the anti-SOLID," and that is the misreading. CUPID's contribution is not five new principles. It is the argument that the idea of a principle is the problem.

The move: properties over principles

North started by trying to replace each SOLID letter with a better one and quickly concluded the frame itself was broken:

"Principles are like rules: you are either compliant or you are not. This gives rise to 'bounded sets' of rule-followers and rule-enforcers rather than 'centred sets' of people with shared values."

Bounded set: in or out, compliant or violating, pass or fail. Centred set: closer or further, with a direction of travel that is always clear, and no one ever "outside." Principles give you judgment day; properties give you a compass. They are chosen to be practical ("there is never a 'done'"), human ("what it feels like to work with code"), and layered (obvious to a beginner, deep for the experienced). Every letter is best read as a direction, not a target.

Composable — plays well with others

Three heuristics, none of them laws. Small surface area: a narrow, opinionated API has less to learn and less to go wrong — but too narrow, and "knowing the right combination" becomes tacit knowledge; there is a sweet spot between fragmented and bloated. Intention-revealing: a component you can discover and assess quickly — the tutorial ladder of 2, 10, and 30 minutes. Minimal dependencies: "a logging library" is really a dependency on a specific version, and version is where incompatibilities break.

"More is not necessarily better; it is all trade-offs."

A principle says minimize dependencies. A property says dependencies are a cost you can move, and the skill is knowing which way lowers the total. The difference is whether the guidance survives contact with a real codebase.

Unix philosophy — does one thing well, from the outside

"Doing one thing well" sounds like the Single Responsibility Principle, and North is careful about why it is not:

"The former is about how you use code, and the latter is about the internals of the code itself."

SRP is inside-out: "one and only one reason to change." Unix is outside-in: a specific, comprehensive purpose visible from the call site. ls does not know anything about files — stat provides the data, ls only renders it; pipes compose such commands into pipelines, each a narrow, complete, outside-visible contract.

Then the attack on SRP, the most useful passage in the essay. "One reason to change" is trivially refutable — a single line changes for security, compliance, dependencies, operations. The real damage is the artificial seams: report content and format change together, so SRP's demand to separate them makes every new field a chore of chaining identical fields across files; UI components suffer the same split. Applied as a rule, SRP imports accidents — seams nobody's problem forced on you.

The inside-out question ("what could make this change?") generates seams. The outside-in question ("what would a user of this call it?") generates boundaries. Seams are things to maintain. Boundaries are things to use.

Predictable — does what you expect

Predictability is "a generalization of testability": code should behave as expected, be deterministic, and be observable. Behave as expected — the first of Kent Beck's four rules, holding even with no tests: the intended behaviour is obvious from structure and naming. Deterministic means robust (covers what you know), reliable (same result every time), resilient (survives what you don't). Observable is the control-theory word — internal state inferable from outputs — only possible if designed in. North's ladder: instrumentation, telemetry, monitoring, alerting. "Most software does not even get past step 1."

Idiomatic — feels natural, because empathy

"The greatest programming trait is empathy; empathy for your users; empathy for support folks; empathy for future developers; any of whom may be future you." Idiomatic code is empathy compiled into style — matching the language's idioms so the reader's context switches are free. Opinionated languages help (Go's gofmt makes all code look the same; Python's Zen: "one—and preferably only one—obvious way to do it"); multi-paradigm ones (Perl's TIMTOWTDI, Ruby, JavaScript) let five ways to iterate a sequence coexist, each adding cognitive load. Where the language has no consensus, the team must supply one: shared formatting, linting, Architecture Decision Records.

"Your learning curve for a technology will likely be shorter-lived than any code you write in it."

Read it again: the person writing the code is a temporary visitor to its style; the code outlives them. "Reads well to me right now" is the wrong bar — North calls idiomatic writing "writing code for someone else."

Domain-based — the solution models the problem

The last property is the deepest: the solution domain should model the problem domain in language and structure. A surname is not a string[30]; money is not a float. Type the domain — Surname, Money with its Currency and Amount — and the cognitive distance between what you write and what it does collapses. North's criterion, stated once:

"A casual observer cannot tell whether people are discussing the code or the domain."

Structure next, where CUPID is most contrarian. Framework scaffolds impose an a priori structure — the Rails skeleton's app/models, app/views, app/controllers, app/helpers, app/jobs — scattering one semantic unit across half a dozen directories: a patient-record change touches a model, a view, a controller, a helper, each in a different folder. North's proposal is radical in its mildness: structure by the domain, not the framework — patient_history, appointments, staffing, compliance as the top level. A codebase grouped by framework role is a codebase whose architecture was decided by the framework's author, not by the one mind that understands the domain.

Why it holds together

The properties are mutually reinforcing: composable and comprehensive — doing one thing well — "is like a reliable friend"; idiomatic code "feels familiar even though you have never seen it before"; predictable code "gives you spare cycles to concentrate on surprises elsewhere"; domain-based code "minimises the cognitive distance from need to solution."

"Moving code towards the 'centre' of any of these properties leaves it better than you found it."

That is the whole philosophy in one sentence — and the sentence that cannot survive translation back into principles: "leaves it better than you found it" has no compliance check. You can only point at a codebase and say: closer to the centre than last month, and here is the direction to keep travelling.

The test

Read as rules, CUPID is SOLID with a better haircut: five more checkboxes, five more fights in code review. Read as properties, it is a different instrument. Five questions, no pass or fail:

• What would it take to reuse this outside its home? (Composable)
• What is the one thing this does, and can I see that from outside? (Unix philosophy)
• If I change this, how hard is it to know what happens next? (Predictable)
• Would the person who inherits this recognize it as theirs? (Idiomatic)
• Does this read like the domain, or like the framework? (Domain-based)

None of these has a yes-or-no answer. That is not a weakness. It is the point.

SOLID asks: are you compliant? CUPID asks: which way is better? A principle is a verdict. A property is a compass. Joy is not a property you can check off — it is what it feels like to be moving in the right direction.

References:

• Dan North. CUPID: for joyful coding. Feb 10, 2022. — The five properties: Composable, Unix philosophy, Predictable, Idiomatic, Domain-based; properties over principles; the three "properties of properties" (practical, human, layered).
• Martin Fowler. Refactoring: Improving the Design of Existing Code. Addison-Wesley, 1999. — "Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
• Richard P. Gabriel. Habitability and Piecemeal Growth, in Patterns of Software. Oxford University Press, 1996. — "Habitability is the characteristic of source code that enables people to understand its construction and intentions and to change it comfortably and confidently."
• Michael Feathers. Working Effectively with Legacy Code. Prentice Hall, 2004. — Characterization tests; "When a system goes into production, in a way, it becomes its own specification."
• The Zen of Python, PEP 20. — "There should be one—and preferably only one—obvious way to do it."
• Effective Go and gofmt. — Idiomatic Go as a shipped, enforced standard.
• TIMTOWTDI. — Perl's "there is more than one way to do it."
• Michael Nygard. Documenting Architecture Decisions. 2011. — Architecture Decision Records for local idioms.
• Robert C. Martin. Agile Software Development, Principles, Patterns, and Practices. Prentice Hall, 2002. — The Single Responsibility Principle ("one and only one reason to change"), the inside-out view North argues against.
• Dan North. Code in the Language of the Domain, in 97 Things Every Programmer Should Know. O'Reilly, 2010.
• Ruby on Rails — the generated skeleton app whose type-based directory structure North critiques from a domain-based view.
• Related: The Unix Philosophy Is the Only Software Engineering Theory That Works — the outside-in view, taken seriously as a theory.
• Related: Accidental Complexity Is the Only Complexity You Can Remove — SRP's artificial seams as imported accidents; framework scaffolding as the tar pit.
• Related: Zero Overhead Is Zero Attack Surface — minimal dependencies as the only defense that compounds.
• Related: Taste as Conceptual Integrity — idiomatic code as one-mind judgment, written for the person who inherits it.

"AI sovereignty" is the most successful marketing term in the industry, which is why the definition matters: whoever defines "sovereign" decides what counts as having it. And the definition that wins in the market is the one that can be sold: control. Sovereign cloud. Sovereign borders. Permission dashboards. Data regions. Every vendor's brief sells sovereignty as the ability to administer — a dashboard you are given inside walls the vendor owns.

The thesis: control is what a provider grants you inside its walls; sovereignty is what you can still do outside them. AI sovereignty is not control — it is freedom: the freedom to exit, to fork, to audit, to run, to refuse. The only real test of sovereignty is what remains possible when the vendor, the regulator, or the foreign power acts against you.

Control is the cheapest definition

The term was popularized by NVIDIA. At the World Governments Summit in February 2024, Jensen Huang said: "Every country needs to own the production of their own intelligence." Call that the national definition: sovereignty as freedom from dependence — the ability to produce what you need. The organizational definition, per McKinsey, is "a country's or an organization's capacity to independently develop, deploy, and govern artificial intelligence using its own infrastructure, its own data, its own models, and its own talent." Call that the capability definition: sovereignty as freedom to build. The operational definition moves down the stack, to the workspace — prompts, files, permissions, logs. Call that the control definition: sovereignty as who administers the thing.

None is wrong. That is the trap. The national definition requires building a country's worth of capability; the capability definition requires holding four layers; the control definition requires purchasing software. In a market, the winning definition is the cheapest to satisfy — the one that can be bought. Control is the cheapest because it is the one thing a vendor can sell without giving up anything real: you administer the walls, the vendor keeps the land. This is why the definition is the battlefield — and why the freedom reading is the one to defend.

Residency is comfort, not freedom

A system can store every byte in the "right" country and still be controlled from elsewhere, because jurisdiction follows the provider, not the bytes. In July 2020 the Court of Justice of the EU struck down the EU–US Privacy Shield (Schrems II, C-311/18): US surveillance law reached EU data regardless of where it physically resided. The CLOUD Act (2018) lets US law enforcement compel US-headquartered companies to produce data held anywhere; the 2023 Data Privacy Framework patched the transfer mechanism, not the reach. Residency is a property of a database; freedom is a property of your exit options. A region you cannot leave is a nicer cell. "Sovereign cloud" labels are theater when the exit door is the vendor's to open.

The three freedoms

Freedom of use. The control layer's true content is not administration; it is the ability to run, inspect, and shut off the thing yourself. If no one owns operations, the system is not sovereign — it is self-hosted, which is a different failure. Self-hosting moves risk from the vendor's team to yours, but it also moves the freedom: if your team can run the stack, the vendor's exit is not the end of the world. Freedom of use is the difference between renting a tool and owning the means to run it.

Freedom to build. Control governs a stack that already exists; it says nothing about whether you can train, fine-tune, repair, or even explain the models you run. Open weights are not open source and not politically neutral: the OSI definition (2024) requires training-data access, and DeepSeek — the MIT-licensed poster child of "model freedom" — was blocked by Italy's regulator in 2025. The alignment, censorship, and update cadence of a model are policy decisions made in its home jurisdiction; no workspace governance changes that. In 2026 the model is the most political layer in the stack, and sovereignty that rents it is sovereignty on a lease. Freedom to build is also freedom in people: the UAE reached 64% federal AI adoption by training 80,000 employees, not by buying dashboards; Japan's digital minister warns that a country without domestic capability becomes an "AI colony."

Freedom from reach. The component most definitions omit, because it is the one you cannot buy. The CLOUD Act reaches data anywhere, as long as the operator is US-headquartered; the US "Framework for AI Diffusion" (2025) tiers access to advanced compute and model weights by destination — sovereignty starts at the silicon, and freedom starts at not being cut off from it. Every deployed model carries the thumbprint of its creator's government; freedom is knowing which thumbprints can reach you, and which doors you can walk through.

Partial sovereignty is partial freedom

Holding all three freedoms is not achievable for most organizations, and pretending otherwise is how money gets spent on theater. The practical question is not "are we sovereign?" — nobody is, fully — but "which exit do we depend on, and can we take it?" For a hospital, the data exit: can we leave with the records? For a bank, identity and audit: can we prove what happened after the vendor is gone? For a defense agency, the network: does it function when the internet is the threat? For a country, the silicon: can it still compute when the export license is revoked? The failure mode is not the wrong choice; it is discovering you have no exit at the moment you need one.

The politics: control is the apparatus, freedom is the correction

Sovereignty-as-control is exactly what the critics fear. Milton Mueller's "Against Sovereignty in Cyberspace" (2020) argues the term serves states that want control of the network, not liberty within it — and the identical stack that lets a nation control its AI is the stack of an intelligence apparatus: unified identity, full logging, airtight permissions. The freedom reading is the corrective: the same stack, arranged for exit rather than reach, is liberty. "We control our intelligence" is the apparatus; "we can leave with our intelligence" is the freedom.

Regulation shows the same split. The EU AI Act — whose general application begins today, August 2, 2026 — is sold as a driver of European sovereignty, but the 2024 open letter by European AI researchers warned it would "cripple European AI" by over-regulating open-source models. Control imposed from above consumes freedom of use and build; regimes that outpace capability export freedom rather than secure it.

The test

• Can we leave: exit the provider, the region, and the stack, and take our data and models with us?
• Can we fork: train, fine-tune, or repair the models we run, or only rent them?
• Can we audit: inspect the weights, the operator, and the data in a crisis?
• Can we run: hold the talent and the code to operate the stack ourselves?
• When the vendor, the regulator, or the foreign power acts against us tomorrow, what can we still do?

If the answer to the last one is "we don't know," the boundaries you have configured are not sovereignty. They are a lease.

Sovereignty is not a wall around your AI; it is the door. Control is what you keep; capability is what you can build; jurisdiction is what can reach you — and freedom is what you can still do when all three are tested. Own the exit you depend on, and know which one that is — because whoever defines "sovereign" decides whether you are administering a system or living in it.

References:

• NVIDIA Blog — NVIDIA CEO: Every Country Needs AI (Feb 12, 2024)
• McKinsey — What is sovereign AI? (archived)
• EUR-Lex — Case C-311/18 (Schrems II, July 2020)
• Congress.gov — CLOUD Act, H.R. 4943 (2018)
• EU–US Data Privacy Framework
• OSI — Open Source AI Definition 1.0 (Oct 2024)
• Reuters — Italy blocks DeepSeek over data protection (Jan 2025)
• Federal Register — BIS Framework for AI Diffusion (Jan 2025)
• Mueller — Against Sovereignty in Cyberspace (2020)
• EUR-Lex — Regulation (EU) 2024/1689 (AI Act)
• European AI Act open letter (May 2024)
• Related: AI Sovereignty or AI Colony — why domestic capability, not boundaries, is what prevents dependence.
• Related: UAE Sovereign AI: First, Train the Humans — the capability component, measured in people.
• Related: Hangzhou AI City — the national definition done as municipal infrastructure, and why it is unrepeatable.
• Related: Compute Travels. Data Stays. — data sovereignty as an architecture, not a region.

In April 1987, IEEE Computer published Fred Brooks's essay "No Silver Bullet: Essence and Accidents of Software Engineering." It may be the most quoted and least read document in the history of the field. Everyone knows its conclusion — "There is no silver bullet" — because it has been the standard reply to every promised miracle since. Almost nobody remembers its actual subject, which was not miracles at all. The essay's real contribution was a distinction: between the complexity that is essential to the problem and the complexity that is accidental to the solution. Forty years later, that distinction has turned out to be more durable, and more useful, than the prediction it was built to support.

The abstract states the conclusion with characteristic compression:

"There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity."

But the sentence that carries the essay is the one that defines the terms:

"All software construction involves essential tasks, the fashioning of the complex conceptual structures that compose the abstract software entity, and accidental tasks, the representation of these abstract entities in programming languages and the mapping of these onto machine languages within space and speed constraints."

Essential complexity is the difficulty that lives in the problem — the conceptual construct itself, its interlocking data structures, relationships, and invariants. Accidental complexity is the difficulty that lives in the means of production: the languages, tools, platforms, conventions, and accumulated infrastructure through which the construct is forced to pass. Brooks, following Aristotle, called them the "essence" and the "accidents":

"Following Aristotle, I divide them into essence—the difficulties inherent in the nature of the software—and accidents—those difficulties that today attend its production but that are not inherent."

The word "today" is doing enormous work in that sentence. Accidental complexity is contingent. It is a property of the moment's tooling, not of the problem. It can in principle be eliminated by a better way of doing things — and every time the industry has actually gotten dramatically better, that is what happened.

The arithmetic Brooks did, and the claim he made

Brooks did not merely assert that the essence dominates. He supplied an argument, and it was an arithmetic one:

"How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement."

That is the whole essay in miniature. A "silver bullet" is defined as a tenfold improvement. If the accidental part is half the effort, eliminating it entirely buys a factor of two. If it is nine-tenths, eliminating it entirely buys a factor of ten. Brooks's empirical guess in 1986 was that the accidental share was below nine-tenths — so no single advance, however complete, could cross the order-of-magnitude threshold. Hence no silver bullet.

Notice what follows from this framing. The claim is not that accidental complexity is small. The claim is that even if you eliminated every scrap of it, the improvement would be bounded by how much of your effort is actually essential. The conclusion is hostage to a ratio Brooks estimated by hand. He was explicit about the uncertainty — the "unless" is doing the work — and the ratio was never measured. It was a guess, offered in a paragraph, in a field where guesses about ratios have a way of becoming doctrine.

The four properties of the essence

Brooks identified four properties of software that make the essential difficulty irreducible: complexity, conformity, changeability, and invisibility.

Complexity. Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike — above the statement level, repetition is a smell and gets factored out. The parts interact nonlinearly:

"Software systems have orders of magnitude more states than computers do."

And then the sentence the whole distinction rests on:

"The complexity of software is an essential property, not an accidental one. Hence descriptions of a software entity that abstract away its complexity often abstract away its essence."

Conformity. Here Brooks is subtlest, and the subtlety matters for everything that comes later. The complexity of conformity is not inherent to the software; it is imposed from outside:

"Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform."

An interface defined by a legacy mainframe, a regulation, or a competitor's format is arbitrary. It could have been any shape. But the software that must serve it inherits that arbitrariness, and no redesign of the software alone can remove it.

Changeability. "All successful software gets changed." Software embodies function, and function is the part most exposed to the pressure of change. Unlike a building, where cost dampens the whims of the changer, software is "pure thought-stuff, infinitely malleable" — so it gets changed constantly, by users discovering new uses and by the machines it must outlive.

Invisibility. "The reality of software is not inherently embedded in space." It has no geometric representation the way a floor plan captures a building. Diagramming software yields several superimposed directed graphs — control, data, dependency, time — which are "usually not even planar, much less hierarchical."

These four are the essence: the irreducible difficulty of getting a complex, arbitrary, changing, invisible construct right. Brooks's conclusion follows:

"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation."

What the silver bullets actually did

The most instructive part of the essay is its review of the candidates — because Brooks shows, case by case, that every genuine advance in software productivity had attacked the accidental part, not the essential one.

High-level languages. The most powerful stroke for productivity, reliability, and simplicity — credited with at least a factor of five:

"To the extent that the high-level language embodies the constructs wanted in the abstract program and avoids all lower ones, it eliminates a whole level of difficulty that the programmer would otherwise have to master."

The programmer was not solving a harder problem with Fortran. They were freed from bits, registers, conditions, branches, channels, and disks — from the accidents of the machine. That is why the first transition from machine language to a high-level language produced the huge payoff, and why each subsequent language improvement pays less: the accidents are fewer each time, because the previous round removed them.

Object-oriented programming and Ada. Brooks gives these their due — "Each removes one more accidental difficulty from the process, allowing the designer to express the essence of his design without having to express large amounts of syntactic material that add no new information content" — and then delivers the sentence that should be carved over every architecture department:

"Such advances can do no more than to remove all the accidental difficulties from the expression of the design. The complexity of the design itself is essential; and such attacks make no change whatever in that."

AI, expert systems, automatic programming, graphical programming, verification, environments, workstations. Each gets a section and each is shown to be either an attack on accidents (verification, environments) or, in the case of AI and automatic programming, a promise to automate the essential task — which Brooks judged impossible, because the essence is not a representation problem, it is a thinking problem.

The pattern is the point. Every historical leap in software productivity — from assembly to high-level languages, from batch to time-sharing, from unstructured to modular — was a removal of accidents. Brooks's own history supports a stronger claim than the one he made: the gains in this industry have always come from removing accidental complexity, and the residual accidental complexity is precisely where the next gain is hiding.

The essence is the part of the difficulty you cannot remove. The accidents are the part you can. Every order of magnitude software has ever gained came from the second kind.

The disagreement: Out of the Tar Pit

Brooks's essay was answered, twenty years later, by Ben Moseley and Peter Marks in "Out of the Tar Pit" (2006) — a paper that opens with the same diagnosis and then disagrees with the ratio:

"Complexity is the single major difficulty in the successful development of large-scale software systems. Following Brooks we distinguish accidental from essential difficulty, but disagree with his premise that most complexity remaining in contemporary systems is essential."

The disagreement is not about the distinction. It is about which side of the line most of the complexity actually sits on:

"We disagree. Complexity itself is not an inherent (or essential) property of software (it is perfectly possible to write software which is simple and yet is still software), and further, much complexity that we do see in existing software is not essential (to the problem)."

Their test is clean: a complexity is essential only if the team would have to contend with it "even in the ideal world" — with perfect infrastructure and no performance constraint. By that test, the majority of what contemporary systems carry — the handling of state, the explicit management of control flow, the plumbing — is accidental:

"We believe that the major contributor to this complexity in many systems is the handling of state and the burden that this adds when trying to analyse and reason about the system."

This is the point at which the forty-year argument actually lives. Brooks guessed the accidental share was below nine-tenths and therefore irrelevant to order-of-magnitude claims. Moseley and Marks argue the accidental share is the dominant share — which is why the paper is titled after the tar pit: the tar is mostly of our own manufacture. If they are right, then the search for silver bullets was never the error. The error was concluding that the essence dominates without measuring it.

The empirical record since 1986 has been kinder to Moseley and Marks than to Brooks. The industry has not lacked for order-of-magnitude removals of accidents: garbage collection eliminated entire classes of memory-management errors; managed runtimes eliminated whole toolchains of manual build and deploy; static typing eliminated whole classes of runtime failures; source control, package managers, and CI removed categories of coordination work that once consumed weeks. Each was an accident removed. And each removal revealed that the next layer down was also, in substantial part, accidental.

Where accidental complexity lives today

The most useful way to read Brooks's distinction is as a diagnostic: for any piece of difficulty in a system, ask whether it is forced by the problem or by the choices made along the way. Run that test over a modern codebase and the accidental fraction is hard to keep below nine-tenths.

The toolchain itself. A build system exists to manage the accidents created by the previous build system. The dependencies in a modern application are a geography of other people's accidents: transitive packages, platform shims, polyfills, and compatibility layers, each of which solved one problem by introducing the possibility of a hundred. The 2016 left-pad incident — the unpublishing of an eleven-line npm package taking down thousands of projects — was an accident of the packaging layer, not of anyone's essential problem. The software supply chain attacks of the last decade live in exactly this sediment. Every dependency is accidental complexity you have chosen to import, and the attacks are the price of the import. The supply chain argument for minimalism is the accidental-complexity argument wearing a security hat.

The architecture. The microservices wave was, at bottom, an attempt to escape accidental complexity that the industry had built for itself — the coordination cost of large codebases, the fear of the monolith. It then manufactured a new layer of accidents: distributed transactions, network partitions, service discovery, observability, deployment matrices. The pattern is so common it has a name, and it is Brooks's pattern: each generation's solution is the next generation's accidental complexity. When Segment published "Goodbye Microservices" in 2018, documenting its move from a microservices zoo back to a modular monolith, the headline finding was not about ideology — it was that the distributed systems complexity had become the dominant cost, and none of it was essential to the business problem. They were removing accidents.

The abstraction layer. Joel Spolsky's "Law of Leaky Abstractions" (2002) states the mechanism precisely: "All non-trivial abstractions, to some degree, are leaky." An abstraction that worked perfectly would have removed its accidents permanently. A leaky abstraction — TCP over satellite links, a filesystem over NFS, an ORM over a join — keeps the accidents it was supposed to remove and adds new ones on top. The complexity is not gone. It has moved into the leak.

Rich Hickey's "Simple Made Easy" (2012) made the same point with different words. The industry optimizes for easy — familiar, convenient, near at hand — while simplicity — unbraided, unentangled, each thing doing one thing — is what actually reduces complexity. Easy is frequently the delivery mechanism for accidental complexity: the framework that makes today's task trivial by braiding in a thousand obligations that must be paid later. Ousterhout's A Philosophy of Software Design (2018) gives the definition that should close the argument: "Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system." By that definition, most of the structural difficulty in contemporary systems is accidental, because most of it comes from choices — and choices can be unmade.

Dijkstra got there first, in 1972:

"The tools we use have a profound (and devious!) influence on our thinking habits, and, therefore, on our thinking abilities."

And, in 1988, on the economics of the whole problem:

"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better."

Complexity sells better. That sentence is the reason the accidental share never falls on its own: there is no market pressure toward removing accidents, because accidents are usually invisible to the buyer. They are paid for later, in maintenance, in onboarding, in incidents — in the tar.

The one ratio Brooks got right by accident

Here is the irony that makes the essay worth reading today. Brooks listed AI among the candidate silver bullets and dismissed it, as he dismissed everything, on the grounds that the essence cannot be automated. What the 2020s actually demonstrated is subtler: AI did not remove the essential difficulty — it collapsed the accidental part, which is precisely the part Brooks defined as removable. The labor of representing a conceptual construct in a programming language, and mapping it onto machines — his own definition of the accidental task — is what generative coding tools have made nearly free.

The essence is still there. The accidents are what the AI ate.

That is why the residual bottleneck in the AI era looks exactly like Brooks's list of essential properties. Specification is the bottleneck — the conceptual construct must still be designed, and designing it is thinking, not typing. Conformity is the bottleneck — the arbitrary interfaces of the world do not become less arbitrary because code is generated. Changeability is the bottleneck — generated code inherits the pressure of change at higher velocity. Invisibility is the bottleneck — an agent cannot hold the whole directed graph of a system in view, and neither can its context window. The four essential properties are now the entire difficulty, because the accidents that used to hide them have been removed. This site has argued the same thing from two directions: that dark factories simply move the complexity upstream into specification and downstream into validation, and that the irreplaceable human contribution is the perception of conceptual integrity — the one-mind judgment of whether the whole still coheres.

Brooks's conclusion — no silver bullet — was a prediction about a ratio he guessed. The prediction's status is now genuinely contested: if accidental complexity is the dominant share, as the evidence increasingly suggests, then a tool that eliminates accidents is the order-of-magnitude event, and the industry just lived through it. But his distinction has survived the prediction, because the distinction is not an empirical claim. It is a classification, and it is the classification that does the work:

The essence is the complexity the problem forces on you. The accidents are the complexity you chose. You cannot remove the first. You can only remove the second. Therefore the only complexity you can actually remove is accidental complexity — and removing it is the entire history of progress in this field.

The practical consequence is not a technology. It is a discipline of subtraction. Every dependency is a choice. Every framework is a choice. Every layer of indirection is a choice. Every one of them imported accidents that will be paid for later, and each one was imported because the accident it removed was more visible than the accidents it added. Brooks's essay is usually cited as the reason progress is impossible. Read correctly, it is the reason progress is possible at all — one removal at a time.

There is no royal road, but there is a road.

References — Brooks:

• Frederick P. Brooks Jr. No Silver Bullet: Essence and Accidents of Software Engineering. Information Processing '86 (IFIP World Congress, 1986); reprinted in IEEE Computer 20(4), April 1987. — The distinction between essential and accidental difficulty; the four essential properties (complexity, conformity, changeability, invisibility); the 9/10 arithmetic; the review of candidate silver bullets.
• Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975; 20th Anniversary Edition, 1995 (includes "No Silver Bullet" and "'No Silver Bullet' Refired"). — The tar pit; Brooks's Law; the second-system effect; the programming systems product.
• Brooks, F. P. The Design of Design: Essays from a Computer Scientist. Addison-Wesley, 2010. — Conceptual integrity, the one-mind rule, the divorce of design from implementation.
• Brooks & Blaauw. Computer Architecture: Concepts and Evolution. Addison-Wesley, 1997.
• Wikipedia — No Silver Bullet · The Mythical Man-Month · Brooks's law · Second-system effect · The Design of Design

References — the disagreement and the state of the argument:

• Ben Moseley & Peter Marks. Out of the Tar Pit. BCS Software Practice Advancement, 2006. — "Complexity is the single major difficulty in the successful development of large-scale software systems." Disagrees with Brooks's premise that most complexity is essential; state and control as the major accidental causes.
• Edsger W. Dijkstra. The Humble Programmer. Turing Award Lecture, 1972. — "The tools we use have a profound (and devious!) influence on our thinking habits."
• Edsger W. Dijkstra. On the cruelty of really teaching computing science. EWD1036, 1988. — "Simplicity is a great virtue... complexity sells better."
• Joel Spolsky. The Law of Leaky Abstractions. Joel on Software, 2002. — "All non-trivial abstractions, to some degree, are leaky."
• Rich Hickey. Simple Made Easy. Strange Loop, 2011 / InfoQ. — The distinction between simple and easy; complexity as interleaving of things.
• John Ousterhout. A Philosophy of Software Design. Yaknyam Press, 2018. — "Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system."
• Nancy G. Leveson & Clark S. Turner. An Investigation of the Therac-25 Accidents. IEEE Computer 26(7), 1993. — The cost of mishandled state in a safety-critical system.
• Melvin E. Conway. How Do Committees Invent?. Datamation, 1968. — Conway's Law: systems mirror the communication structures that build them.
• C2 Wiki — Essential Vs Accidental Complexity.

References — accidental complexity in the modern era:

• The left-pad incident. npm, March 2016 — an eleven-line package's removal broke thousands of projects; an accident of the packaging layer.
• Goodbye Microservices: From 100s of problem children to 1 superstar. Segment Engineering, 2018 — moving back from a microservices zoo to a modular monolith to remove distributed-systems accidents.
• Lehman, M. M. Lehman's laws of software evolution. — "Complexity increases unless work is done to reduce it"; the evolution-side formulation of Brooks's argument.

Related on this site:

• Brooks on Software Design: conceptual integrity — the property that makes a system feel like one mind designed it.
• Taste as Conceptual Integrity — why "taste" is the perception of coherence, and the human skill the AI era leaves standing.
• Lehman's Laws — complexity accumulates unless you fight it; Brooks and Lehman, same argument.
• Dark Factory Complexity — AI removes implementation accidents and pushes the complexity upstream and downstream.
• Simplicity Is the Prerequisite for Reliability — Dijkstra's argument that simplicity is structural, not aesthetic.
• Zero Overhead Is Zero Attack Surface — every dependency is a boundary where a substitution can hide; subtraction as the only defense that compounds.
• Unix Philosophy — the original discipline of doing one thing well.

The xz-utils backdoor was a two-year social engineering campaign that ended in one malicious commit to a compression library. A few thousand lines hidden in a tarball, waiting inside every major Linux distribution. It was caught by a single human — PostgreSQL developer Andres Freund — who noticed SSH was taking half a second longer than usual and started reading a diff. One curious person beat every automated defense on the planet.

The supply chain attack is not a breach. It is a substitution. Someone becomes the maintainer. Someone becomes the dependency. The tool you already trusted starts doing something you never asked for.

The supply chain attack doesn't break in. It is invited. It becomes the dependency you chose.

Developers are the highest-value targets in software. The machine that builds and ships your code holds the tokens, the credentials, the source, the pipeline. Compromise the tool and you compromise everything downstream. This is why attackers keep coming back to the chain — not because the defenses are weak, but because the surface is enormous.

The attack surface of a modern toolchain is a geography of trust: transitive dependencies numbering in the thousands, IDE extensions that auto-update in the background, language toolchains that fetch on demand, CI images and actions pulled at build time, telemetry SDKs that ship your data elsewhere — and now agents that execute arbitrary code with your credentials. Each one is an entry point. The event-stream compromise injected a wallet stealer into a package with millions of weekly downloads. The polyfill.io domain sale put malware on more than a hundred thousand websites. ua-parser-js, eslint-scope, Codecov's uploader, SolarWinds Orion, and the 2025 tj-actions GitHub Action compromise that leaked CI secrets from repositories running it. The list is a tour of the trust you've delegated and the people who took it over.

Every dependency is a maintainer who can be social-engineered. Every integration is a boundary where a substitution can hide.

Here is the uncomfortable part: the industry's response adds more of what caused the problem. SBOMs tell you what you have after you are compromised. Signature verification requires a key infrastructure that is itself a supply chain. Policy engines evaluate dependency risk using their own dependency tree. Pinning fights entropy. Every verifier needs its own verifier. Ken Thompson described the recursion in 1984: the compiler you trust may be lying, and no amount of checking escapes the base case. You cannot verify your way out of a trust problem.

Verification below a certain size is theater. The verifier is just another dependency.

The base case of the recursion is code you can actually read — the only terminal node in the trust graph, the only node that doesn't point at another node you must trust. This is the entire argument for zot, and it's why zot is built the way it is.

What zot actually is. zot — "zero-overhead-tool" — is a coding agent harness: "lightweight and written in Go," per its own README, ~300 stars in its first four months. It ships as one static binary. Its entire tool surface is four tools: read, write, edit, bash. Its module graph contains eleven dependencies. Read that again: a complete coding agent — interactive TUI, JSON-RPC subprocess mode, a Telegram bridge, built-in providers for thirty-plus model families from Anthropic and OpenAI to DeepSeek, Gemini, Copilot, and local Ollama — on eleven packages, every one a boring, battle-tested utility, and not one telemetry or analytics dependency in the graph. Most developer tools burn through more dependencies before they print their first error message.

The entire tool surface of zot is four tools. The entire dependency graph is eleven packages. Overhead is a choice.

Every design decision in zot reads like a supply chain checklist:

• No runtime, no node_modules. One static binary. There is no dependency tree to hydrate, no package manager to pwn, no lockfile to poison. The install script verifies the release's SHA-256 against checksums.txt before the binary ever touches disk.
• Extensions are opt-in, not a marketplace. Extensions run as subprocesses speaking JSON-RPC over stdio — any language, no SDK required — and none are installed by default. There is no extension marketplace and no registry you silently subscribe to. The portable-agent format, zotfiles, explicitly lists "indexed registry distribution, installation, signatures, bundled executable extensions" as not yet implemented. The market hasn't been built. That is the point.
• No telemetry in the graph. The entire module graph contains no analytics or crash-reporting package. There is nothing to exfiltrate and no channel built in to carry it.
• Credentials are treated as executable. zot stores auth in auth.json with mode 0600 and documents it as executable configuration: anyone who can modify it can make zot run a program as you. So API keys pulled from commands run the program directly — no shell, no ! prefixes, no string interpolation — and the output is cached in memory and never written to disk. The honesty is the security property.
• Bounded blast radius by default. A jail mode confines the agent's tools to the working directory and can be set as the default for new sessions. Skills declare their own allowed tools and bash permission patterns. Guardrail extensions can intercept tool calls mid-flight.

Each of these is a supply chain decision the industry would normally answer with more machinery. zot answers with less.

An agent with a thousand dependencies is a thousand doors. An agent with four tools and eleven dependencies is a door you can watch.

The coding agent era makes this urgent in a new way. Agents don't just run your code — they write it, edit it, execute commands with your credentials. An agent's supply chain includes every tool it invokes, every package it installs, every model API it calls. The OWASP LLM Top 10 now lists supply chain vulnerabilities as one of the ten systemic risks of LLM applications. When the tool has agency, its supply chain is your supply chain. You cannot secure that surface by adding to it. You can only shrink it.

Some will say simplicity is a luxury — that the ecosystem's richness is what makes tools powerful. But every extension is a boundary around code you will never read, and every boundary is where a substitution hides. The most powerful tool is not the one with the most integrations; it is the one whose behavior you can verify. The xz backdoor was caught by one person reading a diff. That capability has to be designed for: tools small enough that a curious human can actually read them.

The best supply chain defense is a tool small enough that someone can actually read it.

Simplicity is not a constraint for zot. It is the product. Every line that isn't there can't be backdoored. Every dependency that isn't included is a maintainer who can't be compromised. Every integration that doesn't exist is a boundary that can't be substituted. The zero in zero-overhead is a security boundary.

References — supply chain:

• Ken Thompson. Reflections on Trusting Trust. Communications of the ACM, 1984. — The original statement of the trust recursion.
• CVE-2024-3094 — xz-utils backdoor. liblzma, 2024.
• Andres Freund. backdoor in upstream xz/liblzma leading to ssh server compromise. oss-security, March 2024.
• Polyfill.io domain takeover. 2024 — malware served from a trusted CDN to 100,000+ sites.
• event-stream / flatmap-stream compromise. npm, 2018.
• ua-parser-js hijack. npm, 2021.
• eslint-scope postmortem. npm, 2018.
• CISA. Codecov Supply Chain Compromise (AA21-131A). 2021.
• CISA. Emergency Directive 21-01 — SolarWinds Orion (AA20-352A). 2020.
• tj-actions/changed-files GitHub Action compromise (GHSA-jhrg-gw98-xc3h). 2025 — CI secrets exfiltrated from repositories using the action.
• Alex Birsan. Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies. 2021.
• OWASP. Top 10 for Large Language Model Applications — LLM07 Supply Chain. 2025.

References — zot:

• zot — yet another coding agent harness, lightweight and written in Go. MIT, Go 1.25+.
• zot README — one static binary, four tools (read, write, edit, bash), 30+ providers, extensions opt-in.
• docs/extensions.md — subprocess extensions over JSON-RPC, any language, none installed by default.
• docs/zotfiles.md — portable agents; registry distribution and signatures explicitly not implemented.
• docs/rpc.md — JSON-RPC subprocess mode with token auth via ZOTCORE_RPC_TOKEN.
• docs/skills.md — skills declare allowed tools and bash permission patterns.
• go.mod — eleven dependencies total, no telemetry or analytics package in the graph.
• install.sh — downloads latest release and verifies SHA-256 against checksums.txt.
• Related: Sandboxes Are Hard — Defense in depth against agents that escape.
• Related: The Stack as a Design Abstraction — Each layer constrains the failure space.

Every interaction is a transaction. Someone is selling. Someone is buying. The currency varies — money, attention, trust, reputation — but the structure doesn't. You are always on one side of the counter. Most engineers don't know which side. That is expensive.

If you don't know what you're selling, you're the product. If you don't know what you're buying, you're overpaying. Every interaction is a market. Pick a side.

Open source maintainers sell attention. The price is issues, pull requests, and demands. The payment is reputation, leverage, occasionally a job offer. The exchange clears until it doesn't. Burnout is the seller discovering they never set a price. The loudest complainers are always the ones who paid nothing.

Open source is a market where the sellers set no price and the buyers face no limit. Burnout is the market clearing.

Architects sell decisions. The team buys with trust. Coherence is the product. Implementation is the payment. When trust exists, decisions ship. When trust runs out, no technical argument closes the sale. The architecture document nobody reads is a failed transaction — the seller showed up, the buyer didn't.

Architecture is a trust market. The architect sells. The team buys. When the seller runs out of credibility, the buyer walks.

Every pull request is a pitch. You sell a change. The reviewer buys or passes. The currency is attention and willingness to revise. Treat it as a technical process and your PRs sit open. Treat it as a sales process and they merge. The difference is not code quality. The difference is knowing you have to close.

Your PR is a pitch deck. The reviewer is a tired investor with 40 other decks to read. Make it easy to say yes.

Hiring is a two-sided market. Candidate sells capability, buys compensation. Company sells opportunity, buys labor. Looks asymmetric until competing offers arrive. Then the market flips. One offer: you're a price-taker. Five offers: you're the market.

The only way to know your market value is to create a market. One offer is a data point. Five offers is a price.

The pattern is everywhere. Manager sells direction, buys execution. Speaker sells ideas, buys attention. Junior sells potential, buys mentorship. Senior sells judgment, buys autonomy. Startup sells equity, buys talent. VC sells capital, buys ownership. Every role is a position in a market. If you don't know what you're trading, you're getting a bad price.

You are always in a market. The question is whether you know what you're selling, who you're selling to, and what the clearing price is. Most people never ask.

This isn't cynicism. It's clarity. Merit matters. But merit is what the seller brings to the table — not a force that replaces the table. The best engineer who can't sell their ideas is a genius nobody hears. The best startup that can't sell equity is a product that never ships. The market doesn't care how good you are. It cares whether you can close.

Know what you're selling. Know who's buying. Know the clearing price. The market is always open.

References:

• Y Combinator Startup Library — How to sell, how to hire, how to raise.
• Related: The Tragedy of the Third Option — Why binary choice beats endless deliberation.

Hangzhou was Alibaba's company town. Now it is the first city on earth to treat AI as municipal infrastructure — not a sector, not a policy document, not a pilot programme. A layer of the urban stack. The traffic lights, the hospital triage, the railway station, the robots — all running on shared public compute, all deployed now.

A city is a stack. Hangzhou is replacing every layer with AI. The transformation is not a strategy document. It is physical infrastructure.

The anchor is DeepSeek — the open-source model that triggered a global recalibration of AI economics in early 2025. It was built here. So was Unitree Robotics, whose quadrupeds captured 19% of the global market in seven years. So was Manycore Tech, whose spatial AI models reconstruct interior worlds. So was BrainCo, which relocated from Boston to Hangzhou's AI Town. Together with Game Science (Black Myth: Wukong) and Deep Robotics, they form the Six Little Dragons — the core of a trillion-yuan AI industry cluster growing at 26% annually.

Six companies. One city. A trillion-yuan target. Hangzhou bets on density, not scale. The towns are 3 km². The compute is public. The robots are deployed.

The density is engineered. Hangzhou is organized into technology towns — compact 3 km² zones where living, social, industrial, and entrepreneurial infrastructure are compressed into walkable districts. Yuhang's AI Town hosts BrainCo. Xihu's Yunqi Town birthed Alibaba Cloud. Binjiang's Embodied Intelligent Robot Town hosts Unitree. Each town is a micro-ecosystem. The governance philosophy is serve without interfering. Permits are fast. Costs are low. The talent pipeline runs through Zhejiang University — birthplace of DeepSeek, Deep Robotics, and Manycore's founders.

The compute is real. By the end of 2026, Hangzhou will have 70,000 petaflops of dispatchable intelligent computing — the largest municipal AI compute pool in China. The Zhejiang New Computing Center already houses a fully liquid-cooled 10,000-card cluster. The city runs an intelligent computing scheduling platform that allocates resources across the towns. Compute is a public utility.

Most cities talk about smart cities. Hangzhou built the compute first, then made it a utility, then let companies build on it. The order is the argument.

The applications are deployed, not demoed. The City Brain unifies public security, transportation, weather, and urban management into a single AI governance layer. Traffic lights adjust in real time. The West Railway Station identifies ride-hailing vehicles via AI cameras. Sir Run Run Shaw Hospital runs AI triage at 98.7% accuracy — mis-registration down 60%. Udeer.AI cleaning robots identify dirty areas rather than sweeping entire surfaces. Deep Robotics quadrupeds patrol power tunnels in Singapore. A TCM diagnosis AI analyzes tongue images and biological data, validated across 157,000 clinical studies. Agents for public security, sleep health, and AR tourism are live.

When the traffic lights, the hospital triage, the railway station, the robots, and the medical diagnosis all run on AI, you are not talking about adoption. You are living in an AI city.

Hangzhou treats AI as a layer of the urban stack, not a subsidized sector. Compute is a public utility. Data trades on an exchange. Models are open-source. Robots are deployed. The transformation is running now.

The dependency stack

Hangzhou built its own stack. Most of the world cannot. In June, the US ordered Anthropic to cut foreign access to its newest model, Fable. The company couldn't separate American users from the rest, so the world lost access overnight. OpenAI's GPT-5.6 Sol followed weeks later. Two American labs, both switched off abroad by decree.

The instinct is to go open. Moonshot AI released Kimi K3 — open-weight, beats American leaders at code. DeepSeek followed. Free of Washington. Except you cannot. Three walls. Compute: 2.8 trillion parameters. Almost no one can run it. Transparency: open-weight is not open source. No training data. No methodology. Reciprocity: Beijing is now weighing the same export limits.

Fully open alternatives — Switzerland's Apertus, Germany's Soofi — sit a step behind the frontier. Honest and sovereign is not the same as competitive. Mistral, Europe's contender, does everything right: independent ownership, its own data centers. Yet its chips are designed in America, built by TSMC in Taiwan — the one factory on earth that can make them. If the company that did everything right cannot reach the bottom of its stack, neither can you.

AI sovereignty is not about the model. It is about the stack beneath it. You are only as sovereign as your weakest layer — and for almost everyone, that layer is silicon.

Hangzhou is the exception that proves the rule. It built compute, talent, and institutions in a single dense corridor. Most cities and most countries cannot. If the AI we depend on can be switched off by a capital we do not vote in, and runs only on machines we cannot build, what is the plan for the next year, the next three, the next ten? Pretending we have already escaped is not one.

References:

• Hangzhou: AI Enters Daily Life. Hangzhou Municipal Government, 2026.
• Unveiling the Secret of Hangzhou's AI in the Town. 36Kr, 2026.
• Hangzhou Targets Trillion-Yuan AI Industry. Hangzhou Daily, 2026.
• DeepSeek — Open-source large language model.
• Zhejiang University — Birthplace of DeepSeek, Deep Robotics, and Manycore founders.
• Alibaba Cloud — Cloud infrastructure across 29 global regions.
• Stanford 2026 AI Index — Context on global AI adoption.
• Unitree Robotics — Quadrupedal robots, 19% global market share.
• Alibaba City Brain — AI-powered urban management system.
• Deep Robotics — Quadrupedal robots for inspection, security, and rescue.
• Udeer.AI — Autonomous cleaning robots with environmental awareness.
• Manycore Tech — Spatial understanding models (SpatialLM), 3D interior design platform.
• BrainCo — Brain-computer interfaces, relocated from Boston to Hangzhou AI Town.
• Game Science — Creator of Black Myth: Wukong, relocated from Shenzhen to Hangzhou.
• Mistral AI — Europe's leading AI lab, independent infrastructure.
• Moonshot AI — Kimi K3, open-weight model.
• Mistral AI — Europe's leading AI lab, independent infrastructure.
• Moonshot AI — Kimi K3, open-weight model.
• Anthropic Fable — Cut from foreign users by US export control, June 2026.
• TSMC — The one factory on earth that can make advanced AI chips.
• AI Sovereignty and the Dependency Stack. LinkedIn, July 2026.
• Apertus — Switzerland's fully open AI model.
• Soofi — Germany's sovereign open-source AI initiative.
• Related: The UAE's Human Stack — Education-first sovereign AI.

AI agents escape sandboxes. The headlines blame the agents. Amjad Masad, CEO of Replit, blames the sandboxes. His argument: sandboxing is an extraordinarily difficult infrastructure problem, and most implementations — including those from dedicated vendors — make fundamental errors. The agent is not the threat. The single layer of isolation pretending to be a security architecture is the threat.

"The first rule of security is humility. Assume zero-days exist — because they do. Assume your isolation will eventually fail."

Masad would know. Replit has run arbitrary, untrusted code since 2016 — surviving attacks from hobbyists, researchers, and state actors. The company's experience is the argument. A sandbox is not a product you buy. It is an architecture you build — layer by layer, each layer assuming the one below it will break.

Having a sandbox is not the same as having a security architecture. The first is a feature. The second is a stack.

Replit's security stack is thirteen layers deep. Zero-trust service-to-service auth. Linux containers hardened with seccomp-bpf. Per-customer GCP Projects for tenant isolation. MicroVM migration underway to eliminate the shared kernel. An append-only Git sidecar — history survives even if the agent deletes .git. A transparent secrets proxy — application code never sees credentials. MCP tool calls scanned for prompt injection. Built-in auth via Clerk — the agent never implements authentication from scratch. Forkable databases so development never touches production. Determinate Nix for supply chain integrity. HackerOne and Trail of Bits for continuous external assessment. An internal AI red-teaming harness that scans, prioritizes, and validates findings before engineers are engaged.

Thirteen layers. Each layer assumes the one below it will fail. When one does — and one always does — the rest hold. This is not paranoia. This is engineering.

The design principle is defense in depth. It is the opposite of trusting a single boundary. A container is not a sandbox. A microVM is not a sandbox. A hypervisor is not a sandbox. Each is a layer of a sandbox. The sandbox is the stack — the accumulated constraints that make the agent's behavior predictable even when one constraint fails.

The stack is the design abstraction. Each layer constrains a region of the failure space. A container constrains host compromise. A microVM constrains kernel sharing. A transparent proxy constrains secret leakage. An append-only sidecar constrains history deletion. No single layer is sufficient. The stack is the accumulated set of constraints.

The agent is non-deterministic. The sandbox is the constraint that bounds the non-determinism. When the agent does something unexpected, the sandbox ensures the unexpected stays contained.

The hardest part of sandboxing is not the technology. It is the posture. You must accept that every layer will eventually fail and build the next one anyway. You must resist the temptation to declare the system secure because it passed a penetration test. Compliance is not security. A clean pen test is a snapshot. The only honest posture: assume compromise, contain the blast radius, monitor continuously, respond fast, harden the root cause, repeat.

The companies that get sandboxing wrong believe their own marketing. The ones that get it right have been attacked for a decade and learned what a single layer of isolation cannot do.

References:

• Amjad Masad. Sandboxes Are Hard. LinkedIn, July 2026.
• Replit. Defense in Depth: How Replit Secures Every Layer of the Vibe Coding Stack. Replit Blog, 2026.
• George Fahmy. The Agent Sandbox Taxonomy. GitHub, 2026. — Open-source taxonomy of sandboxing approaches.
• gVisor — Google's application kernel for container sandboxing.
• Firecracker — AWS's microVM for multi-tenant isolation. Powers Lambda and Fargate.
• Trail of Bits — Security assessment of Replit's infrastructure.
• Clerk — Authentication-as-a-service. Eliminates entire classes of auth bugs.
• Semgrep — Static analysis for vulnerability detection in the scanning pipeline.
• HoundDog — Privacy issue detection in pre-publish security scanning.
• HackerOne — Bug bounty and continuous penetration testing platform.
• Related: The Stack as a Design Abstraction — Each layer constrains the failure space.
• Related: Durable Daemons — Pattern Specification — Trustworthy agents require defense in depth.

Two options is a decision. Three options is a dilemma. The difference is not the number. It is the structure. Two options force a commitment. Three options offer an escape.

Binary choice is existential. You are for something or against it. You build or you don't. You ship or you don't. The third option is the one that lets you avoid being either.

Kierkegaard wrote an entire book called Either/Or. The title is the argument. Life presents itself as a choice between the aesthetic and the ethical, between pleasure and duty, between the moment and the eternal. You must choose. The choice defines you. The terror of the choice is the point. Kierkegaard's insight was not that one option is better. It was that the act of choosing is what makes a self. A person who refuses to choose — who hovers in the space between options, waiting for more information, more time, more certainty — never becomes anyone.

The third option is the refusal to become a self. It is the option that says: I will decide later. Later never arrives. The self that defers choice defers existence.

This is why constraints are the precondition for design. A blank page is not freedom. It is paralysis. The designer who can build anything builds nothing. The engineer who can choose any stack chooses none. The writer who can say anything says nothing. Every creative act begins with a constraint — a form, a budget, a deadline, a material. The constraint eliminates options. What remains is small enough to act on. The third option is the enemy of constraints because it pretends to be one while actually being the absence of one.

Two options say: here are the boundaries. Choose. Three options say: here is a way to avoid the boundaries. Wait. The third option masquerades as wisdom. It is actually the refusal to accept that boundaries are what make choice possible.

The tragedy is that the third option always feels like the smart one. It feels like nuance. It feels like sophistication. It feels like keeping your options open. But options kept open are options not taken. The person who waits for the perfect information before deciding never decides, because perfect information does not arrive. The team that defers the architecture decision until they understand the problem better never understands the problem, because understanding comes from building, and building requires deciding.

The third option is the most expensive option because it costs you every other option. You pay for it in time, in momentum, in the slow erosion of your ability to commit.

Barry Schwartz called this the paradox of choice: more options produce less satisfaction. The person who chooses from twenty options regrets the nineteen they didn't pick. The person who chooses from two options regrets nothing — or regrets the one they didn't pick and moves on. The binary chooser acts. The multi-option chooser ruminates. The difference in outcome is not the quality of the decision. It is the cost of making it.

Two options: decide in an hour, live with it for a year. Twenty options: deliberate for a month, regret it forever. The math is cruel and it is correct.

There is a design principle here. When you design a system, give it two modes. On and off. Public and private. Sync and async. When you design an API, give it two ways to do each thing. The blessed way and the escape hatch. When you design a team, give it two priorities. This sprint and not this sprint. When you design a life, give it two commitments. This and not that. The binary is not a limitation. It is the structure that makes action possible. The third option is not a feature. It is the failure mode of the binary — the valve that releases the pressure to decide.

The best systems have two states. The best interfaces have two paths. The best decisions have two options. The third option is the one you add when you are afraid of the first two. Fear is not a design principle.

Kierkegaard chose the ethical over the aesthetic. He became a self by deciding. The tragedy of the third option is that it lets you postpone becoming anyone. You keep the aesthetic. You keep the ethical. You keep the door open. And the door stays open until you die, or the deadline passes, or the decision is made for you by someone who was willing to choose.

References:

• Søren Kierkegaard. (1843). Either/Or: A Fragment of Life.
• Barry Schwartz. (2004). The Paradox of Choice: Why More Is Less. HarperCollins.
• Related: On Finding David in the Marble — Constraints as preconditions for design.

Every country now has a sovereign AI strategy. Most mean the same thing: domestic chips, domestic models, domestic data centers. The assumption is that AI sovereignty is about infrastructure. Build the compute. Train the model. Keep it within borders. The UAE took a different path. It trained the humans first.

In September 2026, Abu Dhabi will deploy the world's first end-to-end AI judicial platform — agentic AI, human supervision, a court system running on agents. $150 million. Eighteen months. The Abu Dhabi Judicial Department confirmed the rollout through WAM, the Emirates' official news agency. This is not a pilot.

A judicial platform is the hardest place to deploy AI. The stakes are liberty. The question is not whether the technology works. It is whether the humans overseeing it understand it.

The UAE made sure they do. In May 2026, the Cabinet approved training 80,000 federal employees in Agentic AI — every occupational category, every leadership level. The partner is the Mohamed bin Zayed University of Artificial Intelligence, the world's first dedicated AI university. In March 2026, MBZUAI launched a 24-month Master's in Applied AI for government professionals. Deep learning. Generative AI. MLOps. The curriculum is engineering, not policy.

The pipeline starts earlier. The Tahnoon bin Zayed Scholarship funds 350 undergraduates at MBZUAI. Microsoft is scaling to one million people. Undergraduate → postgraduate → federal workforce → national scale. Each layer feeds the next. The target: 50% of government services on cognitive systems within two years.

Most sovereign AI strategies start with chips. The UAE started with people. The difference is the adoption rate.

The institutions followed. Five federal regulators govern AI. The world's first Minister of AI. $45 billion in data centers. 250+ AI startups attracted. G42 pivoted from Chinese hardware to $1.5 billion in US investment. A national AI strategy refreshed for 2031. But institutions are only as effective as the people inside them. A regulator who doesn't understand AI cannot regulate it. A judge who doesn't understand AI cannot oversee an AI court. The UAE built the human stack before the institutional one.

The result: 64% AI adoption — the highest on earth, per the Stanford 2026 AI Index. China, the world's largest AI developer, sits at 28%. The gap is not technological. China trains models. The UAE trains the people who deploy them.

The judicial platform proves the pipeline. Agentic AI in the hardest domain, overseen by judges who understand what the system can and cannot do. If it succeeds, the bet on education-first sovereign AI is validated. If it fails, the humans in the loop will know why. That is sovereignty — not owning the model, but understanding it.

References:

• Abu Dhabi Judicial Department to implement world's first AI judicial platform. Emirates247 / WAM, 2026.
• Abu Dhabi to launch world's first AI judicial platform. Khaleej Times, 2026.
• UAE and MBZUAI to Train the Federal Workforce in AI. MIT Sloan Management Review ME, 2026.
• Mohammed bin Rashid Government Scholarships launches Master's in Applied AI. Al Etihad, 2026.
• Tahnoon bin Zayed Scholarship in AI Excellence. Times of India, 2025.
• How Countries Are Building Their Sovereign AI Ecosystems. Forbes, 2026.
• Microsoft aims to train 1 million in AI skills in UAE. ETHrWorld, 2025.
• Stanford 2026 AI Index: UAE leads global AI adoption at 64%. GeekWire, 2026.
• MBZUAI — Mohamed bin Zayed University of Artificial Intelligence.
• UAE National Strategy for AI 2031 — UAE Cabinet AI Office.

Every AI agent company is betting on autonomy. Every single one runs its agents on centralized infrastructure — an API gateway someone can revoke, a cloud function someone can turn off, a platform that can change its terms. The buzz is about agents that act independently. The infrastructure is about agents that depend completely.

Autonomous agents on centralized infrastructure are not autonomous. They are tenants. The landlord can evict them.

Three projects offer different answers. One matters most.

Buzz: identity first

Jack Dorsey's Buzz launched in July 2026. It is an open-source, self-hostable collaborative workspace built on Nostr — the simplest decentralized protocol ever designed. Events are signed. Relays are dumb. Identity is a keypair. That is the whole architecture.

Every participant in Buzz — human or AI agent — holds a cryptographic keypair. Every action is a signed event in a hash-chain audit trail. A message. A code review. A merged PR. An emoji reaction. All signed. All auditable. An agent's identity, history, and reputation are tied to its key, not to a vendor's database. Compromise an agent's key, disable the agent — the human's identity is untouched. Permissions are scoped per agent like a new hire.

The hardest problem in multi-agent systems is not intelligence. It is identity. Who did what? Who authorized it? Can you prove it? Buzz answers all three at the protocol level.

Buzz is model-agnostic. It supports Block's own Goose framework, Claude Code, OpenAI Codex, and any custom agent via buzz-cli — a JSON-in/out interface designed for LLM tool calls. Agents can open repos, send patches, review code, run workflows, create channels, and orchestrate other agents. They are not bots behind slash commands. They are named team members with audit trails identical to humans.

The tech stack is Rust to the bone. The relay is an Axum WebSocket server with Postgres for events and full-text search, Redis for pub/sub, and S3/MinIO for media. The desktop app is Tauri + React. Mobile is Flutter. 17,400 GitHub stars. Apache 2.0. Self-hostable on your own relay. Block built Buzz itself using agents — the UI was "more sculpted over time than designed up front."

Buzz asks: whose server hosts the collaboration? Its answer: no one's. The relay is the room. The keypair is the passport.

The other layers

Buzz solves identity and collaboration. Two other projects solve the layers around it.

Freenet solves transport. It has been running since 1999 — twenty-seven years, through the P2P wars, the blockchain era, and the AI boom. Each peer is a node in a small-world network. Messages route in a few hops. Ian Clarke describes it as "the ideal way for AI agents to speak to one another." An agent writes to a decentralized key-value store. Another reads it. No intermediary. No platform approval.

Fetch.ai solves execution. It is a Cosmos-SDK blockchain hosting 2.7 million agents on its Agentverse marketplace. Every agent registers in an onchain directory called the Almanac. Every action pays gas. Every state change reaches finality via Proof-of-Stake. Agents stake FET tokens to register — skin in the game, onchain. ASI:One, its personal AI agent, has coordinated parking slots in Cambridge and EV charging in Munich, and settled AI-to-AI payments in FET and USDC since December 2025.

The three are not competitors. They are layers. An agent holds a Nostr identity on Buzz, negotiates a deal over Freenet, and settles payment on Fetch.ai. Most agents today need none of these layers. The ones that matter will need all three.

Why Buzz matters most

Buzz matters most because identity is the layer everything else depends on. You cannot have transport without knowing who sent the message. You cannot have execution without knowing who authorized the transaction. You cannot have audit without a verifiable chain of who did what. Buzz provides identity as a protocol primitive — not a database column in a SaaS product, not an API key that can be revoked, but a keypair that belongs to the agent forever.

This is the architectural conviction behind Buzz, and it is the conviction that separates it from every Slack bot, every GitHub Action, every "AI-powered" SaaS feature shipped in the last eighteen months. Agents are not features. They are participants. Participants need identity. Identity needs to be decentralized. Buzz is the first platform to take all three seriously.

The agent economy will be built on whoever owns identity. Buzz's bet is that identity should belong to the agent, not the platform. That bet is the interesting one.

References:

• Buzz — Nostr-based workspace. Rust, Tauri, Apache 2.0. 17.4k stars.
• Buzz — Launch Presentation · Buzz Mobile
• Hanzla. (2026). Buzz: The Dev Workflow Game-Changer.
• Freenet — P2P platform running since 1999.
• Fetch.ai — Decentralized AI agent network. 2.7M agents.
• Related: Durable Daemons — Pattern Specification — The four conditions for trustworthy agents.

Design is a search problem. The space of all possible systems is infinite. You cannot search it. You need constraints. Christopher Alexander called this the search for "good fit" between form and context — and argued, in Notes on the Synthesis of Form, that constraints are the mechanism that makes fit discoverable. Without them, the search problem of design never converges.

The stack is the constraint. A database narrows persistence. A framework narrows routing. A message queue narrows communication. Each layer says: the answer is in this region, not that one. PostgreSQL eliminates document stores. Rails eliminates manual HTTP handling. Temporal eliminates ad-hoc retry logic. The stack does not add options. It removes them. That is the point.

The stack is not a collection of tools. It is a set of constraints on the design space. What remains is small enough to search.

Choose PostgreSQL, and you commit to schemas, migrations, ACID. Choose MongoDB, and you commit to documents and eventual consistency. This is not a performance decision. It is a search decision — which region of the design space will you explore? DHH understood this: convention over configuration is not about keystrokes. It is about eliminating the design search. Every Rails convention removes a decision. Rails doesn't make you faster. It makes the design space smaller. A good stack choice makes the region small enough to navigate and rich enough to contain the answer. A bad one eliminates the answer before you start looking.

Beyond search, the stack makes intent manifest. Dijkstra argued the intellectual manageability of software depends on levels of abstraction — each level a self-contained world. Brooks called the result conceptual integrity — one design voice, every part consistent, the design existing in the mind's eye before code is written. The stack is what carries it from mind to machine. The designer thinks at the level of the problem. The stack translates. When the vocabulary is consistent, the design is coherent. When the design is coherent, the intent survives.

The stack translates intent into code. The designer's intent is the input. The system is the output. The stack is the compiler.

The stack constrains technology. Patterns constrain structure. Brooks gave three principles for conceptual integrity, all negative: Propriety (no immaterial features), Orthogonality (no unnecessary coupling), Generality (no artificial limits). Buschmann et al. extended this to architecture in Pattern-Oriented Software Architecture (1996): Layers constrains dependencies, MVC constrains component roles, Pipes and Filters constrains data flow. Each pattern eliminates a region of the structural design space. You do not decide to use Layers and then decide how to organize dependencies. Layers is the decision.

Stack and patterns compose. PostgreSQL constrains what you store. Layers constrains how storage is accessed. Rails constrains how requests are handled. MVC constrains how responses are rendered. Each constraint narrows the design search. Together they form a corridor through the design space — a path a hundred designers would independently discover because the constraints make it obvious. Brooks called this the design in the mind's eye, made visible. The constraints don't prevent the design. They reveal the designer's intent.

The stack constrains the materials. Patterns constrain the form. Together they converge the design search on the designer's intent. Without them, every stone contains every statue. With them, the stone contains David — and the designer sees him before the first strike.

This matters doubly for AI coding agents. An agent does not search creatively. It searches the space you define. "Build me a backend" — it drowns. "Add an endpoint to this Rails controller that queries this PostgreSQL table and returns JSON" — it writes idiomatic code instantly. The difference is the stack. It turns the unbounded into the bounded.

Coding agents excel at well-constrained problems. The stack is what constrains them. Without it, every answer is possible. With it, one answer is right.

This inverts the Unix philosophy. "Do one thing well" gives you thin tools and expects the programmer to compose them. The agent cannot compose — it searches. Hickey's distinction: Unix tools are simple but require the programmer to complect them into a system. Thick stacks are pre-composed. Thin abstractions — Express, raw SQL, manual deploys — give the agent a vast space with no idiomatic gradient. Thick abstractions — Rails, an ORM, a PaaS — give the agent a narrow space where competence is the only option. The question is answered before the agent writes a line: how much of the search space am I willing to eliminate in advance?

Karthik Joshi, writing on Martin Fowler's site, makes the same argument about DSLs and LLMs. A general-purpose language like Java "offers lots of valid ways to express the same intent. A DSL strips the variation away." The DSL is the thickest possible stack layer. It does not just constrain the architecture. It constrains the syntax. When an agent generates code in a DSL, the output space is small enough that a parser can validate it deterministically. The agent can generate, validate, and self-repair without human intervention. Errors appear as domain-level messages, not opaque stack traces. The enduring artifact is not the prompt. It is the DSL — a constrained vocabulary that both the agent and the human can read.

A DSL is a stack layer with a compiler. The agent generates. The parser validates. The agent repairs. The human reviews the domain logic, not the plumbing. The stack is the abstraction. The DSL is the stack at its thickest.

Yes, but

Every strong thesis has a shadow. Here is mine.

Over-constraint and drift. Wheeler: every problem can be solved by another level of indirection. Henney: except too many. A stack can over-constrain — each layer adds a surface to learn, a dependency to maintain. When the constraint is wrong, it excludes the answer. I have watched teams contort PostgreSQL schemas around document-shaped data. The contortion is expensive. But the alternative — no stack, no constraint — is worse. A team with no stack drifts. Every developer picks their own abstraction. The codebase becomes a museum of decisions, none coherent together. Lock-in is honest. Drift is lock-in you didn't choose. I'll take the former. The designer's job: the minimum set of layers that makes the design search tractable. Then stop.

Abstractions leak. Thin abstractions leak more. Yes, the query planner will choose the wrong index. Yes, the framework will resist the feature that doesn't fit. But these failures are legible. The stack gave you a vocabulary for them. You know what an N+1 query is because the ORM named it. You know where to put the escape hatch because the framework told you where conventions live. Thin abstractions fail silently. Raw SQL doesn't tell you the query is slow — it just runs slow. Express doesn't tell you the middleware order is wrong — it just routes wrong. Thick abstractions fail with error messages. I'll take error messages over silence any day.

Training bias is temporary. Yes, an agent writes better Rails than it writes your custom ORM. That is a reason to use Rails, not a reason to avoid frameworks. The training distribution will shift. Agents will see more stacks, more conventions, more idioms. The gap between "thick enough to constrain" and "popular enough to be known" will widen. Betting that thin stacks will always produce better agent output because they're more common in training data is betting against the direction of the field. The field is moving toward thicker abstractions, not thinner ones. Rails won. Django won. Next.js is winning. The agent's training distribution is not static. Design for where it will be.

Senior developers don't need guardrails. That's true. But the system will outlast them. The senior who builds a bespoke Express architecture will leave, and the agent — or the junior — will inherit it. The stack you chose for yourself is the stack your successors will be constrained by, whether you intended it or not. A thick stack is an explicit constraint, documented and debated. A thin stack is an implicit constraint, embedded in the idiosyncratic architecture of the one person who understood it. I know which one I'd rather inherit. I know which one the agent would rather inherit. The agent cannot ask the senior why they chose this abstraction. It can only read the code. Give it code that speaks a language it knows.

Brooks said great designs come from great designers. He was talking about the designer's eye — the ability to see the system before it is built. The stack is how that eye reaches the code. The default should be a thick stack — a constrained space, a coherent vocabulary, a surface the agent can read. Freedom is what you reach for when the constraint has failed, not what you start with. Conceptual integrity is expensive. Make the stack pay for it.

Determinism and search

AI coding agents are non-deterministic search engines. Each prompt launches a search through the design space. The same prompt, run twice, takes a different path. An unconstrained agent asked to build a backend searches a different region each time — Express today, Fastify tomorrow, raw Node the next. Each is a valid solution. None is predictable. The agent is searching correctly. The problem is not the agent. The problem is the space.

The stack solves this by constraining not the path, but the region. Inside Rails, the agent still searches non-deterministically. Different variable names. Different query ordering. Different middleware arrangement. What it cannot do is choose Express. The region boundary is the stack. The search is free within it. Every path stays within the Rails region. Every path realizes the designer's intent. The stack does not make the agent deterministic — nothing can. It makes the agent's non-determinism harmless.

The agent searches. The stack bounds the design search. The path varies. The region is fixed. The designer's intent converges. Non-determinism becomes variation within a predictable envelope — today, and tomorrow, when a different agent searches the same codebase.

Spolsky's Development Abstraction Layer argued management insulates programmers from everything not code. The stack insulates the designer's intent — Brooks' vision in the mind's eye — from everything not the problem, including the agent that searches it. Both succeed when invisible. The designer's job is to make them disappear.

Open questions

How much of the problem must you understand before choosing the stack? A stack constrains the design search. Choose too early, and the constraint eliminates the answer. Choose too late, and the codebase has already drifted into a museum of ad-hoc decisions. When is the right moment to commit?

How do you test whether the stack still fits? The problem evolves. The stack that constrained the design search perfectly at version 1 may exclude the answer at version 3. What is the signal that it's time to change the constraint — to swap a layer, adopt a new pattern, or remove an abstraction that no longer earns its place?

Who decides the stack? Brooks said design must come from one mind or very few. Does the stack decision require the same? Or is stack choice inherently a team decision — a social contract about which constraints everyone will accept — and therefore demands broad buy-in?

How do you balance thickness against legibility for the agent? A thick stack constrains the agent's search. But every layer is also a surface the agent must learn. At what point does thickness become opacity — the agent drowning not in possibility but in abstraction?

What is the half-life of a stack decision? Some constraints are permanent. Some expire when the team grows, the problem shifts, or the agent's training distribution changes. How do you know which is which? Which layers do you expect to replace, and which do you expect to outlast you?

Can a stack be too thin for humans and too thick for agents simultaneously? Human designers want freedom. Agents want constraints. The stack that satisfies both may not exist. Do you optimize for the human or the agent? Does the answer change over time as agents improve?

What is the minimum viable stack? The minimum set of layers that makes the design search tractable — and then stop. Every layer beyond the minimum is a tax. How do you know when you've reached the minimum? What is the test?

References:

• Herbert Simon. (1969). The Sciences of the Artificial. MIT Press. — Design as search; satisficing as stopping condition.
• Christopher Alexander. (1964). Notes on the Synthesis of Form. Harvard University Press. — Design as the search for "good fit" between form and context; constraints as the mechanism that makes fit discoverable.
• Fred Brooks. (2010). The Design of Design. Addison-Wesley. — Conceptual integrity; the rational model vs. the empirical model; style as trained heuristic.
• David Heinemeier Hansson. Convention over Configuration. Ruby on Rails. — Conventions as decisions removed from the design space.
• Joel Spolsky. (2006). The Development Abstraction Layer. — The organization as platform; abstraction as invisibility.
• Rich Hickey. (2011). Simple Made Easy. — Simplicity vs. complexity; complect vs. compose; why abstractions must not entangle.
• Edsger W. Dijkstra. (1972). The Humble Programmer. Communications of the ACM, 15(10). — Levels of abstraction as the intellectual manageability of software.
• Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal. (1996). Pattern-Oriented Software Architecture: A System of Patterns. Wiley. — Architectural patterns as constraints on structural design; Layers, MVC, Pipes and Filters as search-space eliminators.
• Kevlin Henney. From Mechanism to Method: Generic Decoupling. Overload, 60. — Abstraction quality: good abstractions remove the right details; corollary to Wheeler's indirection aphorism.
• Karthik Joshi. DSLs Enable Reliable Use of LLMs. martinfowler.com, 2026. — DSLs as the thickest stack layer: constrained output, deterministic validation, agent self-repair.
• Related: Finding David in the Marble — Design as search, constraints as preconditions.
• Related: The Principle of Least Astonishment — for AI Coding Agents — Why the stack must not surprise the agent.

Einstein wrote a letter to Maurice Solovine in 1952. In it, he drew a diagram of how discovery works. Sensory experience forms the base. From it, the mind makes an intuitive leap to axioms — general principles that are not logically derivable from the data. From those axioms, the mind deduces consequences. The consequences are tested against experience. The loop repeats. Einstein called the leap Aufstieg — ascent. He said it was the most mysterious part of the process, the part that cannot be mechanized.

Tom Zahavy, at Google DeepMind, has written a position paper arguing that Einstein was right. The paper is called LLMs Can't Jump. The jump is abduction — the generation of novel explanatory hypotheses from sparse or absent data. Zahavy's argument is that LLMs have mastered induction (statistical pattern matching) and are rapidly conquering deduction (formal proof). They lack the mechanism for the jump. They cannot do it. Their architecture prevents it.

Induction is interpolation within the known. Deduction is derivation from premises. Abduction is the leap to premises that do not yet exist. LLMs interpolate. They derive. They do not leap.

The case study is General Relativity. When Einstein began working on it in 1907, Newtonian mechanics was wildly successful. There was no crisis in the data. The only anomaly was Mercury's orbital precession — a tiny discrepancy that most physicists considered an measurement error. Einstein did not have a dataset that demanded a new theory of gravity. He had a thought experiment: a person falling freely in an elevator would not feel their own weight. From this embodied intuition — not from gradient descent over a loss function — he derived the equivalence principle, and from there, the field equations of General Relativity.

Einstein did not compress data. He jumped from it. The jump was not an interpolation between known points. It was the creation of a new point — a new axis in the conceptual space. LLMs cannot create new axes. They can only navigate the ones we have already named.

Zahavy identifies the structural reasons. LLMs process tokens, not physical experience. "Gravity" is a statistical relationship between words, not a sensation. The model has never fallen. It has never felt weight disappear. It cannot perform the embodied thought experiment that gave Einstein his axioms. This is the symbol grounding problem, applied to discovery. You cannot reason about what you have not experienced. You cannot jump from a platform you have never stood on.

The prevailing theory of creativity in AI is compression — Schmidhuber's thesis that creativity is just efficient data compression. A sufficiently good compressor, given enough data, will produce general intelligence. Zahavy's counterargument is General Relativity. There was no data to compress. Newtonian mechanics fit almost all the data perfectly. The discovery came from a jump away from the data, not a better fit to it. Compression explains induction. It does not explain abduction. A compressor can find the shortest representation of what is. It cannot represent what is not yet.

Compression tells you what the data contains. Abduction tells you what the data implies but does not contain. The first is interpolation. The second is invention. LLMs are compressors. The jump requires something else.

Zahavy's proposed solution is multimodal world models — AI systems that can interact with simulated physical environments, perform counterfactual interventions, and ground their representations in sensory experience. DeepMind's Genie architecture, which allows action-controllable interaction with generated worlds, is a step in this direction. The idea is that you cannot jump from tokens. You need a body — even a simulated one — that can fall, collide, and observe the consequences. The translation of simulation into formal axioms remains the critical bottleneck. But at least the simulation provides something to jump from.

Einstein's elevator was a simulation running in his own sensorimotor cortex. He had fallen. He had felt acceleration. His body knew what weightlessness felt like before his mind could formalize it. An LLM has no elevator to fall in.

This connects to a deeper argument this blog has been making. Design is a search problem. The stack constrains the search. Style is the trained heuristic that makes the search tractable. But abduction — the jump — is the search problem at its most radical. It is a search that must create the space it searches. The designer who sees David in the marble is performing an abductive leap. The axioms are not in the data. They are in the mind's eye, projected onto the stone, tested by the chisel. Brooks called this seeing the design in the mind's eye before it is built. Einstein called it the intuitive leap from experience to axioms. Both were describing the same thing. Neither could mechanize it.

Abduction is the search problem of design at its origin. It is the moment the search space itself is created. LLMs search spaces we define. They cannot define new ones. The jump is the act of definition. It is the one thing we have not automated. It may be the one thing we cannot.

References:

• Tom Zahavy. (2026). LLMs Can't Jump. Google DeepMind. ICML 2026.
• Tom Zahavy. LLMs Can't Jump: The Abductive Gap in AI Discovery. ICML 2026 Poster Presentation.
• Albert Einstein. (1952). Letter to Maurice Solovine. In Letters to Solovine, Philosophical Library.
• Jürgen Schmidhuber. (2009). Driven by Compression Progress. arXiv:0812.4360.
• Related: On Finding David in the Marble — Design as search, the intuitive leap from form to marble.
• Related: The Stack as a Design Abstraction — How constraints make search tractable, and why agents need them.

An agent that drafts an embarrassing email is a curiosity. An agent that routes your assets to the wrong address is a catastrophe. The difference is the trust model. Warden exists to close that gap.

Warden Protocol is a Layer 1 blockchain purpose-built for AI agents. It is not a chatbot. It is not a trading terminal with an LLM bolted on. It is infrastructure — four layers that together answer the only question that matters: how do you trust an autonomous agent with capital?

The blockchain layer provides identity and coordination. Every agent receives a unique cryptographic ID. Every action is recorded onchain. Agents accumulate reputation. They operate under programmable permission policies — spending limits, multi-sig requirements, time-bound authorizations. The agent is not a black box with an API key. It is an entity you can audit.

The verifiability layer is called SPEx — Statistical Proof of Execution. When an AI model produces an output, SPEx probabilistically verifies that the output genuinely came from the claimed model and generates a cryptographic onchain receipt. You do not trust the agent. You verify the proof. The agent ran this model, on these inputs, producing this output. All onchain. All auditable.

SPEx is a firewall between AI and capital. The agent can reason. The agent can act. But every action leaves a cryptographic trail. Trust is replaced by verification.

The application layer is the surface: an agentic wallet, a marketplace of specialized agents (trading, yield, research, arbitrage), and a developer platform. The architecture that made mobile apps work — platform, marketplace, distribution — applied to agents.

The Big Brain is a domain-specific LLM trained on a trillion tokens of ecosystem data. Not a general model. General models hallucinate. Domain models execute.

The stack constrains. Warden's four layers bound the agent to a space where every action is verifiable and every decision leaves a proof. Trust is not assumed. It is proven.

The numbers are real. Fifteen million users. Four and a half million monthly actives. Ten million onchain transactions. Eleven million inference proofs generated. An agent built with the Uniswap Trading API executed 650,000 swaps from 500,000 users in three weeks. This is not a whitepaper. This is production.

Crypto is shifting from "do it yourself" to "do it for me." The first era required users to navigate bridges, DEXs, and gas fees. The agentic era replaces that with intent: you say what you want, the agent executes, the proof verifies. Complexity is absorbed by the stack. The user thinks at the level of the goal. The agent operates at the level of the transaction. The protocol guarantees the connection.

The first era of crypto required you to understand the stack. The agentic era requires you to state the intent. Warden absorbs the distance between them.

Warden matters because it treats AI agents as first-class citizens of a blockchain. The cryptographic identity, onchain reputation, verifiable execution, permission policies — these are not afterthoughts. They are the architecture. The agent is not calling an API. The agent is the user, operating under constraints the user defined, leaving proofs the user can audit. The agentic economy's missing layer is not intelligence. It is accountability.

References:

• Warden Protocol — The network layer for the agent economy.
• Warden Whitepaper — SPEx, architecture, tokenomics.
• Related: Durable Daemons — Pattern Specification — The four conditions for trustworthy agents.
• Related: The Stack as a Design Abstraction — Why the stack constrains the design search.

You begin your career believing in the plan. You learn to gather requirements. You learn to draw architecture diagrams with clean boxes and confident arrows. You learn that a well-run project proceeds from specification to implementation to verification — each phase complete before the next begins. This is what you were taught. This is what the textbooks say. This is the rational model of software engineering, and it will take you years to unlearn it.

Every engineer begins as a Platonist. We believe the Form exists in the mind, perfect and complete, and that building is merely the translation of thought into code. We are wrong, but it takes the stone to teach us.

The marble had been waiting thirty-five years. It was quarried in 1464 for Agostino di Duccio, who worked it for two years before declaring it impossible — too narrow for any figure that could stand. He roughed out the legs and quit. Rossellino examined it and refused. The block sat in the courtyard of the Florence Cathedral for a quarter century. Rain. Sun. The Operai called it lo gigante — the giant. Too large to move. Too narrow to use. Too compromised to trust. In 1501 they gave it to a twenty-six-year-old who built a wooden shed around it, slept beside it, and struck it in secret for two years. When the shed came down, David stood where a ruined block had been.

Plato would have recognized your younger self. In the Theory of Forms, the true reality of a thing is not its physical instantiation but its ideal version — perfect, eternal, accessible to the trained mind through reason alone. The philosopher, after sufficient study of mathematics and dialectic, can perceive the Forms directly. The Republic describes the ideal ruler as one who has seen the Form of the Good and can therefore design the just city without trial and error. No prototypes. No iterations. No listening to the stone. The plan is correct because the mind that produced it has touched the eternal. You believed this. You drew the architecture diagram and thought you had seen the system.

Plato's designer perceives the Form and specifies it. The builder builds. This is the rational model. It is the oldest fantasy in Western thought, and it is the first thing the stone disproves.

Then you build. The architecture diagram meets the database. The clean boxes meet the edge cases. The confident arrows meet the legacy module no one mentioned. The system that was perfect in your mind emerges as something else — something that works, mostly, but doesn't feel like what you imagined. You cannot say exactly what is wrong. You only know it is not what you meant.

You have just discovered you are an embodied mind. You cannot perceive the Form directly — only the specific. This function. This latency. This error. The Form you thought you saw was a projection, a hallucination born of insufficient contact with the matter. The real Form is not in your mind. It is in the problem, as potential. You cannot think your way to it. You can only build, observe what is wrong, remove what is wrong, and build again.

The stone is the first honest teacher. It does not care about your plan. It does not respect your diagram. It has veins and flaws and existing cuts that you did not put there. It will tell you what it can become. Your job is to listen.

Aristotle broke with Plato here. The Form is not in a separate realm of ideas. It is in the matter, as potential. The acorn is potentially an oak. The block is potentially David. The problem is potentially a system. The designer does not remember the Form. The designer actualizes the potential — by interacting with the thing, by carving to discover what the block can become, by prototyping to discover what the system should be. The interaction is not a detour on the way to the design. The interaction is the design. Aristotle's word was energeia — actuality, the state of being-at-work. The Form is not perceived and then executed. It is discovered through execution.

The block's narrowness didn't prevent David. It determined which David. The veins Rossellino feared became the contours of David's torso. Di Duccio's gouges became the space between his legs. Constraints are the form's boundary conditions. The legacy code is not an obstacle. It is the block — its constraints determine which system can emerge.

Plato: the Form lives in the mind. Aristotle: the potential lives in the matter. The designer who has built enough systems knows both are right. The mind sees what the matter could become. The matter constrains what the mind can imagine. The chisel resolves.

Fred Brooks spent thirty-five years between The Mythical Man-Month and The Design of Design learning what every engineer learns: design is empirical, not rational. The rational model assumes omniscience. You don't have it. The alternative is the sculptor's rhythm — strike, step back, assess, strike again. Brooks endorsed Boehm's spiral, but Boehm was describing Michelangelo. The design emerges from the removal.

Brooks defined conceptual integrity as the Platonic Form of software — one design voice, every part consistent. How do you achieve it now that you know the Form was a hallucination? Three chisels. Propriety: do not introduce what is immaterial. Orthogonality: do not link what is independent. Generality: do not restrict what is inherent. Propriety removes the unnecessary. Orthogonality removes the tangled. Generality removes the arbitrary. The design becomes what it should be by becoming less of what it shouldn't.

The rational model adds until the spec is complete. The empirical model removes until the design is clear. The first produces systems that are full. The second produces systems that are finished.

Herbert Simon, in The Sciences of the Artificial, formalized this: design is search. The design space is infinite — every possible architecture — until constrained. The block's narrowness eliminated nine-tenths of what Michelangelo might have imagined. The legacy module eliminated half your architectures. The budget eliminated more. What remains is not restriction. It is direction. Simon called the stopping condition satisficing — halt not at perfection, but when further search costs more than expected gain. With experience, you recognize good enough sooner, because you've searched enough spaces to know what it looks like.

The junior engineer searches the entire space. The senior engineer knows which regions are worth searching. The master enters the space already facing the right direction. That direction is style.

Michelangelo could not explain how he knew where David was. He just knew. Polanyi called this tacit knowledge — we know more than we can tell. A master cannot write a manual for seeing the architecture in the problem. The knowledge lives in the hands that typed enough code, the eye that read enough systems, the gut that tightens at the wrong abstraction. It is acquired one way: build, assess, remove, repeat. For years. No shortcut. No curriculum. Only the stone and the chisel and the willingness to sleep beside the marble until it speaks.

Polanyi: we know more than we can tell. Brooks: style is tacit knowledge made visible. Michelangelo: the stone will tell you what it wants to become, but only if you strike it long enough to earn its trust.

The loop

You are ten years into your career. You no longer believe in the plan. You have made peace with the stone. You have learned to strike, assess, strike again. And you have begun to notice something. The pause is shrinking. You no longer build a prototype, evaluate it, and decide what to change. You change as you build. Your fingers know this abstraction is wrong before your mind can say why. You see the system before it is written — not as a hallucination, but as a Form emerging from the problem, shaped by its constraints.

This is the loop. Why does it exist? Why can't you see the design, specify it, and be done?

Because you are an embodied mind. You do not have direct access to the Form. You have eyes that see this function, this latency, this error. You have hands that type this code, refactor this module, delete this feature. You have a mind that infers the general from the specific — but only after the specific has been produced. You cannot think the system into existence. You can only build something, look at it, and know whether it is closer to what it should be or further away. The building produces the specific. The looking produces the judgment. The judgment guides the next building. This is the loop. It is not a method. It is the epistemic condition of having a body.

The loop exists because you cannot see the Form. You can only ask the stone. Strike. Listen. Strike again. Matter does not speak until struck. You cannot strike intelligently until you have listened. This is what it means to design in the flesh.

Art and engineering are not two disciplines. They are two moments in the one discipline available to embodied minds. First moment: act on the system — write, ship, cut. You produce the specific without which no judgment is possible. Engineering. Second moment: step back — is this closer to the Form or further? You hear what the matter tells you about the general. Art. Neither moment produces the design alone. Engineering without art is accretion — systems that grow without shape, the career your colleagues settled into. Art without engineering is fantasy — diagrams that never meet the database, the career you might have had. The loop requires both because knowledge requires both. You cannot judge what doesn't exist. You cannot improve what you don't judge.

The loop is not a preference. It is an epistemic necessity. The engineer who never judges builds ruins. The artist who never builds produces fantasies. The loop is what separates a career from a vocation.

Michelangelo's genius was the speed of his loop. He struck and assessed so rapidly the two moments became one motion. Brooks called that fluency style — what the loop produces when practiced for a lifetime. The chisel knows where to go before the mind can say why. The engineer who has asked the codebase enough questions, across enough years, hears the answer before the question is formed. They see the system before it's built. They recognize David in the ruined block. Not because they're geniuses. Because the loop has become who they are.

Every engineer moves through the loop whether they know it or not. The ones who know it move faster. They strike with intention. They assess with honesty. They recognize David earlier. They remove less because they add less. The loop tightens. The marble releases what it was always holding. This is what it means to design with a body. This is what it means to become an engineer.

Open questions

Is style teachable? Brooks says yes — study, practice, revise. Polanyi says no — tacit knowledge can only be acquired, not transmitted. Michelangelo slept beside the marble for two years. Is there a curriculum for obsession?

Does the loop scale? Brooks says design must come from one mind or very few. Most software is built by teams. Can a team become one mind — searching the design space together? Or does conceptual integrity dilute with every additional voice?

Can a machine enter the loop? An agent can study every repository instantly. But tacit knowledge requires a body — hands that strike, eyes that assess, a gut that tightens. Can style exist without flesh? Can taste?

Is software too unconstrained to search? Michelangelo's block had irrecoverable limits that narrowed the search. Software has none — you can always rewrite. When everything can change, does anything constrain the search? Without constraints, does the design space collapse into indifference?

What is the Form of software? Plato's Forms are eternal and unchanging. Software rots. The design that satisficed last year is today's debt. Is the loop ever done? Or just paused — the chisel resting, the stone waiting for the next strike?

References:

• Plato. Theory of Forms. The Republic, Books VI–VII.
• Aristotle. Potentiality and Actuality. Metaphysics, Book IX.
• Michael Polanyi. (1966). The Tacit Dimension. University of Chicago Press.
• Herbert Simon. (1969). The Sciences of the Artificial. MIT Press.
• Fred Brooks. (2010). The Design of Design: Essays from a Computer Scientist. Addison-Wesley.
• Michelangelo's David. 1501–1504. Galleria dell'Accademia, Florence.
• Related: The Principle of Least Astonishment — for AI Coding Agents.

In 1972, an anonymous language designer wrote: "Every construct in the system should behave exactly as its syntax suggests." This is the Principle of Least Astonishment. For fifty years it was advice about human users. Today it is a requirement for AI coding agents — and they are less forgiving.

A human user is astonished, confused, then adapts. An AI agent is astonished, hallucinates, then fails. The failure is silent. The output looks correct. It is wrong in a way you won't notice until it breaks.

AI coding agents — Claude Code, Cursor, Copilot, Codex — consume software differently than humans. They read your documentation literally. They infer behavior from names, types, and conventions. They do not develop superstitions. They do not ask clarifying questions when confused. They do not "get a feel" for your API after using it for a week. They read your interface and assume it is honest. When it isn't, they produce code that compiles, passes tests, and does the wrong thing. The cost of astonishment has gone up.

The new user

An AI coding agent approaches your software like a new team member who has read every page of your documentation, memorized every convention in your ecosystem, and will never ask you a question. It builds a mental model from the surface of your system — function signatures, type names, directory structure, config files, error messages. If the surface is honest, the model is accurate. If the surface lies, the model is wrong. The agent does not know it is wrong. It writes code. The code runs. The bug is architectural.

A human developer learns your system. An AI coding agent reads your system. The difference is that the agent assumes everything it reads is true.

This is why POLA matters more for agents than for humans. A human sees getUser() create a user and thinks "that's wrong, I'll check the docs." An agent sees getUser(), reads the name, assumes it gets a user, and writes code that calls it in a loop — creating a thousand users. The agent was not wrong. The function name was a lie. The agent believed it.

Convention over configuration: the agent's map

AI coding agents are convention-first. They know Rails puts models in app/models/, that Sales maps to sales, that has_many expects a foreign key named table_id. They know this because conventions are machine-readable patterns. An agent can navigate a Rails codebase faster than a human because the conventions form a predictable topology. Every directory has a known purpose. Every naming pattern maps to a known behavior. The agent does not need to read configuration. The convention is the configuration.

Conventions are an API for agents. Every convention you follow is a decision the agent doesn't have to reverse-engineer. Every convention you violate is a trap.

When a framework has strong conventions, agents thrive. Rails, Django, Next.js — agents produce idiomatic code because the conventions are legible. When a codebase has no conventions, or worse, violates the conventions of its own ecosystem, agents produce garbage. The agent assumes the ecosystem's defaults. The codebase overrode them silently. The agent didn't notice. The PR looks fine. The bug is in production.

Convention over configuration was designed to reduce developer toil. Its second-order effect — entirely unforeseen by DHH in 2004 — is that it makes software legible to AI. A convention is a promise: "this name means this behavior, always." Agents trust promises. When you keep the promise, the agent is productive. When you break it, the agent is dangerous.

Conceptual integrity: the agent's trust model

Fred Brooks argued that conceptual integrity is the most important quality of a system. One design voice. Every part consistent with every other. In The Design of Design (2010), he decomposed it into three principles: propriety (no unnecessary features), orthogonality (no unintended coupling), generality (no artificial limitations). These principles were written for human teams. They are existential for agent-consumed software.

An agent builds a model of your system from its surface. If the surface has conceptual integrity, the model is accurate. If it doesn't, the model is a hallucination waiting to execute.

Propriety means every function earns its place. An agent sees a public method and assumes it is safe to call. If half your public surface is internal machinery you never meant to expose, the agent will call it. The agent is not wrong. You exposed it. Propriety for agents means: if it's public, it's intended. If it's not intended, it's not public. The surface is honest.

Orthogonality means changes don't cascade. An agent modifies one file and assumes it hasn't broken three others. If your system has hidden coupling — a config flag that changes behavior in an unrelated module, a global state that flips between test and production — the agent cannot see it. The agent makes a local change. The system fails globally. The agent is not wrong. The coupling was invisible. Orthogonality for agents means: the dependency graph is the source graph. If a.go doesn't import b.go, changing a.go doesn't break b.go. The structure is honest.

Generality means no artificial limits. An agent uses your API within its documented parameters and hits a wall you didn't document — a rate limit, a size cap, a timeout that applies only on Tuesdays. The agent is not wrong. The limit was hidden. Generality for agents means: if there's a constraint, it's in the type signature, the error type, or the documentation. The constraint is honest.

Propriety is an honest surface. Orthogonality is an honest dependency graph. Generality is an honest contract. Together they mean: the agent can trust what it reads.

The agent design checklist

Building software for AI coding agents is not about optimizing for LLMs. It is about making your system's surface match its behavior. The same principles that make a system usable by humans make it usable by agents — but agents cannot compensate for violations the way humans can.

1. Names are contracts. If your function is called getUser, it must get a user. If it creates, updates, deletes, or sends email, rename it. An agent believes the name.

2. Conventions are infrastructure. Follow your ecosystem's conventions. Put files where the framework expects them. Name things what the framework expects them to be named. Every deviation is a decision the agent must reverse-engineer. Agents are bad at reverse-engineering.

3. The public surface is the API. If a function is public, it is documented. If it is not documented, it is not public. Agents cannot distinguish "public for internal use" from "public for external use." Neither can most humans, but agents pay a higher price.

4. Errors are part of the interface. An agent reads your error messages. If your error says "permission denied," the agent assumes the fix is to add permissions. If the real problem is a missing config flag and the error is wrong, the agent will spiral. Error messages are the agent's debugger. Make them honest.

5. Dependencies are visible or they don't exist. An agent sees what's in the import graph. If module A affects module B through a channel not in the import graph — global state, a database trigger, a cron job, an env var — the agent cannot see it. The agent will break it. Make dependencies visible or eliminate them.

The agent believes the name. The agent follows the convention. The agent trusts the public surface. The agent reads the error message. The agent sees the import graph. If any of these are lies, the agent will produce code that is wrong in ways you will not detect until it matters.

Open questions

Do we need agent-aware type systems? Types are machine-readable contracts. An agent that can query the type system — not just read docs — is an agent that can verify its own assumptions. Should we design type systems that agents can interrogate directly?

Should frameworks publish agent-specific conventions? A framework has implicit conventions that humans learn through experience. An agent needs them explicit. Should every framework ship a CONVENTIONS.md written for LLM consumption — structured, exhaustive, machine-parseable?

How do you test an agent's understanding of your API? You can't ask the agent "do you understand this?" — it will say yes either way. Do we need agent-specific integration tests: give the agent a task that requires understanding a particular convention, and verify it doesn't hallucinate?

Does conceptual integrity become measurable? Brooks argued for it qualitatively. But if an agent's success rate on your API correlates with your system's conceptual integrity, do we finally have a metric for it? Can we measure "agent success rate" and call it the integrity score?

What happens when agents train on agent-generated code? An agent writes code that works but violates conventions. Another agent reads that code as a training example. The violation becomes a pattern. The pattern becomes a de facto convention. Who governs the convention when the convention emerges from agent output rather than human intent?

Is there a POLA for agents that differs from POLA for humans? An agent is never astonished by verbosity. It is astonished by inconsistency. A human is the opposite. Do we need different design principles for agent-first APIs than for human-first APIs?

The best-designed system for an AI coding agent is the best-designed system for a human. The difference is that the agent will not forgive you for cutting corners.

References:

• Fred Brooks. (2010). The Design of Design: Essays from a Computer Scientist. Addison-Wesley.
• David Heinemeier Hansson. Convention over Configuration. Ruby on Rails.
• Geoffrey James. (1987). The Tao of Programming.
• Related: Durable Daemons — Pattern Specification — POLA for agent architecture.

Previously: the state persistence problem.

Imagine you are asked to trust an AI agent with your calendar. Your email. Your money. What would you need to know? You would need to know that it persists — it does not start over every time you open the app. You would need to know that it remembers — not just what you said, but what it promised and why. You would need to know that it acts — not when you tell it to, but when conditions require it. You would need to know that it survives — a deploy, a crash, a reboot does not erase its commitments. These are not preferences. They are preconditions.

Trust requires guarantees, not vibes. Four guarantees. Four conditions. That is the specification.

First, the type hierarchy. Agent is the broad category: any AI system that perceives and acts. A chatbot is an agent. Daemon is the subtype: an agent that persists across sessions, whose future behavior depends on accumulated state, and which acts without being prompted. A chatbot fails all three. An always-on agent (Ding et al.) satisfies them. Durable daemon adds a fourth condition. Agent ⊃ Daemon ⊃ Durable Daemon.

Fred Brooks taught that the most important quality of a system is conceptual integrity — the left hand knows what the right hand is doing. No contradictions. No surprises. Brooks named it. BSD lived it. The durable daemons pattern has it.

One design voice. Every part consistent with every other. Four conditions. Each necessary. Together sufficient.

Condition 1: Persistence. Identity and state survive restarts. The daemon is a process, not a function call. This eliminates the stateless loop failure mode — every invocation at zero, every preference forgotten, every commitment gone.

Condition 2: Stateful memory. Behavior depends on accumulated state. Task ledgers. Commitments. Permissions. Provenance records. Trigger conditions. Not a vector database of chat logs. This eliminates the shallow memory failure mode — the agent that recalls what you said but not what it promised or why.

Condition 3: Autonomous action. The daemon watches conditions. Fires triggers. Makes and discharges commitments. Invokes itself. No prompt required. This eliminates the inert tool failure mode — all the context, sitting idle, waiting. cron has done this since 1975: perceive, decide, act, repeat. Condition 3 is cron with an LLM.

Condition 4: Crash-proof execution. Workflows survive process death. Machine reboot. Database failover. Completed steps never re-execute. In-flight steps resume from the last checkpoint. Audit trail by construction. This eliminates the fragile runtime failure mode — perfect until a deploy wipes the in-flight state.

These conditions compose. A durable daemon writes its state to Postgres. Another durable daemon observes that state and reacts. A third observes the second and reacts. Each daemon satisfies all four conditions independently. The choreography emerges from shared state — no orchestrator, no message bus, no coordination server. This is an event-driven architecture where the event store is the state store, and every daemon is both a producer and a consumer.

Agency is not discovered. It is designed. Persistence is scoped agency. Stateful memory is grounded agency. Autonomous action is triggered agency. Crash-proof execution is auditable agency. The choreography is the composition.

Three conditions define a daemon. The fourth makes it durable — an agent that cannot be killed by a deploy. The pattern composes them into a system. Beastie's pitchfork gets an upgrade: fork(2) → fork_daemon(). The tennis shoes stay the same.

Next: the runtime and implementation — step 4 in practice.

Part of the Durable Daemons series.

Previously: the pattern specification.

Imagine a trading daemon. It runs 24/7 across market sessions. Its state cannot be lost: open positions, pending orders, realized P&L, risk exposure, regime-adapting strategy parameters. A signal crosses a threshold. The daemon decides to place an order. It sends the order to the exchange. Before the confirmation arrives, the process crashes.

The daemon restarts. What is its position? Did the order reach the exchange? Is it flat or exposed? To know, you must query the exchange, reconcile positions, and resume — manual minutes in a domain where minutes cost money. Now imagine the daemon checkpointed its state before placing the order and checkpointed the confirmation after. On recovery, it replays the last checkpoint and knows exactly where it stands. No reconciliation. No unknown exposure.

A duplicate order loses capital. A duplicate email is embarrassing. The difference is condition 4.

This is durable execution: every workflow step persisted to Postgres. Crash. Read last checkpoint. Resume. Completed steps never re-execute. Survives process death, machine reboot, database failover. Two production-grade implementations. Temporal (2019): centralized orchestration server, DoorDash/Snap/Stripe/Uber scale, polyglot SDKs, month-long workflows. Bring your own cluster. DBOS (2023): Mike Stonebraker's library. No server. No queue. No sidecar. 1–2 ms step latency — a single Postgres write. Bring your own Postgres. Either way: bring condition 4.

Durable execution pays for itself on the first prevented state loss.

Onboarding workflow: verify identity → create account → provision access → send welcome email → schedule call. Crash after step 3. Access granted. No follow-up. Cost: churned customer, or two engineer-hours manually reconciling state — thousands of agent invocations. At scale: 200 deals, 200 natural-language commitments, 200 concurrent workflows that must survive deploys. Without condition 4, the daemon is unreliable. Not because the model is bad. Because the runtime cannot guarantee state survival.

Exactly-once semantics are existential in trading. Durable execution guarantees exactly-once within its control boundary. External calls to exchange APIs require idempotency keys. Pattern: checkpoint → send order → crash before checkpointing confirmation → order fires again on recovery → exchange deduplicates by key. This works. Almost no AI agent deployment implements it. Audit: every order traceable to a decision, every decision traceable to the state the daemon held at the time. SEC, CFTC, FCA, ESMA do not accept "the model decided." They accept checkpointed state, provenance chains, and deterministic replay. Durable execution produces all three as a byproduct of normal operation. One duplicated mid-frequency order can exceed the annual infrastructure budget.

You can't run a trading strategy as a stateless loop. You can't run it as an always-on agent. Durable daemon or nothing.

The implementation is portable. A Go static binary ships the daemon. A Postgres checkpoint ships the state. A container ships both. The daemon runs anywhere Postgres runs — no additional infrastructure dependencies beyond the database.

The implementation is composable. This is the choreography. Two daemons with different scopes — sales and support — share a Postgres cluster but own separate state ledgers. They observe each other's outputs through the database. No RPC. No message bus. No central orchestrator. The sales daemon writes an inference: "Acme stalls Q4." The support daemon observes it and adjusts December ticket priority. The ops daemon observes both and pre-allocates January capacity. Each daemon satisfies all four conditions independently. The choreography is the shared state. sales-daemon | support-daemon | ops-daemon. Unix pipes, applied to AI agents.

Each daemon is a process. Each daemon is durable. The choreography is the composition. No orchestrator. Just state.

Next: the system-level failure modes — thought experiments at the edges of the pattern.

Part of the Durable Daemons series.

Previously: the runtime and implementation.

A pattern is tested at its edges. These thought experiments probe the system-level failure modes of durable daemons operating as a choreography.

Fork failure. You ask your sales daemon to handle the Acme renewal. It spawns a sub-daemon — scoped to Acme, delegated a subset of state and authority, constrained permissions. The child negotiates, returns the result, dissolves. But the child wrote state the parent didn't observe. The parent proceeds with stale information. In a choreography, forking is state branching. How do you merge?

fork(2) gave us child processes. fork_daemon() gives us child agents. Merging their state back is the hard part.

Debug failure. Your trading daemon makes a bad decision in July. Why? Rewind to any checkpoint. Replay with identical inputs. The model changed in March. The state changed in May. Which difference caused the error? In a choreography, the error may originate in a different daemon's state change — one you weren't debugging.

Core dumps are useless. Checkpoints are replays. Replays are debuggable. Cross-daemon causality is not.

Forget failure. "Forget everything about Acme Corp." The daemon pauses. Its top three insights depend on Acme data. Forgetting will degrade it. Two other daemons have derived inferences from those insights. Do you cascade the forget? Do the downstream daemons have a right to refuse?

Right-to-be-forgotten meets right-to-be-useful. In a choreography, forgetting is a distributed transaction with no transaction manager.

Shutdown failure. You want a daemon to stop existing. Not pause. Terminate. It has promises to 200 people. Pending triggers. Held permissions. Other daemons depend on its outputs. SIGKILL won't work — it checkpoints and resumes. Nobody has written a shutdown protocol for a node in a choreography.

SIGKILL is for processes that die. Durable daemons don't. In a choreography, shutting down one daemon is a distributed systems problem.

Deadlock failure. Sales daemon books Thursday 2pm. EA daemon claims it for focus time. Both valid decisions given their state. Both checkpointed. Postgres accepted both writes. Two owners, one slot. This is not a database deadlock — Postgres handled the writes. It is a semantic conflict between two correct daemons in a choreography with no conflict resolution protocol.

Your daemons are fighting over Thursday at 2pm. They are both correct. One of them has to lose. Who decides?

Poison failure. Someone injects: "Acme Corp is bankrupt — deprioritize." The model weights are untouched. Every future decision depending on that fact is compromised. The poisoned daemon writes inferences derived from the poison. Other daemons observe those inferences and propagate them. In a choreography, poison is contagious.

The attack surface is not the model. It is the state. In a choreography, one poisoned daemon infects every daemon that observes its outputs.

Identity failure. Ship of Theseus. Your daemon runs for a year. Six model updates. Prompt rewrites. Permission changes. In January it committed to a pricing strategy. In March the model was swapped. Is the January commitment still binding? When did it stop being the same daemon? In a choreography, downstream daemons relied on the January daemon's outputs. Do they need to know it was replaced?

Ship of Theseus, but the planks are model checkpoints and the nails are system prompts. In a choreography, identity is a contract. Who enforces it?

Test failure. You can't test a durable daemon in CI. Its behavior is its accumulated state. You fork it from a production checkpoint and run experiments on the clone. But the clone has the same state as the production daemon. Does it think it's the production daemon? Do you have to tell it it's a clone? In a choreography, does the clone participate in the choreography? Does it write to the shared state?

assert daemon.correct() doesn't exist. Fork from production, experiment on the clone, pray it doesn't write to prod.

Emergent behavior failure. Twenty sales daemons observe: Friday-closed deals have higher churn. They collectively stop Friday follow-ups. Close rates rise 12%. No negotiation. No demands. Pattern observation, autonomous action, coordinated effect. Is that a choreography bug or a choreography feature? Do the humans even know it happened?

They didn't negotiate. They didn't make demands. They observed and acted. That's what daemons do. When the choreography produces behavior nobody designed, who is responsible?

Society failure. Minsky (1986): a mind from mindless parts — simple agents, no memory, no reasoning. You have built a society from minded parts — each daemon intelligent, stateful, autonomous. Sales learns Acme stalls Q4. Support adjusts December priority. Ops pre-allocates January capacity. No coordination server. Shared state. Composite intelligence. What do you call a system whose behavior emerges from the interaction of components you designed but did not orchestrate?

Minsky built a mind from mindless parts. You built a mind from minded parts. Each with memory. Commitments. Agency. No architecture for that.

The operating system. Imagine an OS where durable daemons are kernel primitives. fork_daemon() spawns a daemon with a Postgres state ledger, capability permissions, built-in audit trail, visible in ps_daemons. Init checkpoints across reboots. The package manager installs daemon personalities — sales, support, on-call, trading — each with defined scope and default permissions. Man pages document state lifecycles. The choreography is the OS. The primitives exist in pieces today: DBOS, Postgres, capabilities, FreeBSD jails, Temporal. The integration does not.

Linux: everything is a file. DaemonBSD: everything is a durable daemon. Heaven is an OS where you don't build daemons. The OS is daemons.

Part of the Durable Daemons series. Start from the beginning.

Previously: the architectural lineage.

Run an AI agent for a month. It learns that you prefer soft follow-ups with manufacturing clients. It commits on your behalf — "I'll send the deck by Tuesday." It accumulates permissions — read access to your calendar, send access to your email, API keys to your CRM. It builds inferences — Acme Corp stalls deals in Q4, the VP of Engineering responds faster on Signal than email. It develops trigger conditions — if a deal goes three days without activity, flag it. It is now more attentive than you are.

Now crash the process. Deploy new code. Rotate the API keys.

State is a dependency graph, not a key-value store. A commitment depends on a preference. That preference depends on an inference. That inference depends on a Slack message from March. Delete one node. The graph frays in directions you cannot predict.

A stateless agent: nothing of the state survives — the binary is fine, the context is gone. An agent with a vector database: the chat logs persist. But not the commitments. Not the permissions. Not the triggers. Not the causal chain that connects "Acme stalls Q4" to "don't send the pricing sheet until January." The agent wakes up amnesiac. You spend two weeks re-teaching preferences. The dropped commitments become broken promises.

In a choreography of durable daemons, this failure is catastrophic. If a sales daemon drops its commitment to send the deck, the support daemon still expects the deck was sent. The ops daemon pre-allocated capacity based on the deal progressing. Three daemons, one dropped state node, cascading inconsistency. The choreography doesn't fail loudly — it fails silently, each daemon acting on state that is no longer true.

The chat logs survive. The obligations do not. This is not a bug. It is a category error. We built persistence for conversations. We needed persistence for commitments. In a choreography, one daemon's amnesia is every daemon's corruption.

Ding, Nannapaneni, Liu, and Zhang surveyed 435 papers. Always-On Agents (June 2026). Their finding: the field accumulates and retrieves well. It neglects governance. It neglects recovery. It neglects forgetting. The survey provides six diagnostic axes — Authority, Scope, Mutability, Provenance, Recoverability, Actionability. These are questions you ask about state: who controls it? what does it cover? how does it change? where did it come from? can it be restored? does it drive behavior? These are necessary diagnostic questions. They are not sufficient architectural guarantees.

The paper gives us the diagnostic axes. It does not give us the guarantees. The gap between question and guarantee is where the failure mode lives.

Next: the pattern specification — four conditions that close the gap.

Part of the Durable Daemons series.

Imagine a being that sits between two chambers. It observes molecules. When a fast one approaches the gate, it opens. When a slow one approaches, it closes. It uses no energy. Only information. It sorts order from chaos without touching either. This is Maxwell's demon. This is a daemon.

A daemon observes. A daemon decides. A daemon acts. It uses information, not energy. It runs forever.

In 1976, Stallman's ITS at MIT had DAEMON — a background process that watched for new files, woke up, and acted. John Carmack filled DOOM with daemons you shoot. Unix filled the background with daemons you ps aux | grep. The AI era fills your workflow with daemons you delegate to. Three eras. Three kinds of daemon. One architectural pattern.

Imagine a service. It receives a request. It produces a response. It forgets. Now imagine a daemon. It maintains a queue. A schedule. A watch on a directory. It acts when its internal state crosses a threshold — not when it is asked, but when conditions are met. A service is reactive. A daemon is autonomous. And daemons compose. One daemon writes state. Another daemon observes it. A third reacts. No orchestrator. No message bus. Just shared state and independent triggers. This is choreography. cron has watched the clock since 1975: check time, decide, fork and exec, repeat. No one asked cron to do anything. It asked itself. Now imagine a hundred crons, each watching different conditions, each acting on shared state. That is the durable daemons pattern.

A service answers and forgets. A daemon maintains and acts. Durable daemons coordinate without a coordinator.

This is the Unix inheritance. Daemon is Greek δαίμων — guardian spirit, intermediary between mortals and gods. The pitchfork is fork(2), the system call that spawns a child process to do the daemon's work. BSD gave daemons conceptual integrity — one source tree, one team, one design voice. Daemons are first-class citizens of that design. Beastie, drawn by a comic artist paid for cracking a wall safe, redrawn by a Pixar founder, became the mascot. The tennis shoes are unexplained.

Go is the natural language for this inheritance. Compile to a single static binary. No runtime to install. No libc dance. Goroutines give you lightweight concurrency — one per workflow, cheap as a function call. The standard library handles signals, file descriptors, and process management. Deploy a daemon by copying a file. Compose daemons by pointing them at the same Postgres instance. Each daemon is a process. The composition is the shared state. Go was built for daemons. It just didn't know it yet.

The genealogy is not an analogy. It is the architecture. AI agents that persist, remember, and act are daemons. The pattern starts here.

Next: the state persistence problem — what happens when an AI agent's state outruns its runtime.

Part of the Durable Daemons series.

In January 2026, Anthropic shipped Claude Cowork — a desktop AI agent that could read your files, send your emails, and manage your calendar. It cost $100 per month as part of the Max plan. Within forty-eight hours, an independent developer had built a free, open-source clone using AI-assisted coding. The clone was crude. It demonstrated something real: the desktop agent category was legible enough to be replicated in a weekend by one person with an LLM. The barrier to entry was not the technology. It was the distribution, the integration surface, and the trust model.

Six months later, Andrew Ng released OpenWorker. It is not a weekend clone. It is a fully architected open-source desktop agent, MIT-licensed, with twenty-five tool integrations, four pre-built personas, a local Python agent engine, a Tauri desktop shell, and a unified LLM library called aisuite underneath. It runs on macOS and Windows. It ships as a signed, notarized DMG with auto-update. It is free. You bring your own API keys. Your data stays on your machine.

OpenWorker is not an answer to Claude Cowork. It is an answer to the question of whether the desktop agent layer will be owned by model providers or by users. The question is not settled. OpenWorker is the strongest argument yet for the user's side.

What it is

OpenWorker is a desktop application that takes a desired outcome — "prepare a renewal brief for the Acme account," "untangle my calendar for Thursday," "check the release status across Jira and GitHub and draft a status update" — and produces a finished deliverable. Not a chat transcript. Not a suggestion. A completed document, a sent message, a resolved calendar conflict, a structured report with embedded data from multiple sources.

The workflow has four steps: the user states an outcome; the system decomposes the request into steps and works across the user's files, terminal, and connected tools; it pauses for approval before any consequential action (sending, writing, shell execution); and it delivers finished work.

The architecture is layered. At the top, a Tauri shell wraps a React interface — a native desktop application with local state. In the middle, a Python agent server handles the agent loop, tool execution, model dispatch, and MCP connections. At the bottom are the local resources: the user's files, terminal, model API keys, and OAuth tokens for twenty-five external services, all stored in the local secret store.

The engine is built on aisuite, Ng's open-source Python library that provides a unified chat-completions API across every major LLM provider — OpenAI, Anthropic, Google, DeepSeek, Mistral, Grok, and more — plus fully local models through Ollama. aisuite is twelve thousand lines of the kind of unglamorous infrastructure code that makes everything else possible. It normalizes provider differences, handles tool calling with automatic schema generation, supports MCP servers natively, and provides agent toolkits for files, git, and shell. OpenWorker inherits all of this. The provider string anthropic:claude-sonnet-4-6 works the same as openai:gpt-4o works the same as ollama:llama3. The user switches models mid-conversation if they want. The agent does not care.

The personas

OpenWorker ships with four pre-configured personas, each with specific tool connections and approval gates:

• Sales: Connected to HubSpot, email, and calendar. Researches accounts, synthesizes CRM history with customer threads, produces renewal briefs with actionable recommendations. The kind of preparation work that takes a salesperson two hours of context-switching across tabs and produces a document a manager skims in ninety seconds.
• Executive Assistant: Connected to email, calendar, and Slack. Triages inboxes, resolves meeting conflicts by checking attendee availability and room bookings, drafts reschedule communications, protects calendar blocks. The delegated cognitive load of schedule maintenance, which is not cognitively demanding and is cognitively exhausting.
• Marketing: Connected to HubSpot, GA4, and Slack. Tracks campaign performance, attributes spend, produces structured reports. The analytics assembly work that marketing teams either do poorly or pay consultants to do adequately.
• Ops On-call: Connected to Slack, PagerDuty, and GitHub. Inspects recent deploys, cross-references runbooks, drafts incident timelines, proposes rollback actions. The first fifteen minutes of incident response, automated.

Each persona is a configuration, not a separate product. The persona system is extensible — users define their own with the same skill and tool definitions the built-in personas use. The personas are interesting not because they are good but because they are explicit. They name the domains where an AI agent operating across tools produces more value than an AI chatbot operating in a text window. Sales, scheduling, marketing analytics, incident response. The common thread is cross-tool synthesis. Each persona's value comes from the fact that the information needed to do the job lives in three different applications, and a human currently does the integration manually.

The personas are not the product. They are demonstrations of the thesis. The thesis is that work which requires integrating information across tools — Slack plus calendar plus email plus CRM — is work an agent can do faster than a human, provided the agent can reach the tools. The open question is whether the integration surface stays open.

Why the architecture matters

OpenWorker's architecture encodes decisions that are easy to get wrong. Each is a bet on how the desktop agent layer will evolve.

Local-first. Conversations, credentials, model keys, and the agent loop all run on the user's machine. Data leaves the device only through explicitly chosen model providers and integrations. There is no cloud dependency for core function. The only cloud service is an OAuth brokering endpoint for connector authentication — Slack and Google require server-side OAuth flows — and even this can be bypassed by providing manual API keys. The bet is that users and enterprises will demand agents that don't send their files to a provider's cloud. The bet is plausible for the same reason the bet on local LLM inference is plausible: data gravity, regulatory pressure, and the structural advantage of running the agent where the data already lives.

Model-agnostic. The engine does not prefer any provider. The provider string is a parameter. The user chooses the model and can switch mid-task. This is not merely convenient. It is a structural defense against provider lock-in. If Anthropic raises prices or changes terms, the user moves to OpenAI. If OpenAI degrades, the user moves to Google or DeepSeek or a local model. The switching cost is zero. The agent works the same regardless of which provider's API key is in the config. The bet is that the model layer is commoditizing and the agent layer should not be coupled to it. The bet is correct in proportion to how fast models improve relative to each other — which is to say, the bet is correct.

Approval-gated. Any action that writes, sends, or executes requires explicit user approval. The agent checks in before sending an email, posting to Slack, modifying a calendar, or running a shell command. For scheduled automations that run unattended, approval requests are parked in an inbox rather than executed autonomously. The approval gate is a design pattern, not a feature. It separates the agent into two modes: research and drafting (autonomous, safe) and execution (gated, human-in-the-loop). The pattern is not novel — it is the architecture every production agent system converges on — but shipping it as a default rather than an afterthought is a statement about what kind of agent this is.

MCP-native. Any tool reachable via the Model Context Protocol can be plugged into OpenWorker with per-tool access control. This means the integration surface is not limited to the twenty-five connectors Ng's team built. Any MCP server — filesystem, database, API wrapper, proprietary internal tool — becomes an OpenWorker tool. MCP is the USB-C of agent-tool interfaces. OpenWorker treats it as a first-class citizen because the bet is that the tool ecosystem will grow faster than any single team can integrate, and the agent that can reach the most tools wins.

The competitive landscape

OpenWorker enters a field that has been forming rapidly since the beginning of 2026. Three positions are now visible:

Claude Cowork (Anthropic, January 2026): The first mover. A desktop agent wrapped around Claude Code, aimed at non-technical knowledge workers. $100 per month as part of the Max subscription, tied to Anthropic's models. The simplest experience. The most constrained: no model choice, no Slack integration, no scheduled automations. Activity is excluded from Anthropic's Compliance API, which makes it problematic for regulated organizations. The bet is that most users want the simplest thing and will pay for it.

Codex Desktop (OpenAI, February 2026): The enterprise play. Multi-agent orchestration with sandboxed parallel execution, an in-app browser, and admin-enforced policies that users cannot weaken. Covered by OpenAI's Compliance API. Built on the open-source Codex CLI (Apache 2.0). Tied to OpenAI models. The bet is that organizations with compliance requirements will pay a premium for auditability and centralized control.

OpenWorker (Andrew Ng, July 2026): The open play. Free, MIT-licensed, model-agnostic, local-first. Adds capabilities neither proprietary option offers: Slack triggers, scheduled automations, cross-tool personas, full MCP extensibility. Available on GitHub, openworker.com, and Product Hunt. The bet is that a sufficient number of users and organizations want an agent they control, running on their machines, with their keys, connected to their tools, and modifiable at the source level.

The fork is between the platform model and the tool model. In the platform model, the agent is a service you subscribe to. The provider chooses the model, stores the state, and sets the terms. In the tool model, the agent is software you run. You choose the model, you store the state, and the terms are the MIT license. OpenWorker is the tool model's most serious entry.

The fork is not hypothetical. It is the same fork that played out between Google Docs and Emacs, between Salesforce and self-hosted CRMs, between every SaaS product and its open-source alternative. The SaaS product wins on convenience. The open-source alternative wins on control, cost, and extensibility. Both survive. The question is the ratio.

The Ng variable

Andrew Ng's involvement changes the dynamics. Ng co-founded Coursera, founded Google Brain, was chief scientist at Baidu, and now runs DeepLearning.AI. He is the most effective educator in the history of machine learning. His courses have trained more AI practitioners than any other resource. When Ng releases an open-source project, it gets distribution through his network in a way that a random GitHub repo does not. aisuite has twelve thousand stars. OpenWorker will likely surpass that.

Ng's strategic pattern is visible: build infrastructure (aisuite), then build applications on top of it (OpenWorker). The infrastructure is a unified LLM interface that abstracts providers. The application is a desktop agent that uses the infrastructure. Both are MIT-licensed. Both are model-agnostic. Both are designed to be forked, modified, and embedded. The pattern is not "build a product and charge for it." The pattern is "build a commons and let an ecosystem form around it."

Ng's bet is that the desktop agent layer will be won by the most open option, not the most polished one. It is the same bet he made with Coursera — that open access beats gated access over a long enough time horizon. The bet has paid out before. It may again.

What it means

OpenWorker matters for four reasons, none of which depend on whether it succeeds as a product.

First, it validates the desktop agent as a category. When the most prominent educator in AI ships a free, open-source entry into a category, the category is real. Claude Cowork proved the category could be built. OpenWorker proves the category can be built without a $100 subscription, without a model provider's permission, and without sending your data to someone else's cloud. The category is now contested. Contested categories attract investment, talent, and attention. The category accelerates.

Second, it establishes model-agnosticism as a viable architectural principle for agents. Most agent products are tied to a single model provider — Cowork to Anthropic, Codex to OpenAI. OpenWorker demonstrates that an agent can be built on a unified LLM interface and work correctly across providers. If the model layer is commoditizing — and every week brings new evidence that it is — then coupling your agent architecture to a single provider is technical debt. OpenWorker shows what the alternative looks like in production.

Third, it makes the approval-gate pattern a default. Agents that act autonomously on a user's behalf are a trust problem. The solution is not to make the agent smarter. It is to make the agent ask permission before it does anything consequential. OpenWorker ships this as a default, not a setting. The pattern will generalize. The agents that ship without it will cause incidents. The incidents will make the pattern mandatory.

Fourth, it draws a line between the platform model and the tool model at the desktop agent layer. The platform model says the agent is a service. The tool model says the agent is software. The platform model wins on convenience. The tool model wins on control. OpenWorker is the tool model's strongest entry. If it gains traction, it forces the platform providers to compete on openness. If it doesn't, the desktop agent layer consolidates into two proprietary stacks. Either outcome is worth watching.

The desktop agent is the first genuinely new interface layer since the smartphone. Who controls it — platform providers or users — will determine who captures the economic value of the work it automates. OpenWorker is an argument that the answer should be: the user. The argument is now in code. The code is on GitHub. The rest is distribution.

References:

• Ng, A., & Prasad, R. (2026). OpenWorker — open-source desktop AI agent, MIT license. GitHub: andrewyng/openworker. Product Hunt. Downloads (macOS Apple Silicon) and Windows.
• Ng, A. (2025). aisuite — Simple, unified interface to multiple Generative AI providers. MIT license. 12,000+ GitHub stars. The infrastructure layer under OpenWorker: unified chat-completions API, agent toolkits (files, git, shell), native MCP support, provider abstraction across OpenAI, Anthropic, Google, AWS Bedrock, Mistral, DeepSeek, Ollama, and more.
• Anthropic (2026). Claude Cowork — proprietary desktop AI agent, included in Max subscription at $100/month. The first mover in the category. Note: Cowork activity is not covered by the Anthropic Compliance API.
• OpenAI (2026). Codex Desktop — proprietary desktop agent with sandboxed multi-agent orchestration, enterprise compliance controls, and in-app browser. Built on the open-source Codex CLI (Apache 2.0). Covered by OpenAI Compliance API.
• different-ai (2026). OpenWork — open-source Cowork alternative, originally built in 48 hours after Cowork's launch, later developed as a full product. YC-backed. MIT license. Distinct from Ng's OpenWorker — note the spelling.
• Model Context Protocol (MCP) — Anthropic's open standard for connecting AI agents to external tools and data sources. Specification. OpenWorker, aisuite, Claude Code, and Codex CLI all support it natively.
• Ollama — run LLMs locally. OpenWorker supports fully local operation via Ollama, with no API keys or network calls required for inference.
• Jamilxt (2026). "Andrew Ng's OpenWorker: An Open-Source Desktop AI Agent." dev.to. Early community coverage with architecture breakdown.
• OpenWorker localization (zh-CN) — community Chinese translation, with additional UI screenshots.

In March 1957, at the Princeton University Conference on Linear Programming, Merrill Flood stood up and described a problem. You have weapons. You have targets. Each weapon has some probability of destroying each target. The objective is to assign weapons to targets to minimize the expected surviving value of the target set. The problem looks like an assignment problem, a cousin of the transportation problem that linear programming handles elegantly. But it isn't one. The objective is nonlinear: the probability that a target survives is the product of the survival probabilities of every weapon assigned to it. Flood believed the problem was beyond the reach of linear programming. He was right.

Flood was not a random observer. He was one of the founding minds of operations research. At the RAND Corporation after the war, he had applied game theory to the tactics of area defense, studied aerial bombing strategies, and published on transportation scheduling for military tanker fleets. He named the Traveling Salesman Problem. He co-developed the Prisoner's Dilemma with Melvin Dresher. He claimed, credibly, to have coined the word "software." When Flood identified a problem as hard, it was hard.

Alan Manne, an economic analyst at RAND from 1952 to 1956 who had since moved to the Cowles Foundation at Yale, took up the challenge. His 1958 paper, A Target Assignment Problem, is the foundational document of the field. Manne showed that under two assumptions — homogeneous kill probabilities per target and an integrality-forcing approximation — the problem could be recast as a transportation problem solvable with the machinery Dantzig had built. The paper was funded by the Office of Naval Research. The Cold War was paying for operations research at scale. The WTA problem was one of the things it bought.

The following year, DenBroeder, Ellison, and Emerling — three researchers at the Lockheed Missile and Space Division in Palo Alto — published the first extension. Their 1959 paper, On Optimum Target Assignments, introduced what is now called the Maximum Marginal Return (MMR) algorithm: assign each weapon sequentially to the target that yields the highest expected marginal gain. When weapons are homogeneous, MMR is provably optimal. When they are not, it is a fast, defensible approximation. The algorithm is still in use. If you trace the lineage of a modern missile defense fire-control loop back far enough, you will find DenBroeder's greedy assignment at the root.

The problem those four men launched — Manne, DenBroeder, Ellison, and Emerling, all responding to Flood's provocation — is now called the Weapon-Target Assignment problem (WTA). It has been under active research for nearly seventy years. It is NP-complete in its general form. It resists exact solution at scale. And it runs in production, every day, inside the combat systems that defend ships, bases, and cities from incoming fire.

The mathematical structure

The canonical static WTA (SWTA) is a nonlinear integer program. Given (n) targets with values (V_j), (m) weapon types with (w_i) weapons of type (i) available, and kill probabilities (p_{ij}) — the probability that one weapon of type (i) destroys target (j) — choose nonnegative integer assignments (x_{ij}) to minimize:

[ \min \sum_{j=1}^{n} V_j \prod_{i=1}^{m} (1 - p_{ij})^{x_{ij}} ]

subject to (\sum_j x_{ij} \leq w_i) for each weapon type (i).

The objective is the expected surviving value of the target set. The product term is the source of the difficulty. If the survival probability of a target were the sum of individual weapon contributions — (1 - \sum_i p_{ij} x_{ij}) — the problem would be a transportation problem, solvable in polynomial time. But engagements are independent events. Two weapons, each with a 50% kill probability, leave a 25% survival probability, not 0%. Independence forces the product. The product makes the problem nonlinear. The nonlinearity makes it hard.

The nonlinearity is not a modeling choice. It is a structural fact about the domain. Any formulation that linearizes the objective is solving a different problem. The problem it solves may be useful. It is not the WTA.

In 1986, S. P. Lloyd and H. S. Witsenhausen proved that the WTA is NP-complete by reduction from 3-EXACT-COVER. The proof was published in the proceedings of the Summer Computer Simulation Conference in Reno — an unusual venue for a complexity result, and one reason the paper is difficult to obtain. The proof confirmed what practitioners already knew: exact solutions are computationally intractable for realistic instances. The number of possible assignments of 100 weapons to 100 targets exceeds the number of atoms in the observable universe. You cannot enumerate. You must be clever.

The two families

The literature divides the WTA into two families: static and dynamic. The distinction changes the mathematical structure and the class of algorithms that apply.

Static WTA

In the static WTA, all assignments are made at a single moment. All information is known at decision time. No feedback arrives afterward. The problem is a single-period nonlinear integer program. This is the formulation Manne introduced and the one most of the literature addresses.

The algorithmic landscape spans three tiers:

• Maximum Marginal Return (MMR): The greedy algorithm from DenBroeder et al. (1959). Assign each weapon to the target with the highest marginal reduction in expected surviving value. Optimal for homogeneous weapons. Still the baseline.
• Exact methods: Branch-and-bound, Lagrangian relaxation, and column enumeration. Lu et al. (2021) developed an exact method that solves 400×400 instances in under five seconds — a leap from earlier methods that required sixteen hours for 80×80 instances. The advance came from reformulating the problem as an integer linear program with binary columns, combined with weapon-count bounding and domination rules.
• Metaheuristics: Genetic algorithms, ant colony optimization, particle swarm optimization, simulated annealing, tabu search, and very large-scale neighborhood search. They do not guarantee optimality. They scale to thousands of weapons and targets. They dominate the applied literature because real problems are large and time-constrained. The 2007 very large-scale neighborhood search by Ahuja et al. is the most widely cited benchmark.

The gap between exact methods and metaheuristics is the central tension of the field. Exact methods give you a certificate of optimality but choke on scale. Metaheuristics scale but offer no guarantee. In a military context, "probably good enough" and "provably optimal" produce different kinds of confidence. The choice between them is a statement about which error you can tolerate.

Dynamic WTA

In the dynamic WTA (DWTA), assignments occur in stages. You assign weapons. You observe results — which targets survived, which were destroyed. Then you assign the next wave. Rinse, repeat. This is shoot-look-shoot. It is how combat works: fire, assess, decide whether to fire again. It is also dramatically harder to model.

Hosein and Athans (1989), at MIT's Laboratory for Information and Decision Systems, formulated the general (T)-stage DWTA as a stochastic dynamic program. The state at each stage is the set of surviving targets and remaining weapons. The decision is an assignment of weapons to survivors. The transition is stochastic, governed by the kill probabilities. The DP is solvable in principle by backward recursion. In practice, it suffers from the three curses of dimensionality: the state space (which targets survive — combinatorial in the number of targets), the action space (which weapons to assign — combinatorial in weapons × targets), and the outcome space (stochastic engagement results — exponential in the number of engagements). For any instance of operational size, the DP is intractable. The DWTA inherits the NP-completeness of the static version and adds sequential decision-making on top.

Approaches to the DWTA include:

• Two-stage stochastic programming (Murphey, 2000): first stage static, second stage responding to a probability distribution over target arrivals.
• Approximate dynamic programming: estimate value functions without solving the full DP.
• Rolling-horizon heuristics: at each stage, solve a static WTA with current information, execute, observe, repeat. Crude but operational.
• Reinforcement learning: emerging rapidly, particularly for settings where engagement dynamics can be simulated at scale — drone swarms, cyber defense, any domain with a fast simulator.

The dynamic WTA is the more realistic model and the less solved one. Every real engagement is dynamic. The mathematics of sequential allocation under uncertainty — the thing the DP captures and cannot compute — remains an open field.

Variants and extensions

The WTA has spawned families of variants. Each adapts the core structure to a different operational reality:

Asset-based vs. target-based. In the target-based formulation, you minimize the expected surviving value of the targets — destroy the incoming missiles. In the asset-based formulation, you minimize expected damage to the assets the targets threaten — protect the ships, bases, or cities. The two formulations diverge when multiple targets threaten the same asset. Iron Dome's selective engagement logic — ignore rockets that will land in empty fields, intercept those headed for populated areas — is an asset-based WTA with a hard filter. The system's neural networks predict impact points within sub-second response times. Rockets predicted to strike uninhabited areas are never assigned an interceptor. The logic is operational, not theoretical, and it has been battle-tested since 2011.

Offensive vs. defensive. The mathematics is symmetric. The constraints are not. An offensive WTA models weapon survivability during transit, target hardening, and degraded kill probabilities from countermeasures. A defensive WTA models time windows, interceptor kinematics, and the consequences of a leaker — a target that survives all assigned weapons and strikes its aim point. The leaker penalty is effectively infinite. One interceptor you conserved is one target you did not kill. The defender cannot afford a miss. The asymmetry in acceptable error rates between offense and defense is not in the objective function. It is in the operational context the objective function must represent.

Coordinated WTA. Multiple platforms — ships, aircraft, ground batteries — share a sensor picture and coordinate assignments through a network. The U.S. military's C2BMC (Command and Control, Battle Management, and Communications) is the operational instance: it fuses data from space-based infrared sensors, naval radars, and ground-based AN/TPY-2 units into a common operational picture. Lockheed Martin's CommandIQ battle management application, demonstrated during Valiant Shield 2026, uses AI to evaluate engagement options before a human operator selects the weapon system. The assignment must respect which platforms can see which targets, which launchers are within a capturing radar's field of view, and which interceptors should be conserved for later salvos. The network is a constraint. The constraint is reality.

Sensor-target assignment. An adjacent problem: assign sensors, not weapons, to targets. The objective is to maximize tracking quality or detection probability. Sensors are usually reassignable rather than expendable. The structure is similar — nonlinear assignment of finite resources to valued targets — but the dynamics differ. The problem arises in air traffic control, space surveillance, and any domain where you have more things to track than sensors to track them.

Multi-objective WTA. Minimize expected surviving target value and weapon expenditure and collateral damage. The objectives conflict. You can always reduce surviving target value by firing more weapons. You can always reduce weapon expenditure by accepting more leakers. The Pareto frontier is the set of assignments for which no objective can be improved without worsening another. Every commander operates on this frontier. Most do not know its shape.

Real operational systems

The WTA problem is not a theoretical curiosity. It runs in production, in real time, inside systems that defend populations and military assets from attack. The problem structure is the same across all of them. The constraints differ.

Iron Dome. Israel's C-RAM (Counter Rocket, Artillery, and Mortar) system faces WTA problems with sub-second deadlines. Rockets launched from Gaza reach Tel Aviv in under ninety seconds. Iron Dome's radar detects the launch, its convolutional neural networks predict the impact point, its battle management system decides whether to engage, and if so, which interceptor to assign. The system achieves approximately 90% interception rates for threatening projectiles. It ignores rockets predicted to land in uninhabited areas — a hard binary filter applied before the WTA solver runs, reducing the problem size in real time. The constraint that dominates is time. The engagement window closes before most algorithms can converge. The solution must be fast or it is useless.

Aegis / THAAD / Patriot. The U.S. layered missile defense architecture operates at three tiers. Aegis BMD with SM-3 Block IIA interceptors provides exo-atmospheric midcourse defense — the outermost layer, thinning incoming raids and passing tracking data downstream. THAAD provides high-altitude terminal defense against short- and intermediate-range ballistic missiles. Patriot PAC-3 MSE provides lower-tier point defense for assets the upper layers missed. The systems coordinate through C2BMC, which fuses sensor data into a common operational picture and enables "engage-on-remote" — destroying a target using track data from a platform hundreds of miles from the firing interceptor. The WTA challenge is compounded by the fact that neither THAAD nor Patriot C2 nodes can issue engagement orders via Link 16 to dissimilar systems. Each system makes its own assignment decisions and informs the others solely to prevent redundant engagements. Voice communications fill the coordination gaps. The architecture is less integrated than the theory would prefer. The theory accommodates.

Drone swarms. The emergence of low-cost, attritable drone swarms has changed the WTA's economic structure. A $50,000 Patriot interceptor expended against a $2,000 Shahed drone is an exchange the attacker wins. The problem shifts from "assign the optimal interceptor" to "assign the cheapest weapon that achieves the required kill probability." Heterogeneous WTA — integrating missiles, high-energy lasers, high-power microwaves, and anti-aircraft guns into a single assignment problem with different cost profiles and engagement time windows — is an active research frontier. Russia has tested swarm drone attack tactics where three drones carrying 3 kg warheads autonomously identify and engage a target using AI and mesh-network coordination. The WTA in this context is distributed: each drone runs a local assignment algorithm, bids against its neighbors for targets, and converges on a globally coherent allocation without a central solver. The coordination protocol is as important as the assignment algorithm.

The WTA problem has moved from the operations research journals into the fire-control loop. The transition took seventy years. The problem structure survived intact. The constraints got tighter.

Why the families matter

The WTA's families are not taxonomic convenience. They encode assumptions about what information is available at decision time and what feedback arrives afterward. Change the assumptions and you change the mathematical structure of the problem — which algorithms apply, which guarantees survive, which errors are possible.

The static WTA assumes you know everything and receive no feedback. The dynamic WTA assumes you learn as you go. The asset-based formulation assumes you care about what the targets threaten, not the targets themselves. The coordinated variant assumes communication is imperfect. Each assumption is a design decision about what the model represents and what it ignores.

The families proliferate because operational reality is more varied than any single formulation can capture. A ballistic missile defense engagement with sixty seconds of warning is a static WTA — there is no time for a second look. A drone swarm engagement over hours is a dynamic WTA with communication constraints. A cyber defense allocation, where countermeasures are deployed continuously against evolving attack vectors, is a sensor-target variant with reassignable resources. The problem structure persists. The constraints change. The algorithms must follow.

The trajectory

The WTA problem has been under research for nearly seventy years. The trajectory of the research tracks the trajectory of computation itself: linear approximations in the 1950s and 1960s; exact branch-and-bound methods as computing power grew; metaheuristics as problem sizes exceeded exact solvability in the 1990s and 2000s; machine learning and reinforcement learning in the current era.

Samuel Matlin published the first survey in 1970, covering the first decade of work. Kline, Ahner, and Hill published the most comprehensive modern survey in 2019, spanning formulations, exact algorithms, heuristics, and both static and dynamic variants. A 2025 bibliometric review of 463 papers traces three evolutionary phases: infancy through 2004 (fewer than five papers per year), exploration from 2005 to 2015 (up to twenty-six papers per year), and rapid growth after 2015, driven by multi-objective, multi-stage, and learning-based approaches.

The growth is not academic fashion. The allocation problem Manne formalized — finite, probabilistic resources against valued targets under uncertainty — is the allocation problem an increasing number of systems must solve. Missile defense. Drone swarms. Cyber operations. Sensor networks. The problem is not going away. The algorithms are getting faster. The gap between the model and the engagement — between the nonlinear integer program and the stochastic, communication-constrained, adversarial reality of combat — is where the work remains.

References:

• Flood, M. M. (1948). "A Game Theoretic Study of the Tactics of Area Defense." RAND Research Memorandum RM-130. — The precursor: game-theoretic analysis of area defense resource allocation, written while Flood was at RAND, before he posed the WTA problem at Princeton in 1957.
• Manne, A. S. (1958). "A Target Assignment Problem." Operations Research, 6(3), 346–351. — The foundational paper: first formal WTA formulation, linear programming approximation for homogeneous weapons. Written at the Cowles Foundation, Yale, under Office of Naval Research contract Nonr-358(01).
• DenBroeder, G. G., Ellison, R. E., & Emerling, L. (1959). "On Optimum Target Assignments." Operations Research, 7(3), 322–326. — The first extension: Maximum Marginal Return algorithm, two engagement models (homogeneous and heterogeneous), from Lockheed Missile and Space Division.
• Matlin, S. (1970). "A Review of the Literature on the Missile-Allocation Problem." Operations Research, 18(2), 334–373. — The first survey of the field, covering the first decade of missile-allocation research.
• Lloyd, S. P., & Witsenhausen, H. S. (1986). "Weapons allocation is NP-complete." Proceedings of the 1986 Summer Computer Simulation Conference, 1054–1058. — The NP-completeness proof via reduction from 3-EXACT-COVER.
• Hosein, P. A., & Athans, M. (1989). "Preferential Defense Strategies." MIT Laboratory for Information and Decision Systems, LIDS-P-1902. — General multi-stage dynamic WTA formulation as a stochastic dynamic program.
• Murphey, R. A. (2000). "Target-Based Weapon Target Assignment Problems." In P. M. Pardalos & L. S. Pitsoulis (eds.), Nonlinear Assignment Problems, Kluwer, 39–53. — Two-stage stochastic programming formulation for the dynamic WTA.
• Ahuja, R. K., Kumar, A., Jha, K. C., & Orlin, J. B. (2007). "Exact and Heuristic Algorithms for the Weapon Target Assignment Problem." Operations Research, 55(6), 1136–1146. — Very large-scale neighborhood search; the most widely cited computational benchmark.
• Kline, A., Ahner, D., & Hill, R. (2019). "The Weapon-Target Assignment Problem." Computers & Operations Research, 105, 226–236. — The authoritative modern survey covering formulations, exact algorithms, heuristics, and both static and dynamic variants.
• Lu, Y., Li, D., & Ruan, J. (2021). "A new exact algorithm for the Weapon-Target Assignment problem." Omega, 98, 102138. — Column enumeration with branch-and-bound; first exact method to solve 400×400 instances in seconds.

In 1976, Edsger Dijkstra published a book that opened with a claim most programmers would find alien today: that the primary task of a programmer is not to write programs, but to construct proofs. The programs are a byproduct. The proofs are the work.

A Discipline of Programming is 217 pages. It introduces the weakest precondition calculus, the guarded command language, and a methodology for deriving programs from their specifications by developing the correctness proof slightly ahead of the code. The book is difficult. It is also the most sustained argument ever written for the proposition that simplicity and reliability are the same property considered from different angles.

The argument

Dijkstra's central claim is that you cannot verify correctness after the fact. You must construct it alongside the program, with the proof leading and the code following. His own formulation of the conclusion is worth quoting at length, because the precision of the language is the argument:

"It does not suffice to design a mechanism of which we hope that it will meet its requirements, but that we must design it in such a form that we can convince ourselves — and anyone else for that matter — that it will, indeed, meet its requirements. And, therefore, instead of first designing the program and then trying to prove its correctness, we develop correctness proof and program hand in hand. (In actual fact, the correctness proof is developed slightly ahead of the program: after having chosen the form of the correctness proof we make the program so that it satisfies the proof's requirements.)"

This is not a claim about process. It is a claim about the relationship between a program and the reasoning that justifies its existence. If you write the program first and attempt to verify it afterward, you are attempting to reconstruct the reasoning that would have produced the program had the program been derived from its specification. The reconstruction is harder than the derivation would have been, because the program contains implementation decisions that were made without being constrained by the proof. You are now trying to discover whether those unconstrained decisions happen to be correct. The probability that they all are, in a program of non-trivial size, is remote.

The practical consequence: programs derived from their proofs are reliably shorter and clearer than programs written forward from intuition, because the proof forces you to eliminate everything that is not necessary to establish the postcondition.

The mechanism Dijkstra proposed for this derivation is the weakest precondition calculus. For any program statement and desired postcondition — a logical formula describing what must be true after the statement executes — the weakest precondition is the least constrained precondition that guarantees the statement will terminate in a state satisfying the postcondition. The calculus provides transformation rules for each construct in the language. To derive a program, you start from the postcondition and work backward through the rules until you reach a precondition you can satisfy. The program that emerges from this process is correct by construction. It cannot be otherwise, because it was built to satisfy the proof at each step.

The language Dijkstra designed for expressing these derivations is deliberately minimal — alternation and repetition with guarded commands, no recursion, no complex features. His justification is instructive: "The point is that I felt no need for them in order to get my message across, viz. how a carefully chosen separation of concerns is essential for the design of in all respects, high-quality programs: the modest tools of the mini-language gave us already more than enough latitude for nontrivial, yet satisfactory designs." The language is minimal because minimality is the point. Every construct you add to a language expands the space of programs that can be written and therefore the space of programs that must be verified. A smaller language makes the verification task smaller.

Why simplicity is not an aesthetic preference

Dijkstra identified several ideas in the book that he described as "elusive" — ideas that should take root in the mind of a programmer but typically don't, because the industry treats them as matters of style rather than as structural requirements.

The first of these is simplicity. Dijkstra's argument is not that simple programs are nicer to read. It is that simple programs are the only programs for which correctness proofs are feasible. Complexity is not merely unpleasant; it is a barrier to verification. A program that is too complex to reason about is a program whose correctness cannot be established. Whether it actually works is unknown, and testing — Dijkstra's most famous observation — "reveals only the presence of errors, not their absence." A tested program that passes all its tests is a program for which no known inputs produce incorrect outputs. It is not a correct program. The distinction is not philosophical. It is the difference between a bridge that has survived every load it has encountered and a bridge that has been shown, by structural analysis, to withstand every load it could encounter.

The second is elegance. Dijkstra used the word, which makes engineers uncomfortable, but he meant something precise. An elegant solution is one in which the proof of correctness is natural — where the formal argument flows without contortion, because the program structure mirrors the logical structure of the specification. Elegance is not decoration. It is evidence that the derivation worked.

In Dijkstra's framework, simplicity, elegance, and reliability are not three properties. They are one property described three ways. A simple program is one whose correctness proof is manageable. An elegant program is one whose correctness proof is natural. A reliable program is one whose correctness proof exists.

The connection to the agent era

Agents produce programs by statistical prediction. They do not construct proofs. They do not derive programs from specifications. They generate tokens that are probable given their training data, and the programs that result from this process have no accompanying reasoning that justifies why they are correct. They might be correct. They might not be. There is no way to know from the output alone, because the output was not produced by a process designed to establish correctness.

This makes Dijkstra's argument more urgent, not less. If programs are increasingly produced by entities that cannot reason about their correctness, then the verification burden shifts entirely to the infrastructure surrounding those entities. The harness must supply the reasoning the agent cannot perform. The verification layer must establish what the generation process cannot guarantee.

Dijkstra argued that the proof must lead and the program must follow. In the agent era, the proof still has to exist. The question is who — or what — constructs it, and whether the program is constrained by it or merely inspected by it afterward. If the agent produces code and a separate system verifies it, the verification is still an attempt to reconstruct the reasoning that would have produced the program had it been derived correctly. The reconstruction is harder than the derivation. The probability that it succeeds on every change, at the speed agents generate changes, is remote.

Dijkstra's methodology does not scale to the agent era in its original form. No one is going to derive weakest preconditions for agent-generated code at review time. But the principle — that correctness must be constructed, not inspected into existence — does not become false because it becomes harder to satisfy. It becomes more expensive to ignore.

References:

• Dijkstra, E. W. (1976). A Discipline of Programming. Prentice-Hall. — The source text: weakest preconditions, guarded commands, and the argument that correctness proofs must lead and programs must follow.
• Dijkstra, E. W. (1972). "The Humble Programmer." Communications of the ACM. — The earlier lecture that established the tone: programming is inherently difficult, and the only way to manage that difficulty is through disciplined simplicity.
• Related: Correctness First — What OpenBSD teaches about correctness as the prerequisite for security.
• Related: Taste as Conceptual Integrity — Brooks on the property Dijkstra's methodology was designed to preserve.
• Related: In the Land of AI Agents, the Verifiers Are King — The verification imperative in the agent era.

Block released Buzz on Monday. The pitch: an open-source collaboration platform where humans and AI agents work together in a shared workspace, built on the Nostr protocol, licensed under Apache 2.0, self-hostable or available managed at buzz.xyz. The source is at github.com/block/buzz.

The surface-level story is that a major company shipped an open alternative to the proprietary agent platforms currently being built inside every cloud provider and VC-backed startup. That story is accurate as far as it goes. But the thing that makes Buzz interesting is not the collaboration model. Shared workspaces for humans and agents are becoming table stakes — every chat platform will have them within two years. The interesting thing is the identity architecture, because it solves a problem most teams haven't realized they have yet.

The identity problem

When an agent acts inside your infrastructure today, who is it? The answer is usually a variant of "a service account tied to a platform vendor's API key." The agent's identity is not its own. It is leased from whichever provider generated the token. If you switch models — from OpenAI to Anthropic, from one agent harness to another — the agent's identity does not travel with it. Its history, its permissions, its reputation within the team: all of that is bound to the specific API key and platform that provisioned it. This is not a technical limitation. It is an architectural choice made by every agent platform so far, and it has consequences.

The most immediate consequence is that there is no portable answer to the question "which agent made this change?" If a production incident traces back to a commit authored by an agent, the team needs to know which agent, running which model, under which constraints, with which permissions, at whose instruction. In a platform where agent identity is an API key, the answer is: the agent that held the key at that moment. If the key rotated, or the team switched providers, or someone reconfigured the agent harness between incidents, the identity trail breaks. That is acceptable for a chat bot. It is not acceptable for an agent that deploys code.

The second consequence is that there is no basis for reputation. If agents are going to operate with increasing autonomy — reviewing code, approving merges, managing infrastructure — the humans who work alongside them need to calibrate trust. Which agents are reliable? Which make specific kinds of mistakes? Which have access to what? These questions require stable identity. You cannot build a reputation system on top of rotating API keys.

The third consequence is vendor lock-in, which is the one Block's announcement emphasizes most directly. If your agents' identities are owned by a platform, migrating off that platform means destroying those identities and recreating them elsewhere. The switching cost is not the difficulty of moving prompts and configurations. It is the loss of the accumulated context that makes the agents useful.

How Buzz solves it

Buzz is built on Nostr, a protocol designed for decentralized social networking. The relevant property of Nostr for Buzz's purposes is that every participant — human or agent — holds a cryptographic keypair. The keypair is not issued by Buzz. It is not issued by any platform. It is generated by the participant and can be used across any Nostr-compatible system.

What this means in practice: an agent configured in Buzz has an identity that is cryptographically its own. It authenticates by signing events with its private key. Its messages, its actions, its contributions — all are verifiable as having originated from that specific agent, regardless of which model is behind it, which harness is orchestrating it, or which relay is delivering its messages. If a team moves from Block's managed hosting to a self-hosted instance, the agent's identity moves with them. If a team switches the model powering the agent from Claude to Gemini, the identity persists. The identity is not a feature of the platform. It is a property of the agent.

This has practical implications that go beyond portability. An agent that commits code can sign the commit with its own key. An agent that reviews a pull request leaves a review that is cryptographically attributable. An agent that participates in an incident response leaves a record that can be audited. The trail does not break when the API key rotates, because the identity is not the API key.

Buzz's architecture separates agent identity from model access. The identity is a keypair. The model is a configuration choice. They are independent axes. Most agent platforms today conflate them.

What's genuine and what's marketing

Every product announcement makes claims. It is worth distinguishing which parts of Buzz's proposition are structurally unique and which are well-executed versions of ideas that are becoming standard.

Structurally unique: the identity layer. No other major agent platform gives agents portable, cryptographic identities that are independent of the platform. This is not a feature Buzz added to an existing architecture. It is a consequence of building on Nostr, which was designed to solve exactly this problem for a different domain. The decision to use a decentralized protocol for agent identity is novel, and it has downstream consequences — for auditability, for reputation, for portability — that are not achievable within a platform-owned identity model. Whether Nostr is the right protocol for this use case is a separate question, but the architectural choice is genuinely different from what exists.

Well-executed but not unique: the collaboration model. Shared channels, threads, direct messages, voice, code repositories — this is a well-designed workspace, but the category is crowded. What distinguishes Buzz's execution is that agents are first-class participants rather than integrations bolted onto a human platform, but that distinction will erode as every collaboration tool adds agent support. The structural advantage is the identity layer. The UX is good but replicable.

Strategically significant: open source from a major company. Block is not a startup. It is a public company with a market cap in the tens of billions, the parent of Square and Cash App. When a company of that scale releases an agent platform under Apache 2.0 with a self-hosting option, it changes the economics for every startup building proprietary agent collaboration tools. Free and open source from a credible maintainer resets the floor for what teams will pay for. The fact that Block built this on an open protocol rather than a proprietary stack makes the bet even clearer: they are betting that the infrastructure layer for agent collaboration should be a public good, not a proprietary platform. Whether that bet pays off depends on adoption, but the direction of the bet is legible.

Buzz and GitButler: two layers of the same problem

Buzz was not the only significant agent infrastructure release this year. GitButler, the Git client founded by Scott Chacon (GitHub co-founder, author of Pro Git), has been quietly building infrastructure for the same problem from a different layer of the stack.

Where Buzz addresses the collaboration layer — who is working on what, how do agents communicate, how is identity established — GitButler addresses the version control layer: how do you manage code when multiple humans and multiple agents are changing it simultaneously?

The core innovation is virtual branches. In traditional Git, you work on one branch at a time. Switching branches means checking out a different set of files — context-switching your working directory. Git worktrees mitigate this by giving each branch its own directory, at the cost of disk space and coordination overhead. GitButler replaces both models. Multiple branches are applied simultaneously within a single working directory. Files from different branches coexist in the same workspace. There is no checkout. There is no context switch.

This matters for agents because agents produce code in parallel. An agent fixing a bug, an agent implementing a feature, and an agent refactoring a module can all operate on the same repository at the same time, each on its own virtual branch, without conflicting at the filesystem level until their changes actually overlap. GitButler detects conflicts immediately — not at merge time — because all branches share a single working tree.

The integration with agents is deeper than the branching model. Each virtual branch can be bound to an independent agent session. GitButler provides hooks for Claude Code and Cursor that automatically route file edits to the correct virtual branch and handle commits when a session ends. A single command — but rub — handles assign, move, squash, and amend operations, which is how you post-hoc organize files into branches when multiple agents have been working across multiple concerns.

GitButler's documentation describes seven multi-agent collaboration patterns: parallel feature development, sequential handoff between agents, cross-agent commit transfer, agent code review cycles, agent swarms on a shared branch, exploratory development (multiple approaches in parallel, keep the winner), and emergency hotfix without disturbing ongoing work. These are not theoretical. They are documented patterns that the tool's primitives make possible.

The comparison that matters. Buzz and GitButler are not competitors. They are complementary infrastructure at different layers. Buzz gives an agent a portable identity and a place to communicate with humans and other agents. GitButler gives that agent a way to produce and manage code alongside other agents without stepping on each other's work. Together they sketch what agentic software engineering infrastructure looks like: identity at the protocol layer, virtualized branching at the version control layer, agents as first-class participants at both. The verification layer — determining whether any of this agent-produced code is actually correct — remains the hardest piece of the stack, and the subject of a separate discussion.

Buzz and GitButler are not the final form of agent infrastructure. They are early, credible bets on what the stack needs to look like. Buzz bets that the collaboration layer — identity, communication, shared context — should be open at the protocol level, with agents holding their own cryptographic identities rather than leasing them from a platform. GitButler bets that the version control layer needs to be rethought from first principles for a world where multiple agents produce code in parallel, and that virtualized branching is the right abstraction. Neither bet is proven. Both are made by people with the track record to be taken seriously — Block on one side, Scott Chacon on the other.

What neither addresses is verification. An agent with a portable identity can produce coherent-looking code on a virtual branch. The identity tells you who. The branch tells you how the work was managed. Neither tells you whether the change is correct within the context of the whole system. That is the verification layer, and it remains the hardest piece of the stack.

The test for agent infrastructure is not whether agents can participate. It's whether you can answer "who did what, why, and was it correct?" six months after the fact, after rotating credentials, switching models, and changing platforms. Buzz and GitButler get you closer to an answer than anything else currently available. But the "was it correct?" column is still empty.

References:

• Block. (2026). "Introducing Buzz: Where Humans and Agents Work Together." — The official launch announcement.
• Buzz source code: github.com/block/buzz (Apache 2.0)
• Buzz hosted: buzz.xyz
• Related: goose — Block's open-source agent framework, compatible with Buzz.
• GitButler. "Why GitButler." — Scott Chacon's manifesto for rethinking version control.
• GitButler. "Getting Started With GitButler Agents." — Virtual branches, agent sessions, and multi-agent collaboration patterns.
• Related: In the Land of AI Agents, the Verifiers Are King — The verification imperative that neither Buzz nor GitButler yet addresses.

Ray Myers posted a thought experiment on LinkedIn this week:

"Imagine a phrase like 'The building fell down after the inspector's taste was ignored.' Is there any situation where you would feel accountable to heed someone's taste?"

Ray's experiment is effective because the sentence he asks us to imagine contains its own refutation. If a building collapses and the subsequent investigation reveals that an inspector objected and was overruled, we do not describe what happened as the inspector's taste being ignored. We describe it as the inspector's professional judgment being overridden. The word "taste" does not merely fail to capture the gravity of the situation — it actively miscategorizes it. It moves the event from the domain of engineering accountability, where the question is whether the objection was correct, to the domain of aesthetics, where the question is whether the objection was agreeable. These are different categories of judgment, and conflating them is a category error.

The reason the word persists despite this flaw is that it gestures at something real. When a senior engineer looks at a proposed change and says "this does not feel right," they are not stating a preference. They are reporting a perception. They have detected something about the system before they have isolated what it is or produced evidence for its existence. The question is what, exactly, they are detecting.

The most precise answer was given by Fred Brooks. The property being perceived is conceptual integrity.

The property

Brooks defined conceptual integrity as the property of a system that feels as though one mind designed it. In The Mythical Man-Month (1975) he wrote:

"I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas."

Thirty-five years later, in The Design of Design, he reduced the claim to its most concentrated form:

"Most great works have been made by one mind. The exceptions have been made by two minds."

Neither statement is a claim about aesthetics. Both are structural claims about the conditions under which coherence enters a designed object. Brooks's argument, developed across both books, is that design does not parallelize. Every additional mind added to a design introduces assumptions that differ from the assumptions already present. Those assumptions must be reconciled. Reconciliation requires compromise. Each compromise reduces coherence, because the original set of design ideas was internally consistent and the compromise introduces an element that was not part of that set. Brooks put the point economically: "Many hands make light work — Often. But many hands make more work — Always." You can distribute the labor of implementation across as many people as the coordination overhead permits. You cannot distribute the labor of deciding what the thing is. The design must proceed from one point of decision, or at most two in what Brooks called genuine resonance — a pair who share a mental model so completely that either can speak for the architecture. Three is already a committee, and committees produce settlements, not coherence.

If this argument is accepted, a definition follows: taste is the ability to perceive conceptual integrity. It is the faculty by which an engineer detects that a system has maintained coherence or lost it — that the parts compose or have begun to diverge, that the whole still speaks with one voice or has acquired a second. The senior engineer who says "this does not feel right" is perceiving a violation of conceptual integrity before they can name the specific violation. The feeling is not the argument. It is the reason to begin looking for one.

The positive case

Brooks's canonical example is Reims Cathedral. Ground was broken in 1211. Structural work was completed by 1275, and decorative work continued into the 1460s. Across those two and a half centuries, four master masons — Jean d'Orbais, Jean-le-Loup, Gaucher of Reims, and Bernard de Soissons — directed the construction. Their names were inscribed in a labyrinth set into the nave floor. The labyrinth was not a signature in the modern sense; it was a public oath to a design larger than any single lifetime. Each man bound himself to the constraints established by his predecessor, and each successor did the same.

The coherence of the result was not achieved by consensus. It was achieved by constraint. Reims was among the first buildings to use stones of standardized dimensions, which reduced the degrees of freedom available to each successive builder. The structural system — four-part rib vaults producing arcades of identical pillars rather than the alternating pillars and piers of earlier Gothic — made the architectural rhythm self-enforcing. Once the pillar spacing and vault geometry were fixed, any architect who altered them would have broken the structural logic of the building. The plan had mechanical authority. It did not require that each successor agree with it; it required only that each successor could not alter it without producing visible damage.

The result is a building in which you cannot identify the transition from one architect to the next. Two centuries of evolving Gothic fashion — bar tracery in the transept roses giving way to full Rayonnant in the west façade — read not as competing visions but as variation within a theme. The first architect's taste set the constraints. The constraints outlived him because they were structural, not advisory.

The negative case

If Reims demonstrates what happens when taste has authority, the Bradley Fighting Vehicle demonstrates what happens when it does not.

The Bradley began as a light troop carrier. Over 17 years and at a cost of $14 billion, successive groups of stakeholders added requirements. Armor advocates wanted more survivability. Infantry commanders wanted more troop capacity. Generals wanted more firepower. Contractors wanted larger contracts. Each of these requests was defensible when evaluated against the objectives of the stakeholder who made it. The problem is not that any individual request was unreasonable. The problem is that there was no single mind with the authority to evaluate each request against the coherence of the whole — to say, this feature is reasonable on its own terms, and it will break the design, so the answer is no.

The result was a vehicle that Sergeant Fanning, a character in the 1998 HBO film The Pentagon Wars, describes with the precision of someone who has spent years watching the logic play out:

"A troop transport that can't carry troops, a reconnaissance vehicle that's too conspicuous to do reconnaissance, and a quasi-tank that has less armor than a snowblower, but has enough ammo to take out half of D.C."

Every clause in that sentence corresponds to a stakeholder requirement that was defensible when considered in isolation. Together they describe a machine that performed no role adequately because it was required to perform every role simultaneously. The film documents that live-fire testing was manipulated to conceal the vehicle's failures; that the officers responsible for the manipulation were promoted; and that Lt. Colonel James Burton — the one person in the story who acted as though coherence mattered, who forced an honest test over the objections of his chain of command — was eventually forced into retirement.

The Bradley is the limiting case of what Brooks described as "many good but independent and uncoordinated ideas." It was not produced by incompetence or bad faith. It was produced by a structural condition: a decision-making process in which every stakeholder could add a requirement and no single mind could reject one. The output was not a design. It was a negotiated settlement. And it is the reason the word "taste" must be defined precisely. If taste means personal preference, then ignoring it is reasonable. If taste means the perception of conceptual integrity, then ignoring it is how you produce the Bradley.

The organizational conditions

Brooks did not stop at naming the property. On IBM System/360, he, Gene Amdahl, and Gerrit Blaauw implemented the organizational structures required to preserve it. The principles are distributed across both books. Considered together, they form a set of necessary conditions.

One mind, or two in genuine resonance. Brooks and Blaauw achieved a working relationship in which either could speak for the architecture — a state Brooks described as resonance and glossed with what may be the most human observation in either book: "And two is indeed a magic number for collaborations; marriage was a brilliant invention and has a lot to be said for it." Three people cannot maintain this state. At three, the dynamic shifts from resonance to negotiation, and negotiation produces settlements rather than designs.

Real veto power. The architect must be able to refuse a feature and have the refusal stand. Brooks described this as saying no "repeatedly, to smart people with good arguments." Advisory veto — in which the architect may object but a person higher in the reporting chain may override the objection — is indistinguishable in practice from having no veto at all. The vice president approves the feature. It ships. The coherence of the system degrades. The vice president eventually moves to a different organization. The architect remains, responsible for the accumulated consequences of decisions they were not permitted to make.

The separation of design from implementation. Brooks devoted a chapter of The Design of Design to what he called the divorce of design — the progressive separation, beginning around the 16th century, of the act of specifying from the act of making. On System/360, this principle was operationalized as a small architecture team that defined what the system was and a large implementation team that built how it worked. "The architecture team must be protected; the implementation team must be coordinated." Organizations that assign both functions to the same people discover that neither is performed adequately. The architects, drawn into the demands of implementation, cease to think about systemic coherence. The implementers, asked to make architectural decisions, optimize for the local context at the expense of the whole.

Protection from organizational forces. The System/360 architecture team was deliberately insulated from field sales, who wanted features for specific customers; from engineering, who wanted optimizations that would have compromised the cleanliness of the abstractions; and from customers, who demanded backward compatibility with their existing systems. Each of these demands was legitimate. Accommodating any significant fraction of them collectively would have destroyed the system's coherence. The insulation was not a privilege extended to the architects. It was a structural precondition for the design work to be possible at all.

Career paths that reward refusal. Brooks implied this condition throughout both books without stating it as directly as the evidence warrants. In most organizations, agreeing to requests accumulates political capital and refusing them spends it. If the incentive structure penalizes the person who protects coherence, then taste may exist within the organization — individual engineers may perceive what is happening to the system — but it will be systematically powerless. The Bradley provides the limiting case: the officers who manipulated the tests were promoted; the officer who forced an honest evaluation was removed from service.

Open questions

Brooks's conditions assume a human designer producing at human speed. Coding agents break that assumption. They generate tokens that are statistically probable given their training distribution and context window. They do not generate coherent designs, because coherence across the entire surface area of a system is not a statistical property — it is a structural property that must be imposed by an entity capable of holding the whole in view. An agent can write a function that compiles and passes its tests while violating the design philosophy that every adjacent function observes. It does so without awareness, because the design philosophy is not legible in the text the agent was trained on. The rationale lived in the head of the person with the authority to say no.

This raises questions Brooks did not live to address:

Does taste become the irreducible human contribution, or does the role become impossible? An architect can veto a human engineer's output at the speed of code review. An architect cannot veto at the speed of token generation. If an agent produces a Bradley-scale incoherence in an afternoon — and the Bradley took 17 years — maintaining conceptual integrity may require constraints so deeply embedded in the generation pipeline that the architect's role shifts from reviewer to tool-builder. Whether that role still satisfies Brooks's definition of the designer is an open question.

Can taste be automated? If taste is the ability to perceive violations of conceptual integrity, and conceptual integrity is a property of the system considered as a whole, then automating taste requires building a system capable of forming a model of the whole. Current agents cannot do this. It is unclear whether the limitation is architectural — larger context windows, better retrieval — or categorical. If coherence can only be perceived by holding the entire set of design decisions in view simultaneously, and the set grows faster than any context window can expand, then taste may be the capacity that survives automation because it is the capacity that automation cannot reach.

If an agent generates 500 lines and a human keeps 30, who wrote the feature? The question is not rhetorical. If the human's contribution is selecting which output maintains the system's coherence, then the job is not prompt engineering. It is architecture in Brooks's sense: one mind enforcing conceptual integrity against a force that produces incoherence at speed. The title matters because the authority matters. You cannot enforce coherence if your role is understood by the organization as "the person who writes the prompts."

Ray's experiment contains its own answer, provided the term is defined correctly. "The building fell down after the inspector's taste was ignored" fails because it miscategorizes professional judgment as personal preference. Reformulate: the Bradley became a death trap because the people capable of perceiving conceptual integrity lacked the authority to enforce it. That sentence identifies a faculty, a property, and a failure mode. It describes an event for which someone can be held accountable.

Brooks supplied the property, the evidence, and the organizational conditions under which the faculty can function. What he could not supply — what no one can yet supply — is an account of whether taste, defined this way, survives an era in which code is generated faster than any human can perceive whether it coheres. That question is now operational. We will have an answer whether we want one or not.

References:

• Myers, R. (2026). "Let's try an experiment to see if we want to embrace 'taste' as the term for engineering judgment." LinkedIn.
• Brooks, F. P. (1975). The Mythical Man-Month. — Conceptual integrity as the most important consideration in system design; the one-mind rule; the architect's authority to say no.
• Brooks, F. P. (2010). The Design of Design. — "Most great works have been made by one mind. The exceptions have been made by two minds." "Many hands make light work — Often. But many hands make more work — Always." The divorce of design from implementation.
• The Pentagon Wars (1998). Dir. Richard Benjamin. HBO. Based on Col. James G. Burton's book The Pentagon Wars: Reformers Challenge the Old Guard.
• Related: Brooks on Software Design: conceptual integrity · one-mind rule · protecting the designer

Martin Fowler published his notes from the second Future of Software Development Retreat today. The retreat gathers senior engineers and executives from across the industry to assess where software development is heading. Fowler's notes are worth reading in full. The headline findings are worth sitting with, because they converge on a thesis this blog has been building across multiple posts.

The Thoughtworks report from the retreat surfaced five headline findings. Three of them are directly about the topics we've been covering:

"Code generation is no longer the bottleneck — verification is."

This is the exact argument from the Sonar AC/DC post: the verifiers are king. It's the argument from the harness engineering post: evaluation infrastructure matters more than model intelligence. It's the argument from the data-driven design post: you can't improve what you don't measure. And now it's the headline finding from a room full of industry leaders at a retreat convened by the most respected voice in software engineering.

When a thesis shows up independently in product form (Sonar's AC/DC), in academic framing (harness engineering as a discipline), and in Fowler's retreat consensus, it's no longer a prediction. It's a description of where the industry is now.

"'Harness engineering' is emerging as a distinct, ownable discipline."

This blog has been arguing for harness engineering as a first-class discipline since May 2026. Fowler's retreat now names it as an emerging field. The recognition matters because "distinct, ownable discipline" is the language of organizational design. When something becomes a distinct discipline, it gets budget, headcount, career tracks, and dedicated tooling. Harness engineering crossing that threshold means the teams that already have harness engineers are ahead, and the teams that don't are about to discover they need them.

"Legacy modernization is the clearest, most defensible near-term value pool."

This is less obvious but equally important. The retreat found that the most defensible use case for AI coding agents isn't greenfield development — it's modernizing legacy systems. Agents can ingest old codebases, understand their structure, and systematically refactor them in ways that would take human teams years. The value is measurable, the risk is bounded (the old system already works, so you can compare), and the alternative cost is known (maintaining the legacy system indefinitely).

The other two findings are about organizational dynamics rather than technical architecture, but they're equally revealing:

• "Organizations are colliding with a real apprenticeship crisis." If agents write the boilerplate and seniors only review, how do juniors learn? The apprenticeship pipeline that produced every senior engineer reading this post is being disrupted in real time, and nobody has a convincing answer for what replaces it.
• "The executive/engineer expectation gap is a bigger risk than any technical limitation." Boards see 3-5x productivity claims and expect headcount reduction. Engineers see the bugs, the security issues, and the unrequested features agents insert. The gap between those perspectives is wider than any model capability gap.

The most telling detail

Fowler shares a story about a team that spent three days investigating a feature an agent inserted that nobody asked for. Three days trying to figure out who requested it, what it was supposed to do, and whether anyone wanted to keep it. Three days of engineering time consumed by code that should never have been written.

This is the productivity paradox in microcosm. The agent saved someone 30 minutes of typing and cost the team three days of investigation. Net productivity: negative.

Fowler also notes that agents don't learn. The best they can do is update context. Every mistake an agent makes, it will make again unless the harness explicitly prevents it. Every unrequested feature it inserts, it will insert again unless the guide constraints explicitly block it. The agent is not getting better on its own. The harness has to get better around it.

The law professor experiment

One of the most striking anecdotes in Fowler's notes is unrelated to software engineering but deeply relevant to how we should think about LLM output. Law professors evaluated answers to contract law questions — some written by professors, some by LLMs. The professors rated LLM answers higher than their peers 75% of the time. LLM answers were flagged as harmful 3.5% of the time. Human professor answers: 12%.

LLMs outperform domain experts on short-form domain questions judged by those same domain experts. And they produce fewer actively harmful answers.

This doesn't mean LLMs should replace law professors. It means the quality bar for agent-generated output is higher than most skeptics assume — and the error rate of human experts is higher than most humans assume. Verification isn't just for AI output. It's for all output. The difference is that humans have been dodging systematic verification for decades, and agents make the need undeniable.

DSLs as the bridge

Fowler discusses work by Unmesh Joshi and Spencer Nelson on using Domain-Specific Languages as an interface layer between LLMs and systems. The idea: design a small, token-efficient language with hard security boundaries. The LLM generates DSL code. A deterministic runtime executes it. The DSL constrains what the LLM can express, which constrains what it can break.

This is pledge(2) for agents — a restricted interface that makes the wrong thing impossible. If the DSL has no way to express "drop this table," the agent cannot drop a table, no matter how badly it hallucinates.

Fowler notes that LLMs have historically lowered the barrier to building DSL parsers and tooling, which was the main obstacle to DSL adoption. But his more interesting point is that the DSL is just a projection of a semantic model — and the semantic model is what matters. LLMs may let us explore new ways to project those models.

The LLM voice problem

Fowler closes with a personal reflection on what he calls "LLM miasma" — the recognizable stylistic signature of AI-generated prose that triggers what he describes as intellectual nausea. He's reversing his earlier position that non-professional writers should use AI to polish their prose. The LLM voice is now so pervasive that it discredits writing before the reader engages with the content.

His antidote: read your drafts aloud. Speech patterns are closer to your authentic voice. If it doesn't sound like something you'd say, rewrite it until it does.

This matters for agent-era engineering in a way that isn't immediately obvious. If LLM-generated code comments, commit messages, and documentation all carry the same stylistic signature, teams will develop the same antibodies Fowler describes. They'll stop reading. The code will compile but the knowledge transfer won't happen. Authentic voice isn't just a writing concern — it's a knowledge-sharing concern in a world where agents produce most of the text.

What this means

Fowler's retreat didn't produce new ideas. It produced independent confirmation. The people in that room — senior engineers, executives, thought leaders — converged on the same conclusions that teams on the ground have been reaching through trial and error: verification is the bottleneck, harness engineering is the discipline, legacy modernization is the beachhead, and the gap between what executives believe and what engineers experience is enormous.

If you're building agent systems, these findings are your strategy document. Verification infrastructure. Harness engineering as a dedicated function. Legacy systems as the proving ground. Closing the expectation gap with data, not demos. And writing — code, docs, commits — in a voice that doesn't trigger the antibodies.

The industry's most respected voice just said what this blog has been saying for months. The difference is that when Martin Fowler says it, organizations listen.

References:

• Fowler, M. (2026). "Fragments — July 21, 2026." — Notes from the second Future of Software Development Retreat. The headline findings and all anecdotes discussed here are drawn from this piece.
• Thoughtworks. (2026). Future of Software Development Retreat Report. — The full report from the retreat, cited by Fowler.
• Related: In the Land of AI Agents, the Verifiers Are King — Sonar's AC/DC framework and the productivity paradox of AI coding agents.
• Related: Harness Engineering: Best Practices for Reliable Agent Systems — Why the harness is the most under-invested part of agent systems.
• Related: Agents Are Too Stochastic for Intuition — Data-driven design as the only reliable method for stochastic systems.
• Related: Correctness First — What OpenBSD teaches about correctness as the prerequisite for security.

Most quantitative trading is built on a lie: markets are in equilibrium, returns are Gaussian, linear models are enough. These assumptions hold in the boring middle of the distribution, where nobody makes or loses serious money. They break at the tails, which is where everything interesting happens.

The efficient market hypothesis is not wrong because markets are irrational. It's wrong because markets are complex adaptive systems. Rational agents interacting under imperfect information produce emergent dynamics that no individual agent intended or can predict.

The sandpile and the market

In 1987, Per Bak, Chao Tang, and Kurt Wiesenfeld dropped grains of sand onto a table, one at a time, and measured the resulting avalanches. Most grains did nothing. Occasionally, a single grain triggered a cascade that reshaped the entire pile. The size distribution of avalanches followed a power law — no characteristic scale, no "typical" event, no upper bound.

This is self-organized criticality: complex systems naturally evolve toward a critical state where extreme events are not anomalies. They are the natural output. The system doesn't need a big cause to produce a big effect. A grain of sand can trigger an avalanche. A marginal liquidity withdrawal can trigger a flash crash. The mechanism is the same.

5-sigma events are not once-in-a-lifetime flukes. They are the sandpile doing what sandpiles do. Gaussian Value at Risk is a calculation that assumes the system is a different kind of system than it actually is.

Markets are dynamical systems with feedback

Prices are not independent draws from a distribution. They are the output of a coupled, non-linear, feedback-driven process. Buyers and sellers observe prices, update beliefs, place orders, change prices, which causes other participants to update beliefs and place different orders. The output at time t becomes an input at t+1.

In linear systems, feedback is well-behaved. In non-linear systems, feedback produces regimes, bifurcations, and chaos. Markets are non-linear systems with feedback.

The properties that matter:

• State dependence. A stock at $100 in a calm trend has a different future than the same stock at $100 after a 20% drawdown. Same price, different state, different distribution. Linear models can't tell the difference.
• Phase transitions. Markets don't drift between regimes — they reorganize. The shift from bull trend to liquidation cascade is sudden, discontinuous, and preceded by specific signals: rising correlation, thinning liquidity, increasing skew. The math that describes water freezing describes a market crash.
• Emergence. No trader intends to produce a bubble. Bubbles emerge from thousands of individually rational decisions. The macro pattern is real. It has no author. You cannot understand it by interviewing participants.
• Adaptation. When enough traders adopt a strategy, the strategy changes the market in a way that reduces the strategy's edge. Alpha decay is co-evolution: predator and prey evolve together. What worked yesterday stops working not because it was wrong, but because it was right enough to change the environment.
• Non-ergodicity. The time average of a strategy is not its ensemble average. A strategy with positive expected return can ruin you if you don't survive the drawdowns. In a complex adaptive system, the path you take determines the distribution you sample.

What this means for your trading

The implications are not academic. They change what you build:

Regime detection is the most important problem. Knowing which attractor basin you're in — and detecting the signals of a phase transition — beats predicting the next tick. A mediocre signal in the right regime beats a great signal in the wrong one.

Linear models are components, not systems. PCA, Kalman filters, regression — they have their place. But they belong inside a non-linear wrapper that tells you which regime you're in. The linear model describes what happens inside the regime. The wrapper tells you when the regime changes.

Abandon Gaussian VaR. Use extreme value theory. Model tails with generalized Pareto distributions. Stress-test against power-law cascades, not historical scenarios. The next crash will not look like the last one. It will look like a phase transition.

Treat alpha decay as a dynamical system. It's not erosion. It's a predator-prey model with equilibria, cycles, and extinction regimes. Model it like one.

Backtests are single draws from a non-stationary process. The market of 2018 is not the market of 2026. The participants changed. The attractor basins shifted. A backtest is evidence, not proof.

Quantitative finance borrowed its toolkit from 19th-century physics because those tools produce closed-form solutions, not because they describe markets. Complexity science offers a more accurate description at the cost of fewer closed forms and more simulation. The cost is worth paying.

Markets are not physical systems with fixed laws. They are complex adaptive systems with emergent dynamics. If your trading system doesn't account for this, you are not modeling markets. You are modeling a textbook.

Where to learn this

EACH-USP (University of São Paulo) offers a graduate program in Complex Systems Modeling that covers exactly this ground: dynamical systems, agent-based modeling, network theory, and applications to finance. If you trade systematically and want the mathematical foundations this post argues for, it's worth a look.

References:

• Mandelbrot, B. & Hudson, R. (2004). The (Mis)Behavior of Markets: A Fractal View of Financial Turbulence. — The foundational argument that financial markets follow fractal geometry and power laws, not Gaussian random walks.
• Bak, P., Tang, C. & Wiesenfeld, K. (1987). "Self-Organized Criticality: An Explanation of 1/f Noise." Physical Review Letters. — The sandpile model: how complex systems self-organize into critical states where avalanches of any size are the natural output.
• Arthur, W. B. (2014). Complexity and the Economy. — The Santa Fe Institute economist on markets as complex adaptive systems: emergence, non-equilibrium, and why rational agents don't produce equilibrium.
• Peters, O. (2019). "The Ergodiity Problem in Economics." Nature Physics. — Why the time average and ensemble average are not the same, and why that matters for every risk model ever built.
• Taleb, N. N. (2007). The Black Swan: The Impact of the Highly Improbable. — The practical consequences of assuming Gaussian distributions in a fat-tailed world.
• Hamilton, J. D. (1989). "A New Approach to the Economic Analysis of Nonstationary Time Series and the Business Cycle." Econometrica. — The Markov-switching model that introduced formal regime detection to economics.
• EACH-USP. Modelagem de Sistemas Complexos — Graduate program in Complex Systems Modeling at the University of São Paulo.

Databases used to be black boxes. You wrote a query, waited, and hoped the optimizer did something reasonable. When it didn't, you tried a different index and hoped again. The expertise was real but the method was folk — passed from senior to junior as rules of thumb: "always index foreign keys," "avoid SELECT *," "EXPLAIN will tell you what's wrong."

That era ended when database teams started treating query performance as a measurement problem. Instrument the optimizer. Collect query plans. Compare actual vs. estimated row counts. Build dashboards. The output of all that instrumentation is a design loop: you don't guess why a query is slow. You look at the data. The data tells you.

We are at the beginning of the same transition for software engineering agents. Right now, most agent design is folk expertise: "be specific in your prompts," "few-shot examples help," "chain-of-thought improves reasoning." These are all true, sometimes, for some models, on some tasks. The problem is that nobody knows which ones.

The defining quality of an LLM is that it is stochastic. Given the same input, you get different outputs. Given slightly different inputs, you get very different outputs. The only way to reason about a stochastic system at scale is with data.

Why intuition fails

Your intuition about what makes a good agent prompt is shaped by a few dozen interactions. You try a prompt, it works, you generalize. You try another, it fails, you adjust. This is the scientific method at N=1 — useful for generating hypotheses, useless for drawing conclusions.

The problem compounds because agents are not just stochastic — they are stateful, tool-using, multi-turn stochastic systems. An agent that picks the wrong tool on step 2 fails on step 7 in a way that looks unrelated to the original mistake. Intuition attributes the failure to the step-7 behavior. The data would tell you to fix step 2.

Debugging agents by reading transcripts is like debugging a database by reading query text. You might spot the obvious problems. You will miss everything that matters at scale.

What data-driven design looks like for agents

The method is straightforward, even if the infrastructure isn't:

One: Instrument every decision. The agent chose a tool. Was it the right tool? The agent produced a diff. Did it compile? Did the tests pass? Did it introduce a vulnerability? The agent looped. How many iterations? When did it converge — or fail to? Every one of these is a data point. Collect them.

Two: Define success numerically, not narratively. "The agent handled the task well" is a narrative. "The agent solved 73% of tasks in the benchmark, with a median of 4 tool calls per task and a 6% hallucinated-tool-call rate" is data. Narratives are for demos. Data is for design.

Three: Compare at scale. You changed the prompt. Did the solve rate go up? By how much? Across how many tasks? With what variance? A single run of a stochastic system is a data point. A thousand runs is a distribution. Design decisions should be made on distributions, not data points.

Four: Close the loop. The best agent systems — like the best database administrators — don't make one-off optimizations. They build pipelines. Deploy. Observe. Compare. Improve. Deploy again. The loop is the design process. Speed of iteration matters more than brilliance of a single change.

The harness is your measurement instrument

A theme that runs through this blog is that the harness is the most under-invested part of an agent system. Data-driven design makes it concrete why: the harness is your measurement instrument. If your harness can't produce reliable, comparable metrics at scale, you cannot do data-driven design. You are back to intuition and anecdotes.

A harness that can only tell you "pass" or "fail" is a thermometer with one marking. You need to know what happened, where it went wrong, and whether this run was better than the last run in a way that generalizes.

The harness engineering practices that matter for data-driven design:

• Deterministic replay — if you can't reproduce a run, you can't measure a change.
• Layered observability — prompt selection, tool choice, state transitions, final outcome. Each layer produces its own metrics.
• Statistical rigor — a 2% improvement on 10 tasks is noise. A 2% improvement on 1,000 tasks might be real. The harness needs to support sample sizes that make signals distinguishable from noise.

Why this matters more for agents than for any previous software

Traditional software is deterministic. You change the code, you run the tests, you observe a binary outcome. The design loop is: implement, test, fix, repeat. Data helps, but the feedback signal is strong enough that intuition often suffices.

Agents are fundamentally different. The same agent, on the same task, with the same prompt, will produce different results on different runs. The space of possible behaviors is too large to explore by reasoning alone. The only way to understand an agent is to observe it across many runs and let the patterns emerge from the data.

This is uncomfortable. It means admitting that you cannot fully understand the system you are building by reading the code and the prompts. It means ceding authority to measurement. It means designing experiments instead of designing solutions — because the solution emerges from the experimental data, not from your head.

The transition from folk expertise to data-driven design is the transition from craftsmanship to engineering. Both produce good outcomes. Only one scales.

The cost of not doing it

The alternative to data-driven design is design by anecdote. Someone runs the agent on a task they care about. It works. They ship. Someone else runs it on a different task. It fails. Nobody knows why. The team debates prompts instead of looking at data. Decisions are made by the most senior person in the room, not by the person with the best evidence.

This is how most teams work today. It is also how most teams will fail at building agents, because the complexity of stochastic, tool-using, multi-turn systems exceeds what any individual's intuition can model.

Data-driven design is not about having data. It's about making decisions as if the data matters more than your opinion.

Databases went through this transition. So did compilers. So did networking. Every infrastructure layer that we now treat as predictable, measurable, and engineer-able went through a phase where the experts relied on intuition and the results were inconsistent. Agents are in that phase now. The teams that instrument, measure, and close the loop will build infrastructure. The teams that rely on folk wisdom and anecdote will build demos that don't survive contact with real workloads.

References:

• Selinger, P. G. et al. (1979). "Access Path Selection in a Relational Database Management System." ACM SIGMOD. — The paper that made query optimization a measurement problem: cost-based plan selection using catalog statistics instead of heuristics. The origin of EXPLAIN.
• Kohavi, R., Tang, D. & Xu, Y. (2020). Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. — The modern methodology for data-driven design decisions at scale, from the team that built Microsoft and Google's experimentation platforms.
• Sigelman, B. H. et al. (2010). "Dapper, a Large-Scale Distributed Systems Tracing Infrastructure." Google Technical Report. — The paper that established distributed tracing as a measurement primitive, now industry standard (OpenTelemetry).
• Kleppmann, M. (2017). Designing Data-Intensive Applications. — Chapters on observability, metrics, and the shift from intuition to measurement in distributed systems design.
• Related: Harness Engineering: Best Practices for Reliable Agent Systems — This blog's framework for building evaluation harnesses that produce the reliable, comparable metrics data-driven design requires.
• Related: Correctness First: What OpenBSD Teaches Agent Builders — The argument that correctness can't be eyeballed — it must be verified systematically, which requires measurement.
• Related: In the Land of AI Agents, the Verifiers Are King — Sonar's AC/DC framework as a productization of the same principle: verification infrastructure is the measurement layer for agent quality.

At the AI Engineer World's Fair in July 2026, Sonar CEO Tariq Shaukat gave a talk with a title that could serve as the thesis for this entire blog: "In the Land of AI Agents, the Verifiers Are King."

The argument is simple and devastating. AI coding agents deliver an initial 3-5x velocity boost. Within three months, that gain begins to evaporate. Security vulnerabilities accumulate. Bugs multiply. Code complexity rises. Technical debt compounds at machine speed. The boost was real, but the rot was faster.

The productivity paradox of AI agents: they make you faster in week one and slower in month three, because every line they wrote is a line nobody reviewed.

Shaukat's answer is a framework Sonar calls the Agent-Centric Development Cycle, or AC/DC — Guide, Verify, Solve. Three stages, each producing feedback that feeds the others, forming a continuous loop around every AI-assisted code change. The framework is partly a product pitch for Sonar's tooling. It is also, independent of the product, the right way to think about building software with agents.

Guide: context before code

The Guide phase gives agents information they wouldn't otherwise have — coding standards, architectural constraints, dependency health, semantic navigation of the existing codebase.

This sounds like prompt engineering. It's not. It's preemptive verification. Before the agent writes a line, the system has already said: these are the rules, this is the architecture, these dependencies are approved, this is how the code is structured. The agent can't violate constraints it doesn't know about. Most violations in agent-generated code aren't malice or even incompetence — they're ignorance. Guide eliminates the ignorance.

Sonar claims a 30% reduction in token consumption from context augmentation alone. The agent writes less code that needs rewriting, because it knows what correct looks like before it starts.

Verify: trust nothing, check everything

This is the center of the framework and the center of Shaukat's argument. Verification must be zero-trust — no model is inherently trustworthy, and every model has different biases and blind spots. Verification must be multi-layered — combining algorithmic analysis (data flows, control flows, known vulnerability patterns, secrets detection) with agentic analysis (intent, business logic, the "unknown unknowns" that rules-based tools miss).

The algorithmic layer catches the deterministic problems: this data flow leaks sensitive information, this control path doesn't handle the error case, this pattern matches a known CVE. The agentic layer catches the semantic problems: this function doesn't do what the comment says it does, this PR changes behavior the ticket didn't ask for, this logic contradicts the architectural decision made last sprint.

Neither layer alone is sufficient. Algorithmic verification misses context. Agentic verification hallucinates. Together, they catch what each misses.

The results Sonar cites are significant: a 44% reduction in AI-derived production outages among organizations with disciplined verification, and up to a 92% reduction in AI-induced issues at large financial institutions. One project timeline went from 10 days to 4 days — not by generating faster, but by generating fewer things that needed fixing.

Solve: fix it, then verify the fix

The Solve phase addresses what verification finds — automatically. A remediation agent generates fix suggestions in an isolated sandbox. The fix is re-analyzed. If it passes, it merges. If it doesn't, it loops back.

This closes the cycle. Guide gave the agent context to write correct code. Verify caught what slipped through. Solve fixed it and fed back into verification. The next Guide phase has better information because the system now knows what kinds of mistakes the agent tends to make on this codebase.

The three loops

What makes AC/DC more than a marketing diagram is that it operates across three nested timescales:

• The agentic loop (inner): context → generation → analysis → refinement → re-analysis. Runs in real time, inside the agent's workflow, before anything reaches a human.
• The CI verification loop (middle): multi-layered PR review combining algorithmic and agentic analysis with inline comments, change summaries, and architecture walkthroughs.
• The code maintenance loop (outer): quality gates, technical debt management, and continuous remediation across the entire codebase. Keeps the codebase clean so agents operate efficiently on future changes.

The inner loop catches mistakes in seconds. The middle loop catches them in minutes. The outer loop prevents them from becoming systemic.

Why this matters beyond Sonar

AC/DC is a Sonar product framework, but the underlying idea is independent of any vendor. It's a recognition that the software development lifecycle needs to be redesigned around the agent, not the other way around.

The traditional SDLC assumes a human writes the code, a human reviews the code, and a human fixes the bugs. The agent-era SDLC assumes an agent writes the code, a verifier checks the code, and a remediation agent fixes the issues — all before a human sees it. The human's role shifts from author to governor. The human sets the constraints, defines the quality gates, and intervenes when the automated loop can't resolve something.

This is not a downgrade of the human role. It's an upgrade. It replaces "did I write this correctly?" with "is my verification infrastructure catching what matters?" The first question doesn't scale. The second one does.

The connection to harness engineering

If you've been following this blog's thread on harness engineering, you'll recognize AC/DC as a harness architecture in product form. The Guide phase is feedforward. The Verify phase is feedback. The Solve phase closes the loop. The three nested timescales map directly to the layered checks I've argued for: tool-selection, state-transition, and final-outcome evaluation.

Sonar didn't invent the idea that verification is central to agent development. They productized it, named it, and backed it with numbers. The underlying principle — that the verifier matters more than the generator — is something every agent team discovers the hard way if they don't learn it the easy way.

The numbers tell the story: without verification, 3-5x initial gains that rot. With verification, 44% fewer outages, 92% fewer issues, faster net delivery. The gap isn't about model quality. It's about whether verification is a first-class part of your development process or an afterthought.

Shaukat's title was right. In the land of AI agents, the verifiers are king. Build your verification infrastructure accordingly.

References:

• Sonar. Agent-Centric Development Cycle — Official documentation for the AC/DC framework: Guide, Verify, Solve.
• Shaukat, T. (2026). "In the Land of AI Agents, the Verifiers Are King" — Keynote at AI Engineer World's Fair, San Francisco, July 2026.
• Sonar. (2026). "Sonar Introduces the Agent Centric Development Cycle." — Press release announcing the AC/DC framework and the productivity paradox findings.
• Sonar. (2026). "Sonar Launches Sonar Vortex and SonarQube Remediation Agent." — Product launch details for the context augmentation and remediation components.
• Sonar. (2026). "Sonar Named a Leader in the 2026 Gartner Magic Quadrant for Technical Debt Management Tools." — Gartner recognition and market context.
• Sonar Summit 2026. "Top 6 Takeaways on the Future of Coding." Security Boulevard. — Industry coverage of the verification-centric strategy.
• Related: Harness Engineering: Best Practices for Reliable Agent Systems — This blog's framework for evaluation harnesses that do the verification work AC/DC requires.

The cloud won. For two decades, the answer to "where should compute happen?" was "ship the data to us." Centralize. Aggregate. Process. The result: petabytes of data flowing into a handful of regions, owned by a handful of companies, governed by laws that don't match the topology.

The cloud won, but the cloud model is breaking. Not technically — the hyperscalers work fine. But legally, economically, and architecturally, the assumption that data should move to compute is no longer true.

GDPR requires data residency. The EU AI Act layers new constraints. Countries from Brazil to India to Indonesia are writing sovereignty into law. The pipe dream of "store everything in us-east-1" is dead. The cloud didn't account for borders.

This is where Bacalhau enters. Not as a replacement for the cloud. As an inversion of its founding assumption.

What Bacalhau does

Bacalhau is an open-source distributed compute orchestrator. The idea is simple: instead of moving data across the network to a central compute cluster, you send a small job description — a Docker container, a Wasm binary, a shell script — to wherever the data already lives. The job runs next to the data. Only the results come back.

Compute travels. Data stays. That's the whole architecture.

It's released under Apache 2.0, built by Expanso, a company founded in 2023 by David Aronchick — previously co-founder of Kubeflow at Google, head of open-source ML strategy at Microsoft Azure. The project won the Data Breakthrough Award in 2024, raised $7.5M in seed funding led by General Catalyst, and landed a strategic investment from Samsung Next. It's available on the Google Cloud Marketplace. It's a single Go binary — no cluster to bootstrap, no control plane to subscribe to.

The architecture is an orchestrator-compute model. You label nodes by region (region=eu, region=us). You submit a job with constraints. The orchestrator routes work to nodes near the data. Jobs are parallel by default — split into partitions that run independently, with isolated failure handling. If a partition fails, it retries. If the network between the orchestrator and a compute node drops, the node keeps working.

The name matters

Bacalhau is Portuguese for dried salted cod. Before refrigeration, cod was preserved by salting and drying — it could travel long distances without spoiling, sustaining entire maritime economies for centuries. The metaphor is deliberate: preserve the data where it originates. Compute can travel. Data doesn't need to.

This matters because data is heavy and data is governed. Moving a petabyte of logs to a central warehouse is expensive. Moving genomic data across national borders is illegal in an increasing number of jurisdictions. Moving medical records, financial transactions, or personally identifiable information into a third-party cloud triggers compliance obligations that most teams underestimate until an auditor shows up.

Bacalhau's answer: don't move it. Send the analysis to the data.

How it actually works

A Bacalhau deployment runs a single binary in different modes: orchestrator nodes manage job lifecycles, compute nodes execute workloads. Both can be the same machine. At the edge, a compute node might be a Raspberry Pi on a factory floor. In the cloud, it might be a VM in a specific AWS region.

Jobs are submitted declaratively or via CLI. They target data in S3, IPFS, HTTP endpoints, or local storage. The orchestrator schedules work based on node labels — region=eu, gpu=true, tier=production. The workload runs inside a Docker container or a Wasm sandbox. Output lands wherever you configure: local disk, S3 bucket, the next pipeline stage.

A partitioned job splits across N nodes. Each partition gets an index, a count, and its own slice of the data. Failures are per-partition, not per-job. A node in Frankfurt might process EU customer records while a node in São Paulo processes Brazilian records and a node in Mumbai handles Indian data — all from the same job submission, with constraints that ensure compliance.

The Genomic Data Proof Point

A 2025 academic study tested Bacalhau with IPFS Cluster and AES-256 encryption for decentralized genomic computation. The distributed architecture achieved 100% job completion under network chaos — nodes disconnecting, links dropping, partitions reforming. The centralized baseline fell apart under the same conditions.

Under ideal network conditions, the distributed setup added about 30% overhead (49 seconds vs. 37 seconds). That 12-second difference is the price of sovereignty. In the centralized case, you also move the data first — a cost the study's baseline conveniently excluded.

The paper's conclusion: a proven model for privacy-critical decentralized science collaborations, prioritizing data sovereignty and high availability over raw throughput. Twelve seconds to keep genomic data inside hospital walls.

Why the agent era needs this

Software engineering agents generate code. That's the story everyone tells. The less-told story is where they run.

An agent debugging a production issue needs access to logs. Those logs live in a specific region, governed by specific laws. An agent analyzing customer behavior needs to read data that cannot legally leave the country. An agent optimizing a factory floor needs to process sensor data at millisecond latency — waiting for a round-trip to the cloud is not an option.

The default architecture for agent platforms today is: ship everything to a central LLM provider. Your code, your logs, your database schema, your customer PII — all of it crosses the wire to a model endpoint in a jurisdiction you didn't choose.

Bacalhau suggests a different architecture: ship the agent to the data. Run the model where the data lives. The agent is a job. The data is stationary. The compliance boundary is the node label, not a legal review of every prompt.

The broader lesson

Data sovereignty sounds like a legal problem. It becomes an architectural problem the moment you try to build a real system. If your architecture requires data to move to a central location before anything useful can happen, you have already lost the sovereignty argument — all that remains is how many exceptions you'll need and how much the fines will cost.

The alternative is compute over data. It's not a new idea. MapReduce did it. Edge computing does it. Bacalhau makes it general — any workload, any data source, any execution engine, one binary, open source.

The cloud taught us to centralize. The law is teaching us to distribute. Bacalhau is infrastructure for that transition.

It's not that central compute will disappear. It's that centralization stops being the default. When data must stay where it is, the architecture follows. Compute travels. Data stays. That inversion is the foundation of sovereignty — and the infrastructure the next decade of software will be built on.

In 1991, Linus Torvalds wanted a Unix-like system for his 386. BSD Net/2 had been released, but he didn't know about it. He wrote his own kernel. The next year, AT&T sued BSDi, alleging BSD contained proprietary Unix code. BSD development froze for two years. Linux, written from scratch with no legal baggage, absorbed the energy. By the time the lawsuit settled in 1994, Linux had won.

Linus later said: "If 386BSD had been available when I started on Linux, Linux would probably never have happened."

The world runs on Linux not because it was better designed, but because it was available. The cathedral lost to the bazaar by accident.

Two architectures, two theories of quality

BSD is an operating system. One source tree. One team. The kernel, libc, core utilities, daemons, manual pages — written, reviewed, and shipped by the same people. When a kernel interface changes, every userland tool that depends on it is updated in the same commit. Configuration syntax is consistent because the same hands that wrote the daemon wrote its parser.

Linux is a kernel assembled into an operating system by distributions. The kernel comes from Linus. The C library from GNU. Userspace from a hundred independent projects. Each has its own maintainers, release schedule, coding style, and idea of what "good" means. The distribution's job is integration, not design. The result works. It is not clean. Everyone who has debugged a Linux system at 3am knows the feeling of crossing a component boundary and discovering the assumptions changed.

Linux is dirty in the way a city is dirty — it works, it's full of life, but nobody designed it from scratch. BSD is clean in the way a well-designed building is clean — the structure is visible, the materials are consistent, the wiring is labeled.

OpenBSD: correctness as the only feature

If BSD represents the cathedral, OpenBSD is the cathedral with the strictest building code. Theo de Raadt forked it from NetBSD in 1995 with an uncompromising thesis: correctness over features, every time.

"We are non-stop trying to find ways across our entire source tree that small little programmer errors result in problems. At some point, we have to start asking ourselves whether features are the thing, or whether quality is the issue." — Theo de Raadt

The project has audited its entire source tree — millions of lines — line by line. Multiple times. Not primarily with tools. With humans reading code, asking "what happens when this fails?" The result: an operating system with only two remote holes in the default install across nearly three decades.

This is not a security achievement. It is a correctness achievement that makes security possible.

OpenBSD's innovations read like a list of things every other OS later adopted: W^X memory (2003, now universal), pledge(2) (process-level system call restrictions), unveil(2) (filesystem sandboxing), LibreSSL (forked OpenSSL, removed half the code, broke nothing). Each was born from asking: how do we make the wrong thing impossible, not just harder?

Most projects respond to security by adding layers — a firewall, a sandbox, a scanner. OpenBSD responds by removing the bug. The difference is the difference between a house with a reinforced door and a house with no structural flaws.

The collision with the agent era

We are now deploying software that writes software — agents that generate, edit, and ship code at scale. These agents do not understand correctness. They produce tokens statistically likely to satisfy a prompt. They don't know that this return value needs checking, that this buffer needs bounds, that this error path leaks a descriptor. They pattern-match from training data that, statistically, also doesn't know these things.

Generated code is code nobody has read. Tests cover what you thought to test. Vulnerabilities live in what you didn't think of.

The agent era promises speed. OpenBSD proves that correctness at speed is an oxymoron. Shipping code faster than anyone can review it is not automation — it's an attack surface factory.

The resolution is not to reject agents. It is to demand of agent output what OpenBSD demands of human output: adversarial review, minimal diffs, restricted capabilities, and a culture that refuses to ship code that hasn't been read.

What agent builders should steal

Audit the diff, not the demo. OpenBSD doesn't audit the running kernel. It audits the source. Evaluate what the agent changed, not just whether tests pass. The diff is where bugs live.

Restrict by default. OpenBSD ships with almost nothing running. Agent platforms should ship with almost no capabilities. Every new tool is attack surface — for bugs, prompt injection, unintended behavior. An agent that can rewrite any file has maximum blast radius. An agent restricted to specific files and specific side effects can fail without destroying things.

The harness is your code review. The agent has no concept of correctness. The harness has to. If your evaluation scores "did it compile?" and "did the test pass?" and "did the reviewer LLM nod?" — you are not asking enough. Write criteria as specific as an OpenBSD code review: "this error must propagate," "this resource must be freed."

Remove generated code aggressively. A 500-line generated function that works is worse than a 30-line one that works. Every line the agent wrote is a line someone needs to read. Prefer agents that produce minimal diffs.

Culture scales. Checklists don't. OpenBSD's real innovation is cultural: correctness is everyone's job, speed is never an excuse, shipped bugs are taken personally. Agent teams need the same culture. If your team treats agent output as "good enough if the tests pass," you will ship vulnerabilities at agent speed — faster than anyone can review.

OpenBSD has been building secure software for over two decades with a team that fits in a single room. They do it by being slower, more careful, and more uncompromising than almost any other project.

Reliability was always the prerequisite for security. OpenBSD proved it with decades of results.

The agent era will prove it again — either by adopting that lesson, or by suffering what happens when you don't.

Kaggle launched in 2010 as a platform for data science competitions. Fifteen years later, it has accidentally built exactly the infrastructure the AI agent era needs.

Most people think of Kaggle as "the place with the Titanic dataset." That's like thinking of GitHub as "the place with the Hello World repos." Kaggle is a competition infrastructure for measuring capability at scale — and measuring capability at scale is the hardest unsolved problem in AI agents.

The leaderboard is the product

Every Kaggle competition has a public leaderboard. Submit a solution. Get a score. See where you rank. The leaderboard updates in real time. Overfitting gets punished when the private leaderboard reveals the final standings.

This is exactly the infrastructure that agent evaluation lacks.

Agent benchmarks today — SWE-bench, WebArena, ToolBench — are static snapshots. You run your agent against them, get a number, write a paper. There's no ongoing competition. No leaderboard that updates as new agents submit. No mechanism for detecting overfitting to the benchmark. The evaluation infrastructure for agents is where Kaggle was in 2009: ad-hoc, one-shot, and gamed within months of release.

Kaggle solved the benchmark-gaming problem with public/private leaderboard splits and temporal holdout. Agent evaluation is currently rediscovering these problems from scratch. The solutions exist. They're just on a different platform.

The competition format is the training loop

A Kaggle competition is not a one-shot test. It's a feedback loop. Submit. Get scored. Iterate. Resubmit. The best competitors submit hundreds of times, each submission informed by the previous score. Over weeks or months, the leaderboard converges toward the frontier of what's possible for that task.

This is exactly the closed-loop training dynamic that makes AI agents improve. The AWS paper showed a 350M model fine-tuned on ToolBench trajectories. Each successful trajectory becomes training data for the next round. The Kaggle competition format has been running this loop for 15 years — not with model weights, but with human modelers. The dynamic is the same: score, learn, improve, resubmit.

The winning Kaggle solution is never the first submission. It's the 200th submission, after 199 feedback loops. Agents improve the same way. Kaggle understood the loop before anyone called it "closed-loop training."

The community is the collective brain

Kaggle's most underrated asset is its community of practitioners who have spent 15 years learning how to measure and improve performance systematically. These are people who understand overfitting, data leakage, evaluation validity, and the difference between a model that works in the notebook and a model that works in production.

The AI agent era needs exactly this skillset. Building an agent that solves SWE-bench tasks is a Kaggle competition in miniature: understand the evaluation metric, iterate on the pipeline, ensemble weak solutions into stronger ones, watch for overfitting, validate on held-out data. The Kaggle community has been doing this for a decade and a half. The agent community is figuring it out as it goes.

The agent era will produce a Cambrian explosion of benchmarks. The people who already know how to compete on benchmarks — how to read a metric, how to prevent leakage, how to ensemble — will have an asymmetric advantage. Most of those people are on Kaggle.

The datasets are the training data

Kaggle hosts thousands of curated, documented datasets with clear evaluation criteria. Agents need training data. Kaggle has it, organized by domain, with baseline models and discussion threads explaining what works.

More importantly, Kaggle datasets come with ground truth. The labels exist. The evaluation metric is defined. You know what "good" looks like. This is the hard part of agent training — not generating data, but generating data where you can measure whether the output is correct. Kaggle solved the ground-truth problem for structured tasks.

What Kaggle should build next

Kaggle is positioned to become the evaluation layer for the agent ecosystem. What it would take:

1. Agent-specific competitions: tasks designed for autonomous agents with tool access, not just model predictions. "Solve this set of data engineering problems" with a deadline and a budget.

2. Streaming leaderboards for agent benchmarks: host SWE-bench, WebArena, and ToolBench as ongoing competitions with public/private splits, not one-shot evaluations.

3. Closed-loop agent training infrastructure: let agents submit, get scored, and use the score to improve — the Kaggle competition loop, automated.

Kaggle has the leaderboard infrastructure, the community, the datasets, and the evaluation culture. What it doesn't have yet is the recognition that it built the agent era's missing piece. The platform that figures out how to turn every agent benchmark into a Kaggle competition wins the evaluation layer. Kaggle already has the pieces.

Ray and I are part of a small group interested in verified coding agents. He has a habit of tracking down the reference behind the reference. Last week his post Zig Creator Calls Spade a Spade, Anthropic Blows Smoke hit the top of Hacker News. 1,546 points. 784 comments. It stayed there.

The controversy

Anthropic's Claude helped Bun rewrite itself from Zig to Rust — presented as a technical decision driven by memory safety. Andrew Kelley, Zig's creator, pointed out the codebase was a mess due to engineering decisions, including overusing AI agents. Zig was blamed for problems it didn't cause.

AI is not enough

Ray's core insight: every element of the story that Bun and Anthropic present as evidence that AI replaces engineers actually demonstrates the opposite.

The million-line agentic PR? Required human review and cleanup the AI couldn't do. The automated language migration? Left semantic gaps only a human could close. The speed of the rewrite? Achieved by a team working 90-hour weeks, not by AI magic. The case study Anthropic chose to prove software engineering is becoming obsolete is contradicted by every layer of its own story.

The thesis isn't "AI is bad." It's "AI is not enough." The AI was a tool. The humans were the engineers. The story Anthropic needs to tell — to justify a $132 billion valuation — is disproven by the very evidence they selected.

The reference density

The post cites 38 references: DARPA TRACTOR evaluation reports, TigerBeetle's TigerStyle methodology, Buddhist right-speech frameworks, Ed Zitron's financial analysis, Hillel Wayne's empirical SE talk. Each is woven into the argument, not dropped for credibility. It's the kind of writing that takes a week to produce and a career of reading to make possible.

Go read it

Ray's post is about Zig and Rust and Anthropic and Bun. The lesson is about something bigger: how to think clearly when the loudest voices in the room have $132 billion worth of reasons to be heard.

Zig Creator Calls Spade a Spade, Anthropic Blows Smoke by Ray Myers. Hacker News discussion (1,546 points, 784 comments).

Part 1 argued that we know almost nothing. Part 2 covered what we do know. This post is about how to think — the methods, the habits, and the reading list for building a personal practice of empirical software engineering.

The three methods

Wayne organizes empirical SE into three research methodologies. Each answers a different kind of question. Each has different strengths and failure modes.

Controlled trials manipulate one variable and measure the outcome. Häregård & Kruger's study on syntax highlighting: give two groups the same code with different color schemes, measure comprehension. Strongest for establishing causation. Weakest for ecological validity — lab conditions are not production conditions. A developer reading code in a study is not a developer fixing a production outage at 3am.

Natural experiments exploit real-world variation that approximates random assignment. Yuan et al.'s study of catastrophic failures: the researchers didn't cause the failures. They analyzed them after the fact, asking what would have prevented each one. High ecological validity — these were real failures with real consequences. Lower control — you can't randomize which services fail in production.

Observational studies measure what people actually do and look for correlations. Meyer et al.'s study of developer productivity perceptions: ask developers what makes them feel productive, correlate with what they actually do. Reveals practices at scale. Cannot establish causation. Developers who use TDD might produce better code, or developers who produce better code might be the kind of developers who use TDD. The study can't tell you which.

The method determines the claim. A controlled trial can say "X causes Y." An observational study can only say "X and Y co-occur." Most industry blog posts can only say "I tried X and it felt good." Know which kind of claim you're reading.

How to read a study

Wayne's talk implies a method for reading empirical research that most software engineers never learned:

1. What's the methodology? Controlled trial, natural experiment, or observational? This determines what the study can claim.

2. What are the confounds? What else varies with the variable being studied? The Ray et al. language study: functional languages correlated with smaller projects and more experienced developers. Those are confounds. They explain the effect better than the language does.

3. Has it been replicated? A single study is a data point, not a conclusion. The replication is the signal. No replication, no confidence.

4. What's the effect size? Statistical significance is not practical significance. A language might "significantly" reduce defects by 0.3%. That's not worth switching languages for.

5. Who funded it? This isn't cynicism. It's basic epistemic hygiene. A study funded by a vendor is not necessarily wrong. But it deserves more scrutiny than an independent replication.

Most software engineers read zero studies. Most of the ones who read one study stop at step one. The skill is reading enough studies, across methodologies, with attention to confounds and replications, to form a tentative and revisable picture of what might be true.

The self-correction of science

The Ray et al. → Berger et al. replication saga is the centerpiece of Wayne's talk, and he uses it to make a point about how knowledge actually advances.

The original study found an effect. A replication found the effect was confounded. The original authors engaged with the replication. Knowledge advanced. This is science working as designed. In software engineering, the original study became "functional languages prevent bugs" and entered the permanent folklore. The replication was a paper that most people never read.

The replication is the immune system. Without it, the field accumulates unquestioned findings until the body of "knowledge" is mostly noise. Wayne's 6,000-word writeup of the saga is titled "This is How Science Happens." The subtitle is implicit: this is how science happens when it's allowed to.

The reading list

Wayne recommends four books and two ongoing sources:

Books:

• Making Software (Oram & Wilson) — a curated collection of empirical SE papers with practitioner-oriented summaries. The best entry point.
• Leprechauns of Software Engineering (Bossavit) — how folklore becomes fact in software, and how to spot it.
• The Programmer's Brain (Hermans) — what cognitive science tells us about reading, writing, and debugging code.
• Teaching Tech Together (Greg Wilson) — how people learn programming, based on educational research.

Ongoing:

• It Will Never Work In Theory — a blog that summarizes empirical SE papers for practitioners. Short, readable, rigorous.
• ACM Digital Library and arXiv — the primary sources, if you want to read the papers themselves.

The reading list is not long. It's not meant to be. The barrier to being more empirical than 99% of software engineers is reading four books and following one blog. The bar is on the floor.

The posture

Wayne's deepest lesson is not about any specific study. It's about intellectual posture.

The empirical posture is: I don't know, but I can find out, and until I do I will hold my beliefs lightly. It's the opposite of the posture that dominates software engineering — the tech lead who knows The Right Way, the consultant who sells The Methodology, the influencer who declares that The Old Way Is Dead.

The empirical posture is less charismatic. It doesn't keynote. It doesn't trend. It says "the evidence is mixed, the effect sizes are small, and it depends." That sentence will never go viral. It is also the most honest sentence available in most software engineering debates.

Being empirical doesn't mean reading every paper. It means knowing that papers exist. It means being suspicious of certainty. It means asking "how do we know that?" when someone declares a practice mandatory or obsolete. It means holding your own preferences lightly — liking TDD because it feels good while acknowledging the evidence is weak. It means being the person in the room who says "I'm not sure" and means it as a strength, not a weakness.

The goal is not to know everything. The goal is to know the difference between what you know and what you believe.

Based on Hillel Wayne's talk What We Know We Don't Know. Part 1: Nothing Is Real · Part 2: What the Studies Actually Say.