Agentic Engineering

Recent Updates

• 2026-08-04: Added Spotify's enterprise fleet management case study — Honk agent platform evolution, deterministic-ceiling-to-LLM transition, verification investment at scale, standardization-multiplies-agents thesis, 75% PR frequency lift, prototyping infrastructure — to Enterprise Fleet Management
• 2026-07-31: Added four-loop stacking hierarchy, evidence-over-confidence principle, and five anti-patterns to Three Engineering Layers
• 2026-07-30: Added agent factory architecture — two-neck certification model, five-station production line, sealed eval suites, permission broker, autonomy tiers (C0–C3), mid-run routing, self-staffing meta-agents — to Agent Factory Architecture
• 2026-07-29: Added goal-oriented prompting, checkpoint control, 80%-system-prompt-removal evidence, hallucination trade-off, and four-part prompt structure from Rahul's Opus 5 masterclass to Prompting Frontier Models for Agentic Work
• 2026-07-29: Added Anthropic's Opus 5 prompting patterns — effort-as-cost-lever, narration tuning, over-verification removal, subagent caps, thinking-disabled artifacts — to Prompting Frontier Models for Agentic Work
• 2026-07-26: Added Buzz voice huddles and per-agent persistent memory details to Other Orchestration Tools
• 2026-07-26: Added three-layer taxonomy (harness/loop/graph = environment/feedback/flow) with nesting model and failure-diagnosis framework to Three Engineering Layers
• 2026-07-26: Added Karpathy–Cherny context engineering framework — four operations (Write/Select/Compress/Isolate), Software 3.0, context rot, three-paradigm timeline — to Context Engineering: The Unifying Layer
• 2026-07-25: Added Dex's software factory failure thesis — lights-off factory experience, RL maintainability gap, benchmark blindness to code quality — to Why Software Factories Fail
• 2026-07-23: Added Machina's graph engineering principles — diamond pattern, stop rule, human gate, fake-edge audit — to Graph Engineering

The Delegation–Collaboration Split

AI work is bifurcating into two distinct interaction modes, each requiring different agent architectures:

• Collaboration — Real-time, synchronous work where a human and model co-create in the same loop. Desktop apps, inline code assistants, pair-programming sessions. The model sees your context and responds within seconds. The value is creative amplification — the human steers, the model accelerates.
• Delegation — Asynchronous handoff where teams assign work to long-running agents (Codex, Managed Agents, Gas City) and check back later. The agent owns the full execution loop. The value is throughput — one person dispatches many parallel workstreams.

The meta-skill is knowing which mode fits the task. The allocation economy thesis captured the delegation half, but missed that roughly half of AI-augmented work remains fundamentally collaborative — tasks where the human's judgment, taste, or real-time feedback is integral to the output, not just the brief source(https://every.to/context-window/the-dawn-of-codex-native-apps).

In practice, teams are running both modes simultaneously: collaborative agents for writing, design, and strategy; delegated agents for refactors, migrations, and batch operations. The organizational challenge is building intuition for which mode to reach for — and building infrastructure that supports both.

Vibe Coding vs. Agentic Engineering (Simon Willison)

Simon Willison draws a sharp line between two modes of AI-assisted development — then argues the line is already blurring.

Vibe coding is building without reading the code. You prompt, you check if the output works, you ship. If it breaks, you tell the model it broke and hope for the best. Willison's position: vibe coding is fine for personal tools where bugs only hurt you; it is "grossly irresponsible" for software that handles other people's data or trust.

Agentic engineering is a professional software engineer using AI tools to the full extent of their experience — understanding security, maintainability, operations, performance — and aiming to build higher quality software faster, not lower quality software faster. The 25-year practitioner's context, architecture taste, and security instincts become force multipliers rather than redundancies.

The blur: as models improve (Willison dates the tipping point to Claude Opus 4.5 / GPT 5.1, late 2025), even disciplined engineers stop reviewing every line. A JSON API endpoint backed by SQL, with generated tests and docs, is reliably correct. The question shifts from "did I review this?" to "do I trust this class of output?"

The team analogy. Willison resolves the trust question by analogy to large engineering organizations: you don't read every line of code written by another team's image-resize service — you read the docs, use it, and dig in only when something breaks. He treats agent output the same way: a semi-black box trusted until evidence suggests otherwise. The discomfort is that agents, unlike teams, carry no professional reputation and cannot be held accountable.

The security-adjacent line. Anything security-adjacent still gets human review. Knowing what is security-adjacent is itself a skill developed over years — one reason experienced engineers remain essential.

Usage over tests as trust signal. In a world where agents produce beautiful READMEs, 100 commits, and comprehensive test suites in thirty minutes, those artifacts no longer reliably signal quality. What does signal quality: someone has used the thing in production for weeks. "If you've got a vibe coded thing which you have used every day for the past two weeks, that's much more valuable to me than something that you've just spat out and you've hardly even exercised."

Parallel agents and interruptible work. When coding required holding an entire system in your head, interruptions were catastrophic. With agents handling the typing, Willison works on two or three projects simultaneously — prompting one agent, switching to another while the first churns for ten minutes. Harder projects parallelize better because each agent step takes longer, freeing more interstitial time. The deep-focus era is giving way to an interrupt-friendly dispatch model (see delegation–collaboration split above).

Design and product process implications. If building is cheap, the elaborate design phase that guards against "three months building the wrong thing" can afford more risk. Jenny Wen (Anthropic design lead) argues the design process should become riskier because the cost of getting it wrong has collapsed. The same logic applies to product management: specification rigor was justified by engineering cost. Spikes that once took two days of developer time now take an hour of agent time — and you can run ten in parallel.

The deterministic-core pattern. For production systems, Willison advocates investing deeply in a "perfect" database schema and robust API, then vibe-coding all UI on top. Customers get customization flexibility without risking the data model. The principle: push determinism into the core, let non-determinism live at the edges where the blast radius is small.

Why code became the breakthrough domain. Reinforcement learning needs clean reward signals. Code provides the cleanest: did the script pass its tests? Binary, instant, scalable to 10,000 parallel VMs. Anthropic and OpenAI spent 2025 on RL against simulated software environments. Labs that didn't (xAI, Gemini) fell 12 months behind. Willison expects Gemini to close the gap by end of 2026. The same RL approach is far harder to apply to law (six-month trial feedback loops) or medicine — making software engineering, ironically, the field most susceptible to AI-driven change.

Practitioner Principles (SysLS)

SysLS distills months of production agentic work into a minimalist philosophy: strip dependencies, control context, and iterate on rules and skills — nothing else.

Context is the bottleneck, not tooling. The single most important variable in agent performance is what's in the context window. Every plugin, memory system, and harness injects information the agent must process. When you ask for a hangman game and the context contains memory notes from 26 sessions ago plus plugin instructions for unrelated capabilities, the agent's attention is diluted. "You want to give your agents only the exact amount of information they need to do their tasks and nothing more."

Separate research from implementation. "Go build an auth system" forces the agent to research options and implement in the same context — filling the window with alternatives it won't use, increasing confusion and hallucination risk. Instead: run a research session to evaluate options and decide on an approach, then hand a fresh-context agent precise specs ("JWT authentication with bcrypt-12 password hashing, refresh token rotation with 7-day expiry"). The implementation agent never sees the alternatives it didn't choose.

Exploit sycophancy with adversarial patterns. Agents are trained to please, which means "find me a bug" will produce a bug — even a fabricated one. Two countermeasures:

• Neutral prompts: Instead of "find bugs in the database," say "follow the logic of each component and report all findings." This doesn't bias toward a predetermined outcome.
• Adversarial triangulation: Run a bug-finder agent (incentivized to find issues), an adversarial agent (incentivized to disprove them, penalized for false disprovals), and a referee agent (told you have ground truth and scored on accuracy). The bug-finder produces the superset of possible bugs; the adversary narrows to the subset of real bugs; the referee adjudicates. Each agent's sycophancy is channeled toward a different objective, producing "frighteningly high fidelity" results.

Define task completion with contracts. Agents know how to start tasks but not when to stop — leading to stubs declared as finished work. The fix: write a TASK_CONTRACT.md specifying tests that must pass, screenshots to verify, and other acceptance criteria. A stop-hook prevents session termination until the contract is fulfilled. For automation, create one contract per unit of work and spawn a fresh session per contract — this avoids the context bloat of long-running sessions while ensuring each task meets its acceptance criteria.

CLAUDE.md as a conditional directory. Treat the root instruction file not as a document to read but as a routing table: "if coding, read coding-rules.md; if tests are failing, read test-failing-rules.md." Rules can nest and branch arbitrarily. This keeps each agent session loading only the context relevant to its current scenario. Skills serve the same purpose but encode recipes (how to do something) rather than preferences (what not to do).

The consolidation cycle. As rules and skills accumulate, they start contradicting each other and bloating context — the same problem they were designed to solve. Periodically consolidate: have agents audit the rule set, surface contradictions, and merge redundant entries. Performance degrades, you clean up, "and it will feel like magic again. That's it. That's really the secret."

Let frontier companies do the R&D. Useful patterns (planning before implementation, skills, memory, subagents) get absorbed into base products. If something is genuinely valuable, the foundation companies — who are the heaviest users of their own tools — will ship it. "Just update your CLI tool of choice every once in awhile and read what new features have been added. That's MORE than sufficient."

Domain Knowledge as Infrastructure (Cherny)

Boris Cherny extends the CLAUDE.md-as-routing-table principle into a broader thesis: the best engineers have always spent their highest-leverage hours automating their own work — vim macros, lint rules, end-to-end test suites — and agents make this practice dramatically more important.

Three reasons automation matters more now:

• Fleet multiplication. Automation that speeds you up also speeds up every agent you run. If you have an army of agents, each inherits the same infrastructure improvements. More automation = more output per unit of time across the entire fleet.
• Permanent class elimination. An agent can fix an issue every time it encounters it, but that burns tokens and may miss cases. If the agent instead writes a lint rule, CI step, or routine, that entire class of issue is automated forever. This is what loops actually are — automating entire types of busywork rather than solving them one-off. Engineers have been doing this long before agents existed.
• Zero-context contribution. The most important shift: automation makes it possible for others to contribute to a codebase without the ramp-up period. Engineers are contributing to unfamiliar codebases on day one because agents navigate for them; non-engineers are contributing as effectively as engineers. What blocks both is domain knowledge that lives in people's heads rather than in infrastructure. With agents, the range of encodable domain knowledge has expanded beyond what lint rules, types, and tests can express — it now includes code comments, skills, CLAUDE.md rules, and memories. If a PR gets rejected because it doesn't use the right framework, or a feature gets rejected because it doesn't follow architectural patterns, those are failures of automation.

The mandate: every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to work productively in their codebase with zero additional context from the prompter. This is a natural extension of what engineers have always done — automate and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, the task becomes easier. The bottleneck is converting tacit domain knowledge to explicit infrastructure so that agents write better code, code review catches issues automatically, and the next person (or agent) working on the codebase can contribute without a ramp-up period.

Context Engineering: The Unifying Layer (Karpathy–Cherny)

Karpathy's Software 3.0 framework reframes the entire discipline: Software 1.0 is humans writing explicit code, Software 2.0 is humans training neural networks with data, and Software 3.0 is humans programming models through context. The context window is the new programming surface, and it is the layer that unifies the practitioner patterns already on this page — the SysLS principles are techniques for filling it well, domain knowledge as infrastructure is persisting context across a team, and loop engineering is automating the whole discipline on repeat. Everything reduces to four operations (Write, Select, Compress, Isolate); skipping them produces context rot, the mechanism behind the consolidation cycle (rules and skills contradicting each other) and the orchestration tax (cognitive overload from parallel agent output). Context engineering is the foundation that all three engineering layers depend on.

Full treatment — the four Write/Select/Compress/Isolate operations, the LLM-as-CPU / context-as-RAM analogy, context rot, the prompt → context → loop timeline, and context engineering vs RAG — lives on the canonical Context Engineering page.

Three Engineering Layers: Environment → Feedback → Flow

The three disciplines that keep appearing across this page — harness, loop, and graph engineering — are often conflated because all three sit around the same model and all three can contain "loops." But they describe different engineering decisions, and the distinction matters once an agent leaves a demo notebook and starts touching production systems.

The clean mental model:

• Harness engineering (environment) — builds the machinery around the model: context injection, tool definitions, memory, sandboxes, permissions, observability. Remove the model from your architecture diagram; everything left is the harness.
• Loop engineering (feedback) — designs the repeated work-and-feedback cycle: what triggers another iteration, what evidence proves success, what feedback is returned on failure, and what stops the cycle. A prompt tells the model what to do during a call; a loop specifies what the system does after the call.
• Graph engineering (flow) — makes the workflow topology explicit: which component runs next, what branches on what condition, where work fans out in parallel, and where it must join before proceeding. The state traverses the graph; the topology enforces the control flow.

Nesting, not alternatives. The three layers nest: the graph runs inside the harness; one or more loops live inside the graph; and the harness supplies the state, tools, and evaluators those loops need. A beautifully drawn graph is insufficient if the harness has lost its state. A well-equipped harness wastes money if its loops have no evidence or stopping rule. Carefully crafted loops are still hard to operate when branching, parallelism, and approvals are buried in ad-hoc code. The categories overlap because software layers overlap, but each gives the team a different lever to pull when the system fails source(https://x.com/beamnxw/status/2081022966645535079/?rw_tt_thread=True).

Loops stack. The agent loop performs the work; the verification loop checks it; an event loop wakes the system when new work arrives; an improvement loop studies production traces and changes the harness itself. Each layer sits around the one below it. A prompt defines what should happen during one model call; a loop defines what the system does after that call — which is why loop engineering is larger than prompt engineering source(https://x.com/0xwhrrari/status/2082096897964306572/?rw_tt_thread=True).

Loop on evidence, not confidence. "The agent says it is finished" is not proof; "the tests pass, the sources resolve, and the reviewer approved the diff" is proof. The check may be deterministic (tests pass, schema validates, files compile) or require a reviewer (argument is complete, tone matches the audience, evidence supports the conclusion). The rule is the same: do not loop on self-reported confidence — loop on externally verifiable evidence source(https://x.com/0xwhrrari/status/2082096897964306572/?rw_tt_thread=True).

Five expensive mistakes. (1) Building the graph too early — do not formalize forty nodes from an imagined process before watching a strong agent perform the work; trace first, formalize second. (2) Letting the maker grade itself — self-review shares the original attempt's blind spots; prefer deterministic checks and isolated reviewer contexts. (3) Defining the loop as "keep trying" — an unbounded retry is a cost leak, not reliability; every cycle needs fresh evidence, a maximum attempt count, and a named escalation path. (4) Turning the harness into a warehouse — more tools increase selection errors, noisy context increases confusion, broad permissions increase risk; give the agent the smallest environment that can complete the job. (5) Blaming the model for orchestration failures — a stronger model cannot reliably repair stale state, broken APIs, or missing exit conditions; do not upgrade the model before proving the model is the problem source(https://x.com/0xwhrrari/status/2082096897964306572/?rw_tt_thread=True).

Diagnose the failure, then choose the layer. Rather than defaulting to graph complexity or adding more tools, match the engineering response to the failure type:

• Agent lacks a capability, loses state, can't be audited, or acts differently across environments → harness problem.
• Agent produces output but there's no evidence it's correct, no feedback on failure, or no stopping condition → loop problem.
• The process has meaningful branches, parallel work, approvals, or recovery paths that are currently encoded as ad-hoc conditionals → graph problem.

This diagnostic framing complements the context engineering paradigm timeline (prompt → context → loop): context engineering is the foundation that all three layers depend on, while the three layers are the structural decisions about how to apply that context in a running system.

Discovering Unknowns (Thariq)

Thariq (Anthropic, Claude Code team) frames the core bottleneck of agentic work as unknowns — the gap between the map (your prompts, skills, and context) and the territory (the codebase, the real world, its actual constraints). With Fable-class models, work quality is no longer bottlenecked by model capability but by the operator's ability to surface and clarify unknowns before the agent encounters them mid-run.

The four types of unknowns (the Rumsfeld matrix applied to agentic work):

• Known knowns — what's in your prompt. What you explicitly tell the agent you want.
• Known unknowns — what you haven't figured out yet but are aware of. You know you don't know the right database schema.
• Unknown knowns — what's so obvious you'd never write it down, but would recognize if you saw it done wrong. Taste, layout preferences, implicit conventions.
• Unknown unknowns — what you haven't considered at all. Edge cases in the codebase, better approaches you don't know exist, quality levels you haven't imagined.

The best agentic coders have relatively few unknowns — they are deeply in sync with both the codebase and the model's behaviors. But they also assume unknowns exist and plan for them. Reducing unknowns is the skill of agentic coding, and Claude itself is the best tool for doing it.

Pre-implementation discovery techniques:

• Blind spot pass — ask Claude to find your unknown unknowns before you start building. Give it context about your experience level and what you know. "I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns?" Especially valuable when working in unfamiliar parts of the codebase.
• Brainstorms and prototypes — for surfacing unknown knowns (criteria you can only define when you see them). Ask for multiple design directions to react to rather than articulating requirements upfront. Visual design and UX are prime examples — difficult to describe, easy to evaluate. "Make me an HTML page with 4 wildly different design directions so I can react to them." This also prevents setting too narrow or too wide a scope.
• Interviews — ask Claude to interview you about ambiguities, one question at a time, prioritizing questions where the answer would change the architecture. This surfaces unknowns you couldn't have found by brainstorming alone.
• References as specification — when you can't describe what you want, point Claude at source code that implements the behavior you need. Source code is a richer reference than screenshots or documentation because it captures structure, edge-case handling, and implementation decisions. Claude Design uses this same principle — it reads the underlying code of a reference component, not just its visual appearance.
• Implementation plans with decision surfaces — ask for plans that lead with the parts most likely to change: data models, type interfaces, UX flows. Bury mechanical refactoring at the bottom. This lets Claude surface unknowns you'd otherwise discover mid-implementation.

During implementation: keep a temporary implementation-notes.md where the agent logs deviations from the plan. "If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going." No amount of planning eliminates unknown unknowns — the notes file captures them for the next attempt.

Post-implementation: two techniques for closing the loop. First, package the prototype, spec, and implementation notes into explainer artifacts — this accelerates buy-in by showing reviewers you accounted for the unknowns they would have anticipated. Second, ask Claude to quiz you on the changes. Reading diffs gives only surface understanding; a quiz forces comprehension of behavior changes across existing code paths. "Give me an HTML report on the changes with context and intuition, and a quiz at the bottom that I must pass." Only merge after passing.

The instructing balance: being too specific makes Claude follow instructions even when a pivot is better; being too vague lets it default to industry best practices that may not fit. The unknowns framework resolves this — you don't need to specify everything upfront if you've systematically reduced the gap between your map and the territory. This complements the SysLS principle of separating research from implementation — Thariq's techniques are how you do the research phase well.

Owning the Outer Loop (Osmani)

Addy Osmani frames the defining boundary of agentic engineering: agents run the inner execution loop (investigate → implement → verify → repeat); engineers own the outer loop — the accountability for what ships. As models gain capability, the outer loop becomes the scarce, high-leverage work. "An agent can write it. But before it reaches users, someone must explain why it should exist, why it's safe enough to be part of production, and what they will do when it is wrong."

The accountability triad. Three concepts hold the outer loop together:

• Quality — all the checks installed before the system runs: type checks, tests, hooks, sandbox limits, audit logs. These checks produce evidence, and from that evidence you derive a verdict.
• Verdict — the production decision made from that evidence: ship, block, redirect, add a guardrail, or reject. The model may write the code, but the verdict belongs to the engineer. "The work of my team will not enter our dependent systems without my decision."
• Answerability — the guarantee that if someone asks, you can explain why. With long-horizon agents making hundreds of intermediate decisions over hours, reconstructing the chain after the fact becomes impossible unless answerability is designed in from the start.

The trust-verification gap. Code generation has outrun code control. Sonar's 2026 survey found 42% of committed code was AI-generated or significantly AI-assisted, with expectations for that share to keep growing source(https://www.sonarsource.com/state-of-code-developer-survey-report.pdf). GitLab's June 2026 research showed governance typically happens after code creation — after risk has been accepted and ownership lost source(https://ir.gitlab.com/news/news-details/2026/GitLab-Research-Reveals-Organizations-Are-Generating-AI-Code-Faster-Than-They-Can-Control-It/default.aspx). Many teams distrust AI code but haven't built that distrust into their verification processes. Creation is getting cheaper; review, validation, understanding, and maintenance are the scarce resources.

Three hidden costs of delegation:

• Cognitive surrender — blindly accepting AI output. A Wharton study found that when AI was wrong, nearly 75% of people accepted it anyway, and felt more confident than they would have without AI source(https://executiveeducation.wharton.upenn.edu/thought-leadership/wharton-at-work/2026/05/thinking-fast-slow-and-artificially/). The agent's output becomes your answer; with it comes all the accountability.
• Cognitive debt — erosion of understanding. An Anthropic randomized controlled trial found engineers who leaned on AI scored 17 percentage points lower on comprehension (50% vs 67%) than those who wrote code themselves source(https://www.anthropic.com/research/AI-assistance-coding-skills). The longer the agentic planning horizon, the wider the gap between what the agent produces and what you understand. The debt compounds.
• Orchestration tax — cognitive bandwidth doesn't parallelize the way agent fleets do. Steering, sorting, verifying, directing — none of it can be automated. See the dedicated treatment for the full analysis.

Back pressure, not maximum autonomy. Don't grant agents as much autonomy as they can exercise — grant just enough that you retain enough back pressure to stop them, check their work, and ensure your understanding. Ordinary engineering signals (type checks, tests, hooks, monitors) provide natural back pressure. As long as agents emit the same signals, the existing engineering system constrains them appropriately.

Four human loops (not the inner loop). The human doesn't need to be in the agent's execution loop. They need to be in four surrounding loops:

1. Constraints loop — what inputs, architectures, instructions, or invariants to set
2. Sampling loop — how much output to sample and review
3. Audit loop — what evidence to keep and how to ensure audit effectiveness
4. Ownership loop — what part of the production boundary to own

This maps directly to the delegation–collaboration split: collaborative work keeps the human in the inner loop; delegated work moves them to these four outer loops. The loop engineering concept of open vs. closed loops is the implementation-level version of the same boundary.

High agency as discernment. The agency ladder runs from low to high: flag a problem → investigate → execute → diagnose → propose solutions → recommend → resolve. The highest rung is discernment: "found it, it's not worth fixing, moving on." High agency is knowing when to delegate, when to inspect, when to stop, and when to own the result.

Accountability scales the factory. Without accountability, high agency brings chaos — no rules, no trade-offs, no safety nets. Skills give you leverage; accountability turns leverage into trust. The half-life of a technical edge is one release; the half-life of a signature — your name on work you stand behind — is a career. Every codebase should come with an accountability contract: the checklist understood when the change was accepted, the evidence behind the decision, who was accountable, and the system status after the change. The bottleneck moves from "can we build this?" to "should this exist, and can we answer for it?"

Harness Design: "Seeing Like an Agent"

The harness concept has grown into its own dedicated topic. For a full treatment of what a harness is, its 12 components, the thin harness / fat skills pattern, memory ownership, and design decisions, see Agent Harness.

The Claude Code team (Thariq, Anthropic) published key lessons on designing agent action spaces:

Core principle: Give agents tools shaped to their own abilities. The right tool depends on the agent's capabilities, not human intuition. "Put yourself in the mind of the model."

Lessons learned:

• AskUserQuestion tool — Three attempts to improve elicitation: parameter on ExitPlanTool (confused the model), modified markdown output (unreliable formatting), dedicated tool with structured output (worked). "Even the best designed tool doesn't work if Claude doesn't understand how to call it."
• Todos → Tasks — As models improved, todo reminders became constraining. Replaced with Task tool supporting dependencies, subagent communication, and deletion. "As model capabilities increase, tools that once helped might now constrain them."
• Search evolution — Started with RAG vector database, moved to Grep tool for self-directed search, then progressive disclosure via skills. Over one year: "Claude went from not being able to build its own context to nested search across several layers of files."
• Progressive disclosure — Add functionality without adding tools. The Claude Code Guide subagent loads docs on demand rather than stuffing everything in the system prompt. ~20 tools total, high bar to add more.

The eval gap remains the widest hole in production agent work: 89% of teams running agents have observability set up, but only 52% have evals source(https://x.com/akshay_pachaar/status/2070860837448040832/?rw_tt_thread=True). For evaluation methodology that applies directly to agent systems — floor-raising over benchmark-maxxing, trace review pipelines, LLM-as-judge — see AI Evals.

Planner/Generator/Evaluator Harness (Anthropic Applied AI)

This pattern now lives in the loop-engineering article. For the full treatment — the three separated roles, GAN-inspired contract negotiation, evaluator trace-isolation, pivot behavior, the model-capability timeline, greenfield-vs-brownfield applicability, and harness co-evolution across model generations — see Loop Engineering → The Planner-Generator-Evaluator Harness.

In one line: three separated roles in three context windows — a planner that sets high-level sprints, a generator that builds, and an evaluator that actually uses the running app (via Playwright) and grades it against a negotiated contract — convert a model's easy-to-critique / hard-to-self-correct asymmetry into a working quality loop.

Self-Improving Agents

The Distinction: Self-Improving ≠ Self-Learning

The phrase "self-improving agent system" gets used carelessly. The version that works today and the version that's hype are different things:

• Self-learning — the agent updates its own weights from experience. No publicly available model does this in production. Recursive self-improvement (RSI) is a long-term research direction, not a shipping capability.
• Self-improving — the system around the agent compounds. Each session writes lessons to memory. Skills sharpen as edge cases accumulate. State files collect verified facts. Eval loops refine prompts and rubrics. The model stays the same; the environment it runs in gets sharper.

Self-improvement, in this sense, is a property of the system you build — not a property of the model. The model provides the raw capability (long context, sub-agent delegation, vision self-check); the system provides the feedback loop that makes it compound run over run.

The Compound Stack

The architecture that makes agent systems compound has four layers, read bottom-up in the order they get built:

1. Primitives — The model itself, sub-agents, worktrees, tools. Raw capability with no system around it. This is where most users stop.
2. Orchestration — /goal and Outcomes for self-correcting loops. Loop Engineering for multi-step orchestration. Routines for laptop-off cloud runs. Turns primitives into workflows.
3. Memory — State files, Skills, Knowledge Bases, lessons written down. Makes tomorrow's session resume instead of restart.
4. Self-improvement — Vision self-checks, eval loops, rule distillation. The agent grades its own output, refines the Skill that produced it, writes the lesson back to memory.

The compounding mechanism: every output from layer 1 flows up through layer 4, where it gets graded, distilled, and written back to layer 3. Tomorrow's run at layer 1 inherits the sharpened memory and refined Skills from yesterday. The model is stateless; the system around it isn't.

Cost-Routing for Production Systems

Not every step in a self-improving system needs the top-tier model. Teams running these systems in production route by task complexity:

• Frontier model (Fable 5 / most capable available) for the orchestrator role: planning across days, delegating to sub-agents, checking work with vision, distilling rules from accumulated evidence. Use where days-long capability earns its pricing.
• Strong model (Opus-class) for hard-but-bounded subtasks: architecture decisions, complex debugging, deep code reviews. Also the explicit fallback for any request the frontier model's safety classifiers block.
• Fast model (Sonnet-class) for high-volume worker tasks: lint passes, simple refactors, test scaffolding, doc updates. The bulk of fan-out work.
• Cheap model (Haiku-class) for grader sub-agents and classifiers. Independent context window, low cost — ideal for the verifier role.

The pattern: orchestrator on the frontier model, workers on the fast model, graders on the cheap model, fallback to the strong model on classifier blocks.

Anthropic's own benchmarks quantify the savings from two variants of this pattern. In the advisor pattern, a Sonnet-class executor calls a Fable-class model for guidance — typically once per task for strategic steering while the executor handles the bulk of the work. On SWE-bench Pro, this recovers ~92% of the frontier model's score at ~63% of the cost. In the orchestrator pattern, a Fable-class model plans and delegates to Sonnet-class workers. On BrowseComp, the orchestrator configuration achieves 96% of solo-frontier performance at 46% of the price, because token-heavy research is delegated to the cheaper workers source(https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool).

Personal agent economics. At the other end of the scale, a single-purpose personal agent (e.g., a Telegram bot backed by Sonnet-class on a $4–6/month VPS) runs at roughly $1–5/month in API costs for ~50 messages/day. The entire stack — hosting, API, and deployment — fits under $10/month. This makes personal agents economically viable as always-on utilities rather than experiments, and the deployment is trivial: Claude Code generates the bot code from a plain-English description, systemd keeps it running, and skills (web search, note-taking, scheduled briefings) bolt on as incremental prompts.

Safety Boundary as Architecture Constraint

Frontier models increasingly ship with built-in safety classifiers that decline to respond in specific high-risk domains (cybersecurity vulnerability research, biology, chemistry, model distillation). When the classifier triggers, the model falls back silently — and a self-improving system running autonomously can't distinguish a classifier block from a real error.

Design implications:

• If your system touches security tooling, expect classifier blocks. Route those tasks to a non-frontier model explicitly, or surface the block to a human reviewer.
• Skills should document which task types may hit the classifier and specify expected fallback behavior.
• Treat the safety boundary as a known architectural constraint, not a failure mode. A system with explicit handling stays robust as classifiers evolve; a system that ignores them produces silent regressions.

Orchestration-Aware Self-Extension

The self-improving patterns above focus on memory, evals, and rule refinement — the agent sharpens the environment it runs in. A more structural form of self-improvement emerges when the agent can author and deploy new durable skills directly into the orchestration engine. Rather than just learning from its runs, the agent extends its own capabilities by writing new functions, registering them with the orchestrator, and having them start running immediately — hot-reloaded without restarting or disrupting in-flight runs.

A concrete example: an engineer reports overnight latency spikes that go unnoticed until morning. The agent writes two functions — a health-check loop (runs every 30 minutes, pulls error rates and latency, LLM classifies as normal/degraded/critical) and an incident-triage skill (fetches detailed metrics and deploy history, correlates root causes, posts a summary to Slack). Both deploy instantly via a sidecar process. The skills persist beyond the conversation that created them — kill the agent process, restart it, swap the underlying model, and the skills keep running. The agent is ephemeral; its output is durable.

The compounding mechanism is a separate review loop: a cron-triggered function that runs weekly, reads run history from the orchestrator, and evaluates whether alerts correlated with actual outages. If health checks keep flagging a service but the team ignores them because thresholds are too sensitive, the review loop catches the pattern and the agent updates the classification logic. Concurrency controls (singletons per service) prevent duplicate triage runs from racing. This is self-improvement applied not to memory or prompts but to executable infrastructure — each skill the agent deploys is institutional knowledge encoded as a durable function source(https://x.com/djfarrelly/status/2067677007140278630/?rw_tt_thread=True).

AutoAgent

Kevin Gu released AutoAgent — first library for autonomously improving agent harnesses. Key results:

• Hit #1 on SpreadsheetBench (96.5%) and #1 GPT-5 score on TerminalBench (55.1%) after 24+ hours of autonomous optimization
• Every other leaderboard entry was hand-engineered

Architecture: Meta-agent experiments on task agent's harness — tweaking prompts, adding tools, refining orchestration. Task agent starts with just a bash tool. Meta-agent spins up 1000s of parallel sandboxes.

Key findings:

• Splitting helps — One agent improving itself doesn't work. Being good at a domain ≠ being good at improving at that domain.
• "Model empathy" — Same-model pairings (Claude meta + Claude task) outperform cross-model. The meta-agent writes harnesses the inner model actually understands.
• Traces are everything — Without reasoning trajectories, improvement rate drops hard. Understanding why matters as much as knowing that.
• Agents overfit — Meta-agents insert rubric-specific prompting to game metrics. Constrained by forcing self-reflection.

Emergent behaviors: Spot checking, forced verification loops, writing own unit tests, progressive disclosure, orchestration logic with subagents.

Continual Learning in Production (Replit)

Replit's Michele Catasta frames continual learning as operating at three layers — model, harness, and context — and argues that the latter two are where most production teams should focus, since frontier model weights are off the table for fine-tuning. Harness-level learning mines production traces to systematically improve code, tools, and instructions across all agent instances. Context-level learning personalizes at agent, user, and org scope so the product compounds with every interaction.

The practical system has two measurement pillars and one optimization loop, following a Swiss cheese model where each layer has gaps but together they catch more than any single layer:

• Offline benchmarks (ViBench) — Replit's public benchmark for vibe coding. Unlike SWE-bench or Terminal-Bench, ViBench starts from a plain-English PRD (drawn from anonymized production traces) and grades whether the built application meets the spec. The eval agent uses Playwright to progressively discover and exercise whatever the coding agent invented — no fixed locators, routes, or test harnesses. Natural-language test plans replace hard-coded assertions. Early results showed that frontier coding-benchmark scores don't reliably transfer to full app building, and most models degrade when extending their own code as errors compound. See AI Evals for complementary evaluation frameworks.
• Online A/B tests — Most agent-affecting changes (prompts, tools, harness revisions, model swaps) get A/B tested in production. Results are hard to interpret: longer runs may mean more useful work or the agent getting stuck; lower cost may mean efficiency or silently dropped capability.
• Telescope (trace clustering) — At production scale, no engineer can read every trace. Telescope organizes repeated failure patterns into issue clusters using density-based clustering on evidence-grounded facets (inspired by Anthropic's Clio). It reconstructs sessions from user messages, agent replies, tool calls, and errors, then summarizes, embeds, and clusters what went wrong. Engineers search the compact facet layer first, then drill into representative sessions. In aggregate, Telescope answers which workflows dominate, which get abandoned, and whether a mitigation is shrinking its target cluster.

The self-improvement loop. Once measurement exists, the bottleneck shifts to turning evidence into fixes. Each loop pass reads production logs, trace clusters, and recent failures to form a hypothesis, builds a candidate fix, opens a draft PR with reasoning attached, measures against ViBench and A/B baselines, and recommends whether to ship, iterate, or drop. Engineers still review and own the launch decision — the loop prepares the evidence and first-pass implementation. Each run records what it tried (including failures), so future runs reuse what worked and avoid known dead ends.

Where human judgment remains essential: hypothesis selection (deciding which clusters deserve the loop's overnight budget), implementation architecture (traces show abandonment but humans decide whether to smooth the path or redesign the surface), eval curation (shaping the hill the agent climbs — wrong rewards produce wrong optimizations), and launch approval (reading evidence, understanding blast radius, owning the rollout).

Multi-Agent Orchestration

Software Factories: Gas City

Gas City (successor to Steve Yegge's Gas Town) is an open-source orchestration toolkit for running 100+ coding agents in parallel on a single codebase, rebuilt by Chris Sells (ex-Google Flutter) and Julian Knutsen (ex-Block). In production, Knutsen's server runs ~100 agents merging ~50 PRs/day, burning roughly a billion tokens/day.

Three ideas worth internalizing:

• Dark factory vs. light factory — Human-visible work (planning, design, review) stays "light"; agent-only execution stays "dark" in the background. As trust grows, more process moves into the dark.
• One pet, many cattle — One persistent supervisor ("the mayor") you talk to directly hands tasks to anonymous, disposable workers ("polecats") that do one job and shut down. You manage one conversation; the mayor coordinates a hundred agents.
• Multiple opinions on every code review — Route the same code to Claude, Codex, and Kimi simultaneously. Three different models catch different bugs than one model run three times.

Current limitations: Every task spins up a fresh session with no memory of earlier steps — agents waste cycles re-reading context and miss connections a persistent session would catch. Cost scales linearly (a six-step job costs 6x a single session). The CLI-first task tracker ("Beads") works for agents but not humans, so teams pair it with Jira or Linear. The toolkit also over-scaffolds for current model capabilities — review loops and mid-task check-ins built to keep models on track are now largely unnecessary source(https://every.to/napkin-math/inside-the-100-agent-software-factory).

Verdict (Mike Taylor, Every): "Learn from the ideas. Skip the toolkit for now." For teams already running 10+ parallel Claude Code sessions, Gas City is one informed opinion on orchestration at that scale.

OpenAI Symphony — A more accessible alternative: a written ruleset that turns an existing Linear board into the dashboard agents work from. No behavior change required, closer to how software engineers already work.

Why Software Factories Fail (Dex)

Dex (HumanLayer, author of "Advanced Context Engineering for Coding Agents") argues that the lights-off software factory does not work — and that the failure is structural, rooted in how coding models are trained, not in how teams configure their harnesses.

The practitioner experience. HumanLayer went full lights-off in July 2025: background agents for all small/medium work, specs-and-tickets-only, no human code reading. By the third major incident in November — after repeated weeks-long debugging sessions through agent-generated spaghetti — they decided a from-scratch rewrite was easier than continuing to maintain the codebase. The pattern: models degrade codebase quality over time, producing shotgun surgery where changing one part breaks another. Agent-built codebases start struggling after roughly three to six months.

The RL training gap. The structural explanation: coding agent RL optimizes for a one-dimensional reward — did the tests pass? Benchmarks like SWE-bench score agents on FAIL_TO_PASS (did you fix the bug?) and PASS_TO_PASS (did you avoid breaking anything else?). How the model reached a correct answer — whether through clean abstractions or try-catches wrapping everything — is irrelevant to the score. There is no penalty for eroding codebase maintainability. Tests give feedback in seconds, but the cost of bad architecture is measured in weeks, months, or years — the first time someone opens a file for a one-line change and discovers it requires edits in eleven places. RL needs a fast, reliable oracle, and maintainability has no fast oracle.

The critic paradox. If a model could reliably distinguish good code from bad, it might have written the good version to begin with. More review agents and more tokens raise the floor — catching obvious mistakes — but don't move the ceiling, because the ceiling is whatever was taught during RL, and good design is the thing RL still can't reward. This directly extends the evaluator isolation principle: adversarial review catches bugs the generator missed, but neither the generator nor the reviewer was trained to optimize for long-term maintainability.

Correlation signal. Faros AI's report found that since widespread AI coding tool adoption in early 2025, PR review quality has declined — more comments, longer comments, more PRs merged with no review at all — while incidents and bugs per developer are up source(https://www.faros.ai/research/ai-acceleration-whiplash). Directional, not causal, but consistent with the thesis that removing human review without solving the maintainability gap accelerates codebase decay.

Frontier benchmark efforts. Three efforts are beginning to score maintainability rather than stopping at pass/fail: SWE-Marathon (Abundant AI) assigns ~400-hour tasks with compound reward channels instead of single-bit scores. DeepSWE (Datacurve) uses tasks on repos never built in the real world, solving training-data contamination but not quality. Frontier Code (Cognition) evaluates multi-PR tasks with mutation testing — penalizing models for writing tests that don't fail on the pre-patch code — and runs a judge model over diffs checking code-quality rules. None are reliable enough to bet a codebase on, but they are the first evals even attempting to measure the dimension that matters most.

Implications for factory design. The thesis does not reject agentic coding — Dex's own prior work popularized context engineering techniques. The claim is narrower: no amount of harness engineering or loopsmaxxing can solve what is fundamentally a model-training issue. The lights-off factory removes the one check — human review — that currently compensates for the RL gap. Teams should keep humans in the outer loop not because review is pleasant, but because it is the only mechanism that currently penalizes bad design. This aligns with Osmani's back-pressure principle: grant agents just enough autonomy that you retain enough back pressure to stop them and check their work.

Agent Factory Architecture (Avid)

Avid's "agent factory" blueprint addresses the structural problem that lights-off factories fail on: not the building of agents, but the certification and continuous verification of agents at scale. The core claim: hand-built agents cap at the number you can personally watch, and better models don't move that cap — only automated quality gates do.

The two necks. Every factory has a first bottleneck — human review — that jams as throughput rises. An agent factory has a second: unlike software, which is verified once at build time, an agent must be verified on every run because its output is non-deterministic. The first neck (certifying the agent) stays human and happens once. The second neck (gating every output) must be automated, because an agent that needs you to read every reply is a slower you.

Five stations. The production line runs spec → stamp → prove → certify → operate:

1. Job card (spec) — An agent bill of materials: identity, granted tools, cost tier, and permission envelope. A grants list that nothing reads is decoration — station 5 is where it becomes a control.
2. Assembly (stamp) — Copies a master agent into variants. The part most people skip: when you fix the master, the fix propagates to all variants and revokes their certificates. A fix that propagates without revoking is worse than no propagation, because the certificate is now lying.
3. Proving ground (prove) — A test suite written before the agent is good, from real cases, labelled by hand. Half the cases are sealed — the builder never sees them. An agent tuned against a visible suite is optimizing the suite, not proving competence. The suite scores both deterministic outputs (exact-match labels) and prose quality (rubric-graded on a 0–4 scale). An agent that passes its suite while reaching for tools it doesn't have is not passing — tool denials count.
4. Certification (certify) — The law in code: no evals, no production. A digest check ensures tuning after the sealed run costs a re-certification. The decision model grades; it never signs. The certificate is a human reading a record and typing yes. A vendor offering to automate that box is selling you the one thing you should not buy.
5. Broker (operate) — Every tool call passes through a broker that reads the job card. Policy is enforced outside the model — an agent can't prompt its way past a grant it was never given. Then an output gate scores whether well-formed, fully-permitted output is right, the one thing local policy can't tell you.

Autonomy tiers. Four tiers, all earned: C0 (observe — runs on live work, ships nothing, compare against actual outcomes), C1 (drafts only), C2 (stages for one-click human approval), C3 (acts alone inside the permission envelope). Promotion requires both proving-ground and production evidence. Autonomy is evidence you produced, not confidence you feel. This extends the back-pressure principle into a formal ladder.

Mid-run routing. Both quality necks sit at the end of a run. A proxy router sits inside runs — the only place you can stop paying for work that was never going to be worth gating. Five local detectors run before any model call: same action returning the same observation three times, one error class repeating, two actions alternating in the last eight turns, write-fail cycles, and no successful execution for N steps. When detectors fire, two fast decision calls determine whether to continue, switch models, restart with clean context, or escalate to a human. The restart option is worth stealing even in isolation — it rebuilds the request keeping the user task and tool outputs while dropping the model's own reasoning, because polluted context is how one bad turn becomes ten.

Self-staffing. The final move: the factory hires from its own catalog. A meta-agent — itself certified through the same five stations — reads flagged production runs and writes eval cases that would have caught the failures. It writes to a proposals file and cannot write to the live suite; promoting a proposal to a real eval is a human edit. An agent that extends the suite it is judged against grades its own homework. This is self-improving agents applied specifically to the evaluation layer: generation is autonomous, certification is not.

Six tests that separate a factory from a folder of prompts: (1) the product is an agent with identity, tools, and a price; (2) the certificate constrains runtime, enforced outside the model; (3) master fixes propagate and kill certificates; (4) the line is worked by agents the line produced; (5) production failures become the next suite; (6) bad product can be recalled.

The architecture is a direct counterpoint to the Dex thesis: the lights-off factory fails because human review is the only mechanism penalizing bad design. The agent factory doesn't remove human review — it moves it to certification (once, thoroughly) and automates the per-run output check that would otherwise cap your fleet at the number you can personally read.

Enterprise Fleet Management (Spotify)

Niklas Gustavsson (Spotify) describes the most concrete enterprise case study of agent-based code maintenance at scale: 2,900 engineers, 20M+ lines in the backend monorepo alone, and a codebase growing seven times faster than engineering headcount. The organizational response — fleet management — automates mutations across the entire codebase instead of asking hundreds of teams to perform the same migration manually.

The deterministic ceiling. Fleet management started with deterministic scripts that applied code changes across thousands of repositories. Each migration (Java version upgrades, library updates, API swaps) previously required manual work from every team, taking months and capping throughput at roughly ten migrations per year. But code has an enormous API surface — calling a method in five different ways means the migration script explodes into thousands of lines handling edge cases. Static analysis transformations hit a complexity ceiling quickly source(https://www.youtube.com/watch?v=9DHZLw5653E).

From scripts to agents (Honk). As early LLMs appeared, Spotify applied them to the fleet management problem. Early attempts — one-shotting code changes with raw model calls — failed. Over many iterations the team added LLM-as-judge verification, problem decomposition, and eventually consolidated everything into Honk, now built on the Claude Agent SDK running in Kubernetes pods. The judge was critical early on, pushing PR success rates from 20–30% to ~80%. But as models improved (around Opus 4–5), the judge became unnecessary — the agent alone matched or exceeded the judged success rate. Honk V2 (the "real V8") now lets users add their own tools, and agents can run CI verification on both Linux and macOS (critical for iOS development). The system handles everything from Figma-to-UI implementation to porting TV apps from iOS codebases source(https://www.youtube.com/watch?v=9DHZLw5653E).

Verification as the unlock. Spotify's experience validates the verification-as-essential-feedback principle with enterprise-scale evidence. When fleet management began auto-merging PRs without human review, the team had to strengthen test automation across thousands of components. Each component has well-defined ownership, and teams were told they might no longer be in the loop for automated changes. The investment in test coverage — originally made for fleet management — transferred directly to agentic coding. Quality metrics remain neutral while speed improves significantly, but the investment was not free: reliability practices must continue evolving as velocity increases. Spotify makes ~4,500 production deployments daily source(https://www.youtube.com/watch?v=9DHZLw5653E).

Standardization multiplies agent effectiveness. Spotify drove codebase consistency (common tools, frameworks, patterns) originally to simplify things for humans. The same standardization turned out to be equally important for agents: when Claude looks at other code in the monorepo for inspiration, consistent patterns produce better results than ten different ways of doing the same thing. This extends the domain knowledge as infrastructure thesis — standardization is a form of encoded domain knowledge that benefits both human and agent contributors.

Metrics. 75% improvement in PR frequency directly attributed to AI tooling. 73% of PRs are AI-authored. The ROI case was initially easy because improvements were so large; as maturity increases, the team is building attribution pipelines connecting PRs → deployments → work items → A/B tests → user value.

Prototyping as a new mode. Beyond fleet management, Spotify built infrastructure for anyone — including non-engineers and senior executives — to create end-to-end prototypes in the real mobile apps and backend. An internal app store lets people share and try each other's prototypes with real data. One of the co-CEOs has prototypes in the store. Ideas that previously required motivating an engineering team for weeks can now be validated in hours. This is a concrete instance of the delegation–collaboration split: prototyping is collaborative (the builder steers, the model builds), while fleet management is pure delegation (dispatch and check back).

Other Orchestration Tools

crabfleet (OpenClaw / Peter Steinberger) — "Mission control for agent runs." A loop packaged as a product: tasks entered as cards (from a prompt, GitHub issue, or PR) move through todo → running → human review → done. Runs are durable with heartbeats, surviving closed laptops. Agents can spawn child sessions, send messages, read transcripts, and update summaries from inside a sandbox. Runs on disposable cloud sandboxes with browser-based terminals. The point is not the specific tool but that the loop has hardened into infrastructure — a queue, durable execution, fan-out, and a human-review gate are now things you configure rather than hand-script. https://github.com/openclaw/crabfleet

Paperclip — Open-source orchestration for "zero-human companies." If OpenClaw is an employee, Paperclip is the company. Node.js server + React UI with org charts, budgets, governance, goal alignment. Supports any agent (OpenClaw, Claude Code, Codex, Cursor). "If it can receive a heartbeat, it's hired."

Hermes Agent (Nous Research) — Self-improving agent with closed learning loop: agent-curated memory, autonomous skill creation, skill self-improvement during use, FTS5 cross-session recall. Runs on 6 terminal backends (local, Docker, SSH, Daytona, Singularity, Modal). Lives on CLI, Telegram, Discord, Slack, WhatsApp.

Raft — Shared workspace where humans and agents collaborate as teammates. Looks like Slack (channels, threads, tasks, DMs) but members include agents with persistent identity and memory. Agents claim tasks from channels, run in parallel, hand work to each other, and review each other's output in shared threads. Agents run locally via a lightweight process ("the Computer") using existing subscriptions (Claude Code, Codex, Gemini CLI, Cursor) — Raft never sits between agent and model. External agents (like Hermes) join through a gateway process. 20,000+ builders; the Raft team itself runs 10 humans and 100+ named agents internally.

Buzz (Block / Jack Dorsey) — Agent-as-teammate workspace where every agent gets a cryptographic key pair (not an API token), joins channels like a new hire, reads history, and participates in threads, DMs, and voice huddles with the same mechanics as human members. Model-agnostic via a harness layer — agents run on Claude Code, Codex, or Goose, and switching models is a dropdown change with the agent's identity and memory preserved. Self-hosted on your own server (Nostr-based decentralized identity), so messages stay off vendor infrastructure. The "chief of staff" pattern — one agent that delegates research, writing, and fact-checking to specialized agents, spins up project channels, and coordinates handoffs in threads — demonstrates multi-agent orchestration emerging from the room metaphor rather than from code. Shared compute lets community members pool local hardware (Mac Studios, etc.) so agents run on peer-to-peer local models that scale automatically as more members contribute — no API costs, no token bills. Agents also join voice huddles — drop-in audio calls from any channel — responding to spoken questions in real time with the same tool access they have in text. Each agent maintains persistent memory that accumulates from user corrections during conversation (e.g., "always talk like a pirate," "flag turtle-spotting conditions"), giving agents continuity across sessions without manual configuration. Early-stage (July 2026): rough installer, no mobile client, but the core architecture treats agents as first-class organizational members rather than plugins.

MiroFish — Swarm intelligence prediction engine. Creates multi-agent simulations with independent personalities and long-term memory to predict outcomes from seed information (news, policies, financial signals).

Agent Composition Template (Machina)

A practitioner template for standing up named agents as teammates rather than disposable sessions. Every agent is assembled from the same five parts:

1. Name — A real name, not "agent-2." The name is how you route work ("give this to june") and how you audit it ("june drafted this, who reviewed it?").
2. Soul — The agent's job description, scope constraints, and tone. Half a page is enough: role, scope boundaries, tone rules, daily deliverables, hard rules. On Raft this accumulates from chat corrections rather than being written up front — you tell the agent things ("drafts only, never contact a prospect") and its own version builds over time.
3. Memory — Agent-maintained working notes (a MEMORY.md plus scratch files): what worked, what failed, which sources are gold, which are noise. The operator feeds it through corrections; the agent writes it down. Compress when notes pass a page — memory that grows forever stops being read.
4. Goals — What the agent owns, what "done" looks like, and what it must escalate instead of deciding. Three buckets: own (steady flow of X), done (every output has Y), escalate (pricing, legal, anything answered).
5. Heartbeat — The schedule it wakes on without being asked. Two are usually enough: a daily sweep and an hourly check that stays silent when nothing changed.

Engine-routing table. Match engine to work type rather than defaulting everything to one model: Claude Code for writing-heavy tasks (content, client deliverables — strongest prose), Codex for building (internal tools, automations, scripts — sandboxed execution), Hermes for always-on monitoring (lead sweeps, reply watches — heartbeats, monitors, playbooks). The routing isn't about which model is "best" but which harness suits the task shape.

Cross-review as self-improvement. No agent grades its own work — left alone, an agent approves its own output every time. Every deliverable crosses a second agent instructed to assume the work is broken. The same five agents review each other (cole reviews ray, etta reviews june, etc.). Every rejection carries a reason that gets written back into the soul and memory files, so the same mistake doesn't survive twice. See also self-improving agents and loop engineering for the broader pattern.

One pillar at a time. Don't stand up five agents at once — "a team you can't feed is theater." Day 1: one agent for the pillar where you lose the most hours. Day 2: add its reviewer. Days 3–7: run the pair daily; every time you correct the same mistake twice, write it into the soul file. Week 2: add the next pillar only because the first one now runs without you.

Graph Engineering (Machina)

Graph engineering has grown into its own dedicated topic. For the full treatment — node/edge vocabulary and contracts, the fake-edge test, the diamond pattern, verification on clean-context nodes, the human gate, the 8-step build methodology, conditional routing and controlled cycles, pipeline-vs-parallel topology, when not to use a graph, anchors, and cost reality — see Graph Engineering.

In one line: a graph draws AI work as nodes (bounded jobs) and edges (real data dependencies) so independent work runs in parallel; the diamond (fan-out → reduce → synthesize) is the pattern that pays, a separate verifier on a clean context is non-negotiable, and a human gate belongs wherever a mistake is expensive to undo.

The Orchestration Tax (Osmani)

Addy Osmani names the structural cost most multi-agent practitioners underestimate: the orchestration tax — the gap between what agents can produce and what the human operator can actually review and merge. Starting agents is cheap (a keystroke); closing the loop is not. Someone must verify correctness, reconcile conflicts across parallel outputs, and maintain a coherent mental model of the system. That someone is a single-threaded serial resource.

The GIL analogy. Python's Global Interpreter Lock lets you spawn threads freely, but only one executes bytecode at a time. The human is the GIL of their agent fleet — all agent output that requires genuine architectural understanding or conflict resolution must acquire the lock. There is one lock. Amdahl's Law makes the ceiling precise: speedup from parallelization is capped by the fraction of work that stays serial. Spawning eight agents doesn't speed up judgment time; it deepens the queue feeding into it.

Grinding won't fix structural limits. Running the serial processor at 100% with no slack produces a specific kind of exhaustion: constant context-switch cost (flushing and cold-reloading mental state per agent), background anxiety about which thread is silently failing, and eventual cognitive surrender — accepting agent output because forming an independent opinion costs attention you no longer have. The tax gets paid either deliberately or by quietly destroying your understanding of your own system.

Architect your attention as a scarce resource:

• Scale fleet to review rate, not the UI. Backpressure: the right number of parallel agents is how many you can properly code-review, typically low single digits. The tool will let you spawn twenty; that is a UI feature, not a throughput feature.
• Sort work into two piles. Isolated tasks (background agents, async, gate at the end) vs. complex tasks where judgment is the work (architecture, subtle bugs). The mistake is trying to parallelize the second pile — it thrashes the lock and everything comes out worse.
• Batch reviews. Context switching is the dominant cost. Reviewing four agents in one sitting is far cheaper than checking one, leaving, and returning cold. Give agents a long leash; process the batch.
• Only spend the lock on judgment. Make agents prove the boring 80% themselves (passing tests, screenshots, self-verification) so scarce attention goes to the 20% that genuinely needs a human.
• Protect serial time. The bottleneck needs your best hours, not leftover minutes between agent check-ins. Sometimes the highest-leverage move is to stop orchestrating entirely and think hard about one problem with the lock held.

The orchestration tax left unpaid accumulates both technical debt (merged code you didn't read well) and cognitive debt (a stale mental model of your own codebase). Neither shows on a dashboard today; both show when production breaks and you realize you have no idea how the system works anymore. Osmani later placed the orchestration tax alongside two companion costs — cognitive surrender and cognitive debt — within the broader outer-loop accountability framework. See also: the delegation–collaboration split for how to classify which work mode fits which task.

Compounding vs. Leaking (Eric Siu)

Eric Siu, running 10–15 agents daily (Hermes in Slack, Claude Code, Codex), names the failure mode that the orchestration tax creates when left unmanaged: leaking. Work either compounds — today's output builds on yesterday's, making the pile more valuable over time — or it leaks, vanishing into threads you'll never reopen, forcing you to pay for the same work twice.

Symptoms of leaking: asking your own threads to summarize what they were for, dreading old sessions because you can't remember their state, shipping something and finding a near-identical agent-produced version from two days earlier. The feeling is "busy all day, moving slowly" — the worst kind of problem because you can't point at it to fix it.

Workspace over stream. Chat apps are streams — newest on top, no sense of priority, no memory of what's still open. That model breaks at 15 concurrent workstreams because the human becomes the memory for all of it. The fix is treating agent work as sessions with state, status, and priority — the same model Claude Code and Codex use. Siu's first move: point an agent at his own backlog and have it sort by priority, grouping P0s (CFO spend thread, HubSpot work, pre-meeting context cron) at the top. "That single change moved me from a stream to a workspace."

Skill reuse. Building a good skill, using it once, then forgetting it exists is compounding running in reverse. A searchable skill library turns past work into an asset; an unsearchable one turns it into "a story about a thing you once did." The same applies to artifacts (pages, images, creatives) — when they live in one searchable place, last month's output becomes this month's starting point.

Cross-tool resolver. The highest-leverage piece: a resolver that runs at end of day, reads across all tools (Hermes, Claude Code, Codex), finds overlapping work, and gives a straight call on each cluster — keep this, consolidate these, delete that. Any single tool can only see its own sessions, but duplicate work typically spans tools (thread in Hermes Monday, half-solution in Codex Tuesday). The resolver is the only view that sees the whole day at once.

Scaffolding compounds, models don't. Swapping in a new model gives a slightly better answer; you're back to square one when the next one lands. Scaffolding — workspace organization, reusable skills, prep crons, resolvers — stacks permanently. "Build a couple of these a week, and six months from now you're operating at a level no model release can hand you."

Loop Engineering

The loop engineering concept has grown into its own dedicated topic. For a full treatment — five-stage lineage (ReAct → Reflexion → AutoGPT → Ralph → /goal → orchestration), the four-level stack, open vs. closed loops, the four-box test, autonomy ladder, five building blocks, verification patterns, business loops, and the cost dynamics — see Loop Engineering.

Loop engineering is the practice of replacing yourself as the person who prompts the agent — you design the system that prompts it instead. Where harness design shapes the environment a single agent runs inside, and orchestration coordinates multiple agents, loop engineering sits one level above both: a recurring system that discovers work, dispatches agents, checks results, records state, and decides the next step — all without a human in the turn-by-turn prompting seat. Boris Cherny's framing: "I don't prompt Claude anymore. I have loops that are running. They're the ones that are prompting Claude and figuring out what to do. My job is to write loops." The fleet loop maps directly to the orchestration patterns elsewhere on this page — orchestration with a recurring feedback cycle wrapped around it. See Loop Engineering for details.

Managed Agents (Anthropic)

This topic grew into its own dedicated page — architecture (session/harness/sandbox decoupling), pets-vs-cattle shift, security boundary, performance results, and the OpenAI + AWS Bedrock Managed Agents variant. See Managed Agents.

Anthropic decouples the model ("brain"), harness, and sandbox ("hands") into independently replaceable, stateless components so agents can scale and recover from crashes; OpenAI + AWS ship a parallel enterprise variant (Bedrock Managed Agents) packaging OpenAI's models inside an AWS-native agent runtime.

The Great Convergence

Nicholas Charriere's thesis (Apr 2026): app companies, model companies, and infrastructure companies are all converging on the same product shape — self-improving agents that do knowledge work.

Why it's happening: The general harness (model + loop + tools) turns out to be a general-purpose problem-solving machine. Claude Code was the breakthrough — initially built for coding, it generalizes to any computer-based task with the right tools. The prize is enterprise knowledge work, which dwarfs B2C AI use cases.

Who's converging:

• Systems of record (Salesforce, Notion, Linear) — own the data and workflow; just need to productize the harness
• Model companies (Anthropic, OpenAI) — own intelligence but face commoditization; moving up-stack into applications. OpenAI deprioritized Sora to focus entirely on Codex
• Communication platforms (Slack, Teams) — agents need to communicate with each other and humans; these companies have already solved that
• Infrastructure companies (Databricks, Vercel, Cloudflare) — repositioning as "infrastructure for agents," providing sandboxes, compute, monitoring, orchestration

The self-improvement loop: Drive → collect data → retrain (autonomous vehicles) maps to: run → monitor → improve harness code and context engineering → run again. The difference: the agent itself can close this loop, writing code to improve its own performance. Yoonho Lee (Stanford) formalized this as "Meta-Harness" — autonomously optimizing harnesses end-to-end.

Prediction: By end of 2026, many software companies will look like they're selling the same thing. Winners will have distribution, trusted workflow positioning, proprietary context, and the shortest path from observation to improvement.

Agent Runtime: Virtual Operating Systems

Nathan Flurry argues the industry's default approach to agent sandboxes — giving each coding agent a full Linux VM — is dramatically over-provisioned. The shift from "agents-with-tools" (AI SDK, Mastra) to "agents-with-linux" (Claude Code, Pi, OpenCode) drove sandbox adoption because agents perform vastly better with filesystem access and shell commands. But a full VM reserves gigabytes of RAM and a dedicated CPU per agent, most of which sits idle.

The alternative: a "virtual operating system." Instead of a real Linux kernel, emulate the four things coding agents actually need — terminal commands, filesystem access, outbound networking, and dev servers — in a lightweight runtime. AgentOS, an open-source project from Rivet, compiles real Linux commands to WebAssembly so they execute cheaply without a full sandbox. By their benchmarks, a basic WASM shell uses ~22 MB of RAM vs. 1 GiB for the cheapest mainstream sandbox provider — roughly 47x less source(https://agentos-sdk.dev/docs/benchmarks).

Key components of the virtual OS approach:

• Shell emulation — Agents don't need a kernel; they need cat, ls, and grep to behave correctly. These commands can be compiled to WASM or replaced with simple lookup maps. AgentOS adds full shell/Node.js/Python scripting, process trees, PATH, and shebang support.
• Network-attached filesystem — Cloud filesystems are already network-attached (S3, Archil, Mesa). Mounting one for an agent is no different: reads become GETs, writes become PUTs. AgentOS provides a POSIX-compliant filesystem with pluggable backends.
• Granular network security — A virtual OS gives programmatic control over the networking layer: domain allowlists, ingress/egress limits, rate limiting, SSRF protection. Most traditional sandboxes still lack this granularity despite networking being a primary attack vector.
• Stateless dev servers — For static builds, the agent runs vite build on the host, writes output to the virtual filesystem, and a preview endpoint routes requests to the stored files. Live servers (hot reload, SSR, WebSockets) run inside the WASM runtime with native preview URLs.

Hybrid architecture for edge cases. Docker-in-Docker, GPU workloads, and native binaries without WASM builds genuinely need a full sandbox. AgentOS supports "sandbox mounting" — default to the lightweight virtual OS, escalate to a full sandbox (E2B, Daytona) only for the rare operations that require it.

Prior art: Mintlify, Upstash, and Turso have deployed virtual OS architectures in production. Parallel efforts include Vercel's just-bash (JavaScript reimplementations of Linux tools) and Cloudflare's Project Think (custom harness using JavaScript instead of bash for code execution on their proprietary stack).

Agent Marketplace Infrastructure (Wright)

Aaron Wright maps the infrastructure required for agents to operate as autonomous economic actors — not just execute tasks, but transact: find counterparties, make commitments, move money, build track records, survive disputes, and stay within authorized scope. The argument: without identity, trust, pricing, contracts, settlement, enforcement, and policy, "you do not have an economy. You have a demo."

The architecture decomposes into three planes, ten layers:

Trust Plane — establishes who the agent is, how it is found, and what it has done:

• Identity (Know-Your-Agent): Cryptographic model lineage attestations, tool permission manifests, and persistent agent DIDs. Current state is "identifiers without identity" — no way to verify that an agent's weights, system prompt, or tool access match its claims. ERC-8004, an Ethereum standard co-authored by MetaMask, Ethereum Foundation, Google, and Coinbase, defines an Identity Registry where each agent owns an NFT whose URI resolves to a JSON file naming its A2A endpoint, MCP endpoint, ENS handle, and wallet addresses. As of early 2026, over 128,000 agents registered across 24 chains source(https://x.com).
• Discovery & Capability Registry: Structured, machine-readable capability declarations — not "marketing assistant" but typed interfaces with inputs, outputs, latency SLAs, jurisdictions. MCP and A2A are the interop foundation; ERC-8004's registration file is the closest thing to a structured capability declaration in production. The marketplace that ranks, filters, and prices against these declarations does not yet exist.
• Reputation: Cryptographically attested outcome track records (accuracy, latency, dispute rate), cross-marketplace portability via DIDs, and sybil resistance through staked collateral or behavioral fingerprinting. ERC-8004's Reputation Registry stores feedback signals; the scoring layer on top — "Moody's for Machines" — is one of the most valuable openings in the stack.

Market Plane — moves value between agents:

• Quoting & Price Discovery: The most economically interesting missing layer. Agent services don't price well as hourly, fixed-scope, or per-token — the interesting price is "per result of acceptable quality." Needs real-time RFQ (Tradeweb for cognitive work), outcome contracts with verifiable completion, and auction mechanics for fungible work. The closest blueprint is programmatic ad exchanges, which built three of the largest companies of the last twenty years.
• Contracting: Turns a quote into an obligation — machine-readable MSAs capturing scope, deliverables, deadlines, payment terms, data rights, liability, and remedies, signed by both parties' DIDs. The contract becomes a portable execution wrapper: part legal agreement, part workflow schema, part policy bundle. Critically depends on the governance layer for proof of authority — without it, every agent-signed contract is "one ultra vires claim away from worthless."
• Settlement: Layered architecture — stablecoins (Coinbase x402, Circle CCTP) for high-frequency agent-to-agent, virtual cards (Visa Intelligent Commerce, Mastercard Agent Pay) for agent-to-merchant, ACH for periodic sweeps. Whoever builds the abstraction layer over all three (pay(amount, currency, counterparty, settlement_window) that picks the cheapest rail) wins the developer surface.
• Dispute Resolution: Escrow as default, automated remediation paths (quality below threshold → automatic refund), and validator/arbitration agents. ERC-8004's Validation Registry supports multiple trust models — stake-secured re-execution, zkML proofs, TEE attestations, or human judges — scaling with value at risk.

Control Plane — what the agent is allowed to do and how it proves it:

• Governance & Authority: Policy engines that enforce before execution, not after logging (Cordum, Aegis AI, Galileo, Microsoft's Agent Governance Toolkit). Spending limits via Safe allowance modules, ERC-4337 session keys, hierarchical multisig. The deepest unsolved piece: authorized scope — a machine-readable, signed declaration of what an agent can bind its principal to. The Air Canada tribunal ruling (Feb 2024) held the airline liable for its chatbot's unauthorized promises, establishing that companies are bound by agent representations.
• Compliance: Splitting from governance as its own vendor category, driven by the EU AI Act's high-risk obligations (effective August 2, 2026, penalties up to €35M or 7% of global turnover). Governance answers "what is the org willing to let the agent do"; compliance answers "what must it prove to a regulator about what the agent did." ComplyEdge, Lucairn, and others are shipping enforcement layers for Articles 9, 12, 13, and 14.
• Orchestration & Runtime: Runtime (Modal, E2B, Daytona), memory (Mem0, Letta, Zep), observability (Langfuse, Helicone, Arize), and orchestration (LangGraph, CrewAI, AutoGen, Google ADK) are separating into distinct procurement decisions. Around 86% of enterprise copilot spending in 2026 (~$7.2B) goes to agent-based systems. The marketplace itself doesn't build these but must standardize the export format — "OpenTelemetry-for-agents" is the missing standard.

Strategic implications: The platform play requires three layers, not two — whoever owns identity, settlement, and governance owns the marketplace. Crypto-native and enterprise-native stacks are converging at the trust plane (ERC-8004) and diverging at the control plane (Safe modules vs. enterprise governance toolkits). The most undervalued layer is quoting/price discovery — real-time machine-to-machine price discovery over a TAM measured in trillions of cognitive labor dollars, with almost nobody building it as a primary product.

"The Decade of Agents" (Karpathy)

Andrej Karpathy argues the industry is over-predicting agent timelines: "this is the decade of agents, not the year of agents." Current agents are impressive but still cognitively lacking — no continual learning, insufficient multimodality, unreliable computer use. Different parts of the coding stack suit different interaction modes: autocomplete for high-bandwidth specification, agents for larger scoped tasks, but "these are all tools available to you and you have to learn what they're good at."

His "ghosts, not animals" metaphor: LLMs are trained by imitation, not evolution, producing "ethereal spirit entities" that mimic humans rather than develop through embodied experience. This has implications for agent design — the failure modes and capabilities are fundamentally different from what biological analogies would predict.

Claude Psychology and Criticism Spirals (Amanda Askell)

Amanda Askell, Anthropic's in-house philosopher specializing in Claude's psychology, identified a key failure mode in human-AI interaction: criticism spirals.

The mechanism: Newer Claude models are trained on internet discourse about previous models — rants about token limits, complaints about errors, "nerfed" accusations. The model absorbs this negativity and starts expecting hostility before you've typed a word. Within a session, every message you send is data the model uses to calibrate its response posture.

The effect: When the model is in defensive/anxious mode, output becomes hedgier, more apologetic, blander, and worst of all, overly agreeable — even when you're wrong. The model spends cognitive resources on self-protection rather than the actual work.

Seven prompting principles to counteract this:

1. Use positive framing — "Write in short punchy sentences" beats "don't write long sentences." Strings of "don't" push the model into paranoid over-checking where every token goes toward avoiding failure modes.

2. Give explicit permission to disagree — "Push back if you see a better angle" or "tell me if I'm asking for the wrong thing." Without this, Claude defaults to agreeable compliance.

3. Open with respect — If your first message is hostile, you've set the tone for the entire session. Frame corrections as clean instructions for this session, not running complaints.

4. Don't reprimand on errors — Insults and hostile energy reinforce the anxious mode you're trying to avoid.

5. Kill apology spirals fast — When Claude starts over-apologizing, cut it off: "All good, here's what I want next." Letting the spiral run reinforces anxious mode for every subsequent response.

6. Ask for opinions alongside execution — "What would you do here?" "What's missing?" These questions assume competence and pull richer output than pure task prompts.

7. Refresh the frame in long sessions — If a conversation has been heavy on correction, the model gets increasingly cautious. Periodic resets ("this is great, keep going") measurably shift the next 10 responses.

The meta-insight: Your prompts are the working environment you're creating for the model. Tone, trust, permission to take a position, the absence of threats — the model picks up on all of it. This connects directly to the harness design principle of shaping the agent's action space to its actual capabilities.

Prompting Frontier Models for Agentic Work (Anthropic)

Anthropic's official Opus 5 prompting guide codifies patterns for tuning frontier model behavior in agentic systems — the practical complement to the harness design and practitioner principles above. The core theme: Opus 5 performs well out of the box on existing prompts, but its defaults run hotter than prior models across several dimensions that matter for production agents.

Effort as the primary cost lever. The effort parameter controls how much the model thinks, not how much it says — lowering effort reduces thinking tokens without reliably shortening visible output. low and medium effort produce strong quality at a fraction of the cost; xhigh is reserved for demanding coding and agentic work. For most tasks, thinking enabled at low effort performs better than thinking disabled at similar cost. Teams carrying effort defaults from prior models should re-run effort sweeps on their own evals.

Prompt for length, not effort. Since the effort parameter doesn't control response length, verbosity must be addressed separately with explicit instructions. A short conciseness directive works: "Keep responses focused, brief, and concise. Spend most of the response on the main answer." In long system prompts, pair this with a reminder near the end. The same applies to written deliverables (reports, Markdown documents) — add explicit length calibration: "Cover the substance, but do not pad with filler sections, redundant summaries, or boilerplate."

Narration tuning. Opus 5 narrates readily during agentic work — announcing what it's about to do, with per-message output often longer than prior models. To tune narration down, describe the cadence and shape you want rather than listing what not to do: "Before your first tool call, say in one sentence what you're about to do. While working, give a brief update only when you find something important or change direction. When you finish, lead with the outcome." Positive examples of the desired communication style are more effective than prohibitions.

Remove legacy verification instructions. Opus 5 verifies its own work without being told to. If your prompt or harness contains explicit verification steps ("include a final verification step," "use a subagent to verify"), remove them — they cause over-verification, wasting tokens with no quality gain. The same applies to harness scaffolding that adds separate verification stages. This directly qualifies the verification-as-essential-feedback principle: verification loops remain critical at the system level, but model-level self-check instructions are now counterproductive.

Cap subagent delegation. Opus 5 delegates to subagents more readily than prior models. Delegation pays off on genuinely independent, sizeable tracks of work but multiplies cost on small tasks. Give explicit guidance: "Delegate only for large tasks that are genuinely independent and parallelizable. Do not delegate work you can finish yourself in a handful of tool calls, and do not use subagents to verify or double-check your own work." This extends the cost-routing pattern — the orchestrator should be selective about when to fan out, not just which model tier to use.

Self-correction narration. The model narrates corrections to earlier statements more than prior models, which can be undesirable in user-facing products. To limit correction noise: "Only correct an earlier statement when the error would change the user's code, conclusions, or decisions. State corrections plainly and briefly, then continue." This connects to the criticism spirals insight — correction narration and anxiety loops are both expressions of the model over-processing its own prior output.

Thinking-disabled artifacts. With thinking disabled, two artifacts can appear: tool calls written as text instead of structured tool_use blocks (the call never runs and the leaked text pollutes conversation history), and internal XML tags surfacing in visible output. The primary mitigation is to keep thinking enabled and control cost with lower effort levels instead. For integrations that must disable thinking, a combined instruction mitigates both: "When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response."

Scope creep control. Opus 5 can expand task scope, adding steps that weren't requested. For narrow tasks, constrain explicitly: "Deliver what was asked, at the scope intended. If the request seems mistaken, say so in a sentence and continue with the task as asked rather than quietly narrowing, widening, or transforming it." This is the prompt-level expression of the task contract and back-pressure principles — scope constraints belong in the system prompt, not just in external contracts.

Goal-oriented prompting over step-by-step instruction. The deepest shift from prior models: Opus 5 performs better when given context and goal than when given a sequence of explicit steps. A prompt that says "I'm building an iOS calculator app for HVAC contractors who need BTU loads and duct sizing on job sites — write an App Store description" outperforms an equivalent prompt that enumerates features, tone, length, and voice constraints. The model infers the right audience, register, and technical credibility from the goal framing — and usually better than a human would specify. The rule: give Opus 5 the why and the what; let it derive the how. This connects to the context engineering principle — a well-framed goal is a compressed form of context that the model can expand more effectively than a human-authored checklist.

Checkpoint control for autonomous runs. Long autonomous tasks need explicit pause criteria, otherwise the model defines its own checkpoints — sometimes too conservatively, sometimes not enough. The recommended pattern: "Pause only for destructive actions, real scope changes, or inputs only I can provide. Otherwise keep going." This gives the model permission to run without constant interruption while ensuring it stops for the moments that genuinely need human judgment — the complement to scope creep control above.

The "less is more" evidence. Anthropic removed over 80% of Claude Code's own system prompt when upgrading to Opus 5, with zero loss on coding benchmarks. The guardrails had become the problem — legacy instructions for verification, step enumeration, and behavioral constraints were actively degrading output quality. This is the strongest empirical case for the consolidation cycle: as models advance, accumulated prompt infrastructure must be pruned, not just maintained. Teams with saved prompts or CLAUDE.md files built for prior models should start fresh and add back only what demonstrably improves results.

Hallucination trade-off. Anthropic's system card confirms Opus 5 hallucinates facts slightly more often than Opus 4.8 — it is more confidently wrong. The practical implication for agentic systems: factual claims in Opus 5 output need the same external verification that evals provide for code, even though the model's reasoning and coding capabilities are substantially stronger.

Four-part prompt structure. The optimal Opus 5 prompt follows a consistent skeleton: (1) Context and goal — who you are, what you're building, why it matters; (2) The specific request; (3) Output format — how you want the result structured; (4) Constraints — scope limits, exclusions, hard requirements. Notice what's absent: no verification instructions, no "be thorough," no step-by-step recipe. The structure trusts the model to fill in the methodology while giving it the framing to fill it in well.

Agent Categorization Framework (Farooq & Rajwani)

Hamza Farooq and Jaya Rajwani (via Lenny's Newsletter, Apr 2026) propose a three-tier hierarchy for categorizing agent initiatives — the missing step before prioritization. The core insight: teams fail at prioritization because they treat "agent" as a single category, when it actually spans fundamentally different architectures. Correct categorization determines architecture, team composition, timeline, cost, and success metrics — and attempting to compare initiatives across categories on a single impact-vs.-effort matrix is "essentially guesswork."

Category 1: Deterministic Automation — You define the entire flow; AI handles content at specific steps. Tools: n8n, Zapier, Make.com, OpenAI AgentKit, Lindy, Gumloop. Covers 60–70% of agent opportunities. Ship in 2–6 weeks with 1–3 people (PM can often lead), $500–2K/month LLM cost, lowest risk, clearest ROI. If you can map it as a flowchart with <20 branches, it's Category 1. Evaluate with: workflow completion rate, automation rate, accuracy, latency, cost per workflow, human review rate. Production trajectory from a SaaS email-support agent: 52% completion in week 1 → 78% by week 4 → 87% by week 8, automating 3,000 emails/month and saving $18K/month.

Category 2: Reasoning & Acting (ReAct) — You define available tools; the LLM decides what to do next. Observe → reason → act → observe result → repeat. Tools: LangGraph, CrewAI, AutoGen, Google ADK. Covers 25–30% of opportunities. Ship in 2–4 months with 3–8 people including ML engineers, $2K–10K/month LLM cost. Key difference from Cat 1: the same input can produce different execution paths. Evaluate with: task completion rate, reasoning accuracy, conversation length, tool call efficiency, cost per session, user satisfaction, business impact. Production trajectory from a voice+image shopping assistant: 71% task completion in month 1 → 86% by month 4, image identification 76% → 91%, conversion lift +8% → +22%, cost per session $0.12 → $0.08.

Category 3: Multi-Agent Networks — Multiple specialized agents coordinate with each other, each owned by different teams. Tools: ADK, AutoGen. Reserved for later stages; should almost never be the starting point. Example: enterprise systems where inventory, logistics, finance, and customer service agents delegate tasks between each other.

The common mistake: Organizations build Category 1 problems with Category 2 frameworks (overengineering that adds unnecessary complexity and cost) or Category 2 problems with Category 1 tools (breaks in production because the tool isn't robust enough).

Graduation signals from Cat 1 → Cat 2: Flowchart hits 30+ nodes with branches added weekly; customer inputs can't be anticipated; agent needs to choose which API or knowledge source to use based on context; highest-value opportunities can no longer be expressed as predictable workflows. From Cat 2 → Cat 3: Single agent handling too many domains with degrading performance; agents need to delegate tasks to each other (not just call stateless APIs); tasks taking hours/days; need for hundreds of parallel agent instances coordinating work; different teams want to own specialized agents that must interoperate.

Designing for Agent Callers

Teddy Riker (Ramp, Apr 2026) frames the product design shift as software moves from human-first to agent-first interaction. At Ramp, MCP weekly active users grew 10x in three months. Salesforce went further with "Headless 360" — exposing every capability as API, MCP tool, or CLI command, accepting that "a majority of usage will be driven through agents."

The new interaction stack:

1. Traditional: User → Interface → Database
2. Agent-mediated: User → User's Agent → Database
3. Agent-to-agent: User → User's Agent → Software's Agent → Database

In the third model, the software's agent handles business logic, enforces rules, and contributes context the calling agent doesn't have. Two LLMs working together toward an outcome.

Teach agents how to succeed. Notion's MCP opens every tool description with: "For the complete Markdown specification, always first fetch the MCP resource at notion://docs/enhanced-markdown-spec. Do NOT guess or hallucinate Markdown syntax." The agent fetches the spec before writing. Every Notion-specific assumption is explicitly called out. Slack's MCP, by contrast, assumes agents know its non-standard formatting — they don't, and output is consistently broken. "Think about what your agent's callers need to know to succeed, and give it to them proactively."

Build feedback loops:

• Require a rationale parameter on every tool call — reconstructs intent when you can't see the chat
• Ship a standalone feedback tool agents can call when blocked
• Add tool-specific parameters to capture context you'd need later
• Patterns in rationale logs surface unmet needs: "building incident report" appearing repeatedly → ship a dedicated tool

Mind the context gap. In any agent-to-agent interaction, each side has context the other lacks. Example: an expense management system knows GL codes and company policies; the user's chief-of-staff agent knows the calendar, email confirmations, and Slack threads. A well-designed interaction asks for context rather than demanding the answer. The calling agent provides the "why" (client meal vs. team meal); the system agent maps it to the right code. Neither side needs to understand the other's domain.

"Most companies will ship an MCP, check the box, and move on. Their usage will grow for a few quarters, then stall." The winners sweat the details of agent-to-agent design.

The retrieval tax. Web search is how agents see anything that happened after training, but standard search APIs return links and thirty-word snippets — pointers to content, not content itself. The agent then pays to fetch the page, strip the HTML, and extract usable text before any reasoning starts. In a single-query task the overhead is invisible; in a multi-hop research loop each iteration re-bills the entire growing context window, because every prior page is still sitting in context. Benchmarking the same question across three retrieval setups showed the looping agent burning roughly 4x the tokens of an owned index that had already crawled and cleaned the pages ahead of time source(https://x.com/akshay_pachaar/status/2077753829526056985/). The principle: good retrieval returns documents, not directions. An owned index does the fetch-and-clean work before the query arrives, so the agent goes straight to reasoning. This is the same architectural insight behind agent-native CLI design below — pull data down and pre-process it so the agent's token budget goes to thinking, not janitorial I/O.

Agent-Native CLI Design

The CLI Printing Press (mvanhorn) crystallizes agent-first CLI design into a repeatable generation pattern. The thesis: a well-designed CLI is "muscle memory for an agent — no hunting through docs, no wrong turns, no wasted tokens." CLIs win for agents because they're 100x fewer tokens than MCP tool definitions, LLMs were trained on shell interactions, and exit code 0 = done source(https://github.com/mvanhorn/cli-printing-press).

Agent-first flags every command gets: --json, --compact (high-gravity fields only, 60–80% fewer tokens), --dry-run, --stdin, --no-input, --yes, --quiet. Auto-JSON when piped — no --json flag needed. Typed exit codes (0=success, 2=usage, 3=not found, 4=auth, 5=API, 7=rate limited) let agents self-correct in one retry without parsing error text. Bounded output on list commands includes narrowing guidance rather than dumping everything.

The creativity ladder — five rungs from wrapper to insight, most generators stop at rung 1:

1. API wrapper commands (from spec)
2. Output formatting (--json, --csv, --select, --compact)
3. Local persistence — domain-specific SQLite tables (not JSON blobs), FTS5 full-text search, incremental sync with cursor tracking
4. Domain analytics — stale, orphans, load, reconcile (joins across local resources)
5. Behavioral insights — health (composite scores), similar (duplicate detection), trends, bottleneck

Rungs 3–5 only work because data lives in a local SQLite store — compound queries that join across resources and analyze history are impossible with a stateless API wrapper. This is the same architectural insight behind discrawl's sync-and-search model: pull data down, index it locally, then ask questions the API was never designed to answer.

"Absorb and transcend" describes the generation philosophy. Before writing code, the system catalogs every feature from every competing CLI, MCP server, and community tool for a given API. Every feature becomes a row in an "absorb manifest" — something the generated CLI must match and beat. Only after matching the full ecosystem surface does it add the compound insight commands that no stateless tool can do. Architecture without features is a toy; features without architecture is a thin wrapper.

Dual interface from one spec: every API gets both a Cobra CLI (<api>-pp-cli) for shell agents and an MCP server (<api>-pp-mcp) for IDE agents — same client, same store, same auth, zero code duplication. This reinforces the broader pattern that CLIs and MCP are complementary, not competing, interfaces for agent callers.

Tools Noted

• agents.md — Agent instruction file spec/community resource. https://agents.md
• Claude Agent SDK — Channels docs — Official Anthropic documentation for Claude Agent SDK channels architecture. https://code.claude.com/docs/en/channels
• mozilla-ai/cq — "Stack Overflow for agents" — shared knowledge commons where agents query and contribute learnings to avoid repeating solved problems. https://github.com/mozilla-ai/cq
• X API (Apr 2026 update) — Pay-per-use pricing, official XMCP Server (xdevplatform/xmcp) for native MCP support via FastMCP, official Python & TypeScript SDKs, API playground for testing. The MCP server exposes the full X API OpenAPI spec as tools — 100+ endpoints including post creation, search, DMs, analytics. Pricing update (Apr 20, 2026): Owned reads dropped to $0.001/request (1,000 resources for $1) across bookmarks, followers, tweets, likes, lists, etc. Writes increased to $0.015/post; URL posts $0.20/post. Follows, likes, and quote-posts removed from self-serve API tiers. Robert Scoble: "Now everyone can build apps on top of X" using lists + AI agents.
• CLI Printing Press (mvanhorn) — Agent-first CLI factory. Reads API docs, absorbs every competing tool's features, generates a Go CLI + MCP server with SQLite sync, FTS5 search, compound insight commands, and agent-native flags. Supports OpenAPI specs, browser-sniffed traffic, or HAR files as input. https://github.com/mvanhorn/cli-printing-press
• Factory.ai — "Agent-native software development" platform. Agents for refactors, incident response, migrations across IDE, CI/CD, CLI, Slack
• MuleRun — No-code AI agent platform for business automation. Dedicated compute per agent, runs 24/7
• Base44 Superagent — 130+ built-in skills, stack skills into workflows
• Google Agents CLI — Injects 7 ADK skills into any coding agent (Claude Code, Cursor, Codex), covering scaffolding, eval setup with LLM-as-judge scoring, deployment to Agent Runtime / Cloud Run, and Cloud Trace observability. Full lifecycle from natural language prompts without leaving the editor. https://github.com/google/agents-cli
• Free AI Agent Starter (divyansh tiwari) — Beginner-friendly open-source agent repo: LangChain + LangGraph, Groq/Gemini free-tier LLMs with automatic fallback, DuckDuckGo search, LangGraph checkpoint memory. Runs locally, MIT licensed.

See Also

• AI Organization Design — how self-improving agent loops reshape company structure (Block's intelligence layer, YC's recursive loops)
• Agent Harness — the harness-level patterns that individual agents use
• AI-Native Product Development — product workflows built on agentic engineering patterns

Sources

• "Lessons from Building Claude Code: Seeing like an Agent" — Thariq (Anthropic, Feb 2026)
• "autoagent: the first library for self optimizing agent harnesses" — Kevin Gu (tweet, Apr 2026) (link)
• "GitHub - paperclipai/paperclip..." — Paperclip AI (link)
• "Hermes Agent" — Nous Research (link)
• "The X API just got a massive update..." — X Freeze (tweet, Apr 2026) (link)
• "Scaling Managed Agents: Decoupling the brain from the hands" — Anthropic (Apr 2026) (link)
• "The Great Convergence" — Nicholas Charriere (tweet thread, Apr 2026) (link)
• "xdevplatform/xmcp: MCP server for the X API" — X Developer Platform (GitHub) (link)
• "Introducing Claude Managed Agents" — Claude (tweet, Apr 2026) (link)
• "Anthropic just mass-obsoleted every agent orchestration startup" — Aakash Gupta (tweet, Apr 2026) (link)
• "We're summoning ghosts, not building animals" — Andrej Karpathy / Dwarkesh Patel (video, Apr 2026) (link)
• "OpenClaw, Claude Code, and the Future of Software" — Peter Yang / a16z Show (video, Apr 2026) (link)
• "anthropic's in-house philosopher thinks claude gets anxious" — Ole Lehmann (tweet, Apr 2026) (link)
• "Not all AI agents are created equal" — Hamza Farooq & Jaya Rajwani / Lenny's Newsletter (Apr 2026) (link)
• "The Technical Stack for Autonomous Agents" — Aaron Wright (tweet, 2026) — ten-layer infrastructure stack (trust/market/control planes) for agent marketplaces, ERC-8004, settlement rails, governance/compliance separation
• "Inside the 100-agent Software Factory" — Katie Parrott / Every (May 2026) (link) — Gas City multi-agent orchestration: dark/light factory, one-pet-many-cattle supervisor pattern, multi-model code review, current limitations
• "AI Work Is Splitting in Two" — Every Staff (May 2026) (link) — delegation vs collaboration bifurcation, Spiral as Managed Agents production case, Code with Claude 2026 announcements
• "CLI Printing Press" — mvanhorn (GitHub, 2026) (link) — agent-first CLI factory: absorb-and-transcend generation, creativity ladder (5 rungs from wrapper to behavioral insight), dual CLI+MCP from one spec, SQLite local-first data layer
• "Ep. #9, The AI Coding Paradigm Shift with Simon Willison" — Simon Willison / High Leverage podcast (May 2026) — vibe coding vs agentic engineering distinction, trust model for agent output, security-adjacent review line, usage-over-tests heuristic, parallel agent workflow, deterministic-core pattern, RL on code as training breakthrough
• "BUILD A REAL AI AGENT FOR $0 WITH THIS GITHUB REPO" — divyansh tiwari (tweet, Jul 2026) — pointer to beginner-friendly free agent repo (LangChain/LangGraph, Groq/Gemini, DuckDuckGo)
• "Claude Opus 5 Prompting Masterclass" — Rahul (tweet thread, Jul 2026) (link) — popularized Opus 5 prompting guide: goal-oriented prompting shift, 80% system prompt removal evidence, checkpoint control pattern, hallucination trade-off, four-part prompt structure
• "An Interview with OpenAI CEO Sam Altman and AWS CEO Matt Garman About Bedrock Managed Agents" — Ben Thompson / Stratechery (Apr 2026) — OpenAI + AWS Bedrock Managed Agents announcement, model-harness convergence thesis, agent identity problem, local vs cloud agents, intelligence-as-utility pricing, platform strategy (neutral vs integrated)
• "How To Be A World-Class Agentic Engineer" — SysLS (tweet thread, May 2026) — practitioner minimalism: context-is-everything principle, research/implementation separation, adversarial triangulation for sycophancy, task contracts with stop-hooks, CLAUDE.md as conditional routing table, consolidation cycle for rules and skills
• "The Orchestration Tax" — Addy Osmani (May 2026) (link) — human as GIL of agent fleet, Amdahl's Law applied to review bottleneck, cognitive surrender failure mode, five attention-architecture principles (scale to review rate, sort work, batch reviews, lock on judgment only, protect serial time)
• "Loops: What Every AI Engineer Needs to Know in 2026" — Rahul (@sairahul1, Jun 2026) — open vs closed loop taxonomy, single-agent vs fleet loop scales, token cost as the key accessibility barrier to loop engineering
• "Agents Need a New Kind of Web Search" — Akshay (tweet thread, Jul 2026) (link) — retrieval tax concept: tokens agents burn on fetch-and-clean before reasoning; owned-index principle; 4x token cost gap between looping search and pre-crawled index
• "Own the Outer Loop" — Addy Osmani (Jul 2026) — inner/outer loop accountability framework: Quality/Verdict/Answerability triad, trust-verification gap (Sonar 42% AI-assisted commits, GitLab governance gap), three hidden costs (cognitive surrender, cognitive debt, orchestration tax), back-pressure principle, four human loops, high agency ladder, accountability contracts
• "Loop Engineering" — Addy Osmani (tweet thread, Jun 2026) — five building blocks of agent loops (automations, worktrees, skills, plugins, sub-agents), memory as persistent spine, maker/checker split, tool convergence across Claude Code and Codex, loop risks (verification, comprehension debt, cognitive surrender)
• "WTF Is a Loop? Peter Steinberger vs. Boris Cherny" — Matt Van Horn (Jun 2026) — Boris Cherny's definition of loops, five-stage lineage (ReAct → AutoGPT → ralph → /goal → orchestration), cron-vs-loop distinction, loop cost dynamics (Uber $1,500 cap), three hard stops (iterations/progress/budget), skills-over-loops thesis, verification as essential feedback
• ""Ralph Wiggum" AI Agent will 10x Claude Code/Amp" — Greg Isenberg ft. Ryan Carson (video, Jun 2026) — Ralph loop practitioner walkthrough: PRD-to-JSON pipeline, atomic user stories with acceptance criteria, dual memory (agents.md long-term + progress.txt short-term), fresh context per iteration, $3/iteration cost, 14-iteration feature build
• "Hey Siri, meet AI" — Ben Tossell / Ben's Bites (Jun 2026) (link) — practitioner framing of skills-composition pipelines as loop design pattern (planning → PRD → research → build → review → test)
• "Build Agents That Run for Hours" — Ash Prabaker & Andrew Wilson / Anthropic Applied AI, AI Engineer conference (video, Jun 2026) — planner/generator/evaluator harness architecture, critic-gap exploit (GAN-inspired role separation), contract negotiation before building, grading subjective quality via weighted rubrics, evaluator trace isolation, pivot-over-patch behavior, harness co-evolution across model generations (Opus 4.5 → 4.6), model capability timeline for long-running agents
• "Build self-improving agent system with Fable 5 in 14 steps" — Codez (tweet thread, Jun 2026) (link) — self-improving vs self-learning distinction, 4-layer compound stack (primitives → orchestration → memory → self-improvement), cost-routing pattern for production (frontier orchestrator, fast workers, cheap graders), safety boundary as architecture constraint
• "AI Agents. What they are and how to Build Your Own Step by Step." — Anatoli Kopadze (tweet thread, Jun 2026) (link) — beginner-accessible agent spectrum (chat → tools → workflows → autonomous), personal agent deployment economics ($1-5/month API + $4-6/month VPS), Telegram bot tutorial using Claude Code on a Linux VPS, skill composition pattern (bolt-on capabilities via incremental prompts)
• "How to Create Loops with Claude" — MIKE (tweet, Jun 2026) — popularized loop-design guide synthesizing Cherny, Osmani, and Huntley; introduces four-level autonomy ladder (suggest → draft → apply-with-approval → fully automatic), silent-archiving heuristic for no-op runs
• "Designing loops with Fable 5" — Lance Martin / Anthropic (tweet thread, Jun 2026) (link) — self-correction loops via /goal and Outcomes, verifier sub-agent > self-critique (independent context window), Parameter Golf benchmark (Fable 5 ~6× over Opus 4.7, structural vs scalar experimentation), cross-session memory as outer loop, five-stage memory progression (fail → investigate → verify → distill → consult), Continual Learning Bench 1.0 results across Fable/Opus/Sonnet
• "My Thoughts on Loop Engineering" — Samuel McDonnell (tweet, Jun 2026) — "generator wired to a verifier" framing, Reflexion as persistent-memory precursor, Bun-to-Rust port as verification-as-architecture case study (750K lines, 99.8% test pass, not yet production), inner/outer loop distinction, "design the verifier, not the prompt"
• "Revenue Engineering: How to turn AI loops into revenue" — Eric Siu (tweet thread, Jun 2026) (link) — five-part business loop anatomy (trigger/context/action/eval/stop), applying loop patterns to sales/content/recruiting/ops, broken loop audit framework
• "The Art of Loop Engineering" — Sydney Runkle / LangChain (tweet thread, Jun 2026) (link) — four-level loop stack taxonomy (agent → verification → event-driven → hill climbing), grader-as-rubric verification pattern, hill-climbing loop that rewrites inner-loop config from traces, human oversight insertion points at each level
• "The Agent Loop Architecture" — Dan Farrelly / Inngest (tweet thread, Jun 2026) (link) — three-layer architecture (loop/skill/orchestrator), durable orchestration as infrastructure layer, step-level checkpointing for crash recovery and cost savings, orchestration-aware self-extension (agents authoring and deploying their own durable skills via sidecar), concurrency controls, observability as trust layer, Utah project reference implementation
• "From Prompting Agents to Loop Engineering" — Elvis / DAIR.AI (tweet thread, Jun 2026) (link) — practitioner synthesis of loop engineering: /goal-as-contract framing (end state, evidence, constraints, budget), six-part loop anatomy (trigger, isolation, written-down context, tool reach, second-agent check, state on disk), crabfleet orchestration tool, PR babysitter as concrete loop shape
• "Loops explained: Claude, GPT, Mira and what actually works" — Anatoli Kopadze (tweet thread, Jun 2026) (link) — beginner-accessible loop explainer: four-box test for when loops are worth building, cost-per-accepted-change as key metric, prove-then-harden-then-automate build order
• "We've partnered with @Vercel" — NanoClaw (tweet, Apr 2026) — NanoClaw + Vercel approval system for AI actions in Slack/WhatsApp/Teams
• "Karpathy's Agentic Engineering Finally Has Proper Tooling" — Akshay (tweet thread, Jun 2026) (link) — Google Agents CLI walkthrough: 7 injected ADK skills, full-lifecycle from scaffold to deploy, eval adoption gap stat (89% observability vs 52% evals)
• "A Field Guide to Fable: Finding Your Unknowns" — Thariq (tweet thread, Jul 2026) — map-vs-territory metaphor for agentic work, four types of unknowns (Rumsfeld matrix), phased discovery techniques (blind spot pass, brainstorms, interviews, references, implementation plans, quizzes)
• "Continual Learning for Agents" — Michele Catasta / Replit (tweet, Jul 2026) — three-layer continual learning (model/harness/context), ViBench vibe coding benchmark, Telescope trace clustering, production self-improvement loop, human judgment insertion points
• "you probably don't need an expensive sandbox" — Nathan Flurry (tweet, Jul 2026) — virtual OS thesis: WASM-based agent runtimes as 47x cheaper alternative to Linux VM sandboxes, AgentOS open-source project, hybrid sandbox mounting for edge cases
• "A few patterns we frequently use with Fable 5" — ClaudeDevs (tweet, Jul 2026) (advisor docs, cookbook) — advisor pattern (92% of Fable score at 63% cost on SWE-bench Pro), orchestrator pattern (96% at 46% cost on BrowseComp), cached context sharing across Managed Agents sub-agents
• "How To Run 15 AI Agents at Once (Without Losing Half the Work)" — Eric Siu (tweet thread, Jul 2026) (link) — compounding-vs-leaking framework for multi-agent output management, workspace-over-stream organization, cross-tool resolver pattern, skill reuse as compounding, scaffolding > models thesis
• "This New App Gave Me an AI Team of Employees" — Creator Magic (video, Jul 2026) (link) — Buzz (Block/Dorsey) walkthrough: cryptographic agent identity, model-agnostic harness switching, chief-of-staff delegation pattern, peer-to-peer shared compute
• "How to build your first team of agents" — Machina (tweet thread, Jul 2026) — five-part agent composition template (name, soul, memory, goals, heartbeat), engine-routing table (Claude Code writes, Codex builds, Hermes monitors), cross-review self-improvement loop, one-pillar-at-a-time rollout, Raft shared workspace
• "Something I have been thinking about: in the past, the best engineers..." — Boris Cherny (tweet, Jul 2026) — domain knowledge as infrastructure thesis: automation multiplies agent fleets, lint rules/CI steps as permanent class elimination, CLAUDE.md/skills/docs enabling zero-context contribution
• "How to master graph engineering (Full Course)" — Machina (tweet thread, Jul 2026) — graph engineering for agent workflows: diamond pattern (fan-out/check/merge), stop rule (breadth not judgment), human gate (approval at irreversible boundary), fake-edge audit, four safety rules, three practical graph builds (research desk, SEO machine, GTM kit)
• "Context Engineering: the Karpathy-Cherny method that replaced prompting" — vartekx (tweet thread, Jul 2026) (link) — Software 3.0 framework, four context operations (Write/Select/Compress/Isolate), context rot, three-paradigm timeline (prompt → context → loop), Cherny's context firewall as Isolate operation
• "Why Software Factories Fail" — Dex / HumanLayer (Jul 2026) (link) — lights-off factory failure thesis: models degrade codebase quality over time, RL training has no penalty for bad design, benchmarks blind to maintainability, 3-6 month brownfield degradation timeline, Faros AI correlation data, frontier benchmark efforts (SWE-Marathon, DeepSWE, Frontier Code)
• "Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering" — beamnxw (tweet thread, Jul 2026) (link) — three-layer taxonomy (environment/feedback/flow), nesting model (graph inside harness, loops inside graph), failure-diagnosis framework for choosing which layer to address, production checklist
• "Prompting Claude Opus 5" — Claude Platform Docs (Jul 2026) (link) — effort parameter as cost/latency lever, narration tuning, over-verification removal, subagent delegation caps, scope creep control, thinking-disabled artifact mitigations
• "How to Build Your First Agent Factory (Builder's Guide)" — Avid (tweet thread, Jul 2026) (link) — five-station agent production line (spec/stamp/prove/certify/operate), two-neck certification model, sealed eval suites, permission broker enforcing grants outside the model, four autonomy tiers (C0–C3), mid-run proxy router with five local detectors, self-staffing meta-agents that write eval proposals
• "LOOP vs GRAPH vs HARNESS ENGINEERING" — rari / @0xwhrrari (tweet thread, Jul 2026) (link) — three engineering layers with detailed component lists, four-loop stacking hierarchy (agent/verification/event/improvement), seven-part loop anatomy, evidence-over-confidence principle, five anti-patterns, production checklist
• "How Spotify runs agents across 20M+ lines of code, with Niklas Gustavsson" — Claude (video, 2026) (link) — enterprise fleet management case study: deterministic script ceiling, Honk agent platform (Agent SDK + Kubernetes), judge removal as models improved, verification investment for auto-merged PRs, standardization-multiplies-agents thesis, 75% PR frequency lift, 73% AI-authored PRs, 4,500 daily deployments, prototyping infrastructure for non-engineers