Loop Engineering: The Session Illusion. Managing Loop State.
When the Agent Forgets: Why Production Loops Need Durable State Outside the Model
The demo goes perfectly. You build an agent loop, run it against a batch of GitHub issues, and watch it triage forty items in ten minutes. Labels applied, priorities set, comments written. You close your laptop feeling good.
The next morning, you open the repository and find the agent did it again. All forty items. Labels re-applied. Comments duplicated. Priority flags toggled back to defaults in some cases. The agent had no idea it was on its second pass.
This is the moment engineers encounter the AI agent state problem. Not as a concept: as a Monday-morning incident.
The failure is jarring because everything looked right during the session. The agent remembered context from one step to the next. It tracked which issues it had already touched. It gave coherent answers about what it had done. The illusion of memory was so convincing that skipping external state tracking felt reasonable.
It wasn’t a shortcut. It was a bet against the architecture.
What You Observed vs. What the Agent Actually Stores
Inside a single session, the agent appears to have memory. Ask it “what did you do five steps ago?” and it answers correctly. That answer is accurate, but the mechanism behind it has nothing to do with memory inside the model itself.
Every API call resubmits the full conversation transcript. (Anthropic’s own documentation is direct: “The Messages API is stateless, which means that you always send the full conversational history to the API.”) The model sees everything that happened in the session because everything that happened is in the input. The transcript is the memory. When the session ends, the transcript is gone. The next session starts from a blank slate, and the model has no way to distinguish a first run from a hundredth.
This is the Session Illusion: a persistent conversation window creates the experience of continuity, while the underlying model is stateless on every call.
Engineers who build their first agent loop inside a chat interface encounter this illusion early and powerfully. The chat interface preserves session history across browser refreshes and, in some cases, across days. That history is a chat UI feature, not a property of the model. Swap out the chat interface for a direct API loop and the distinction becomes unavoidable.
Why AI Agent State Matters for Production Loops
A single-session agent loop can get away with no external state. The transcript carries everything the agent needs, and the run is short enough that the context window holds it all. This is exactly the condition that makes the demo go perfectly.
Production loops break both constraints. They run across sessions: scheduled overnight, triggered by CI pipelines, resumed after a crash. And they process enough items that the context window fills long before the work is done. At that point, the agent is not just working from an incomplete transcript. It is working from no transcript at all.
The result is not a graceful degradation. The agent redoes completed work, reprocesses items it already handled, and rediscovers facts that the prior run established at token cost. It has no checkpoint to resume from after a failure. It cannot coordinate safely with a parallel agent because neither has access to a shared, authoritative record of what has been done.
These are not edge cases. They are the predictable, documented failure modes of any Agentic AI loop that omits external state.
The Central Question: How Production AI Agents Solve the State Problem
If you are a paid subscriber, thank you. Your support makes this work possible.
If you are a free subscriber and find these articles useful, please consider upgrading. A paid subscription is $80 per year or $8 per month.
Free subscribers typically receive access to the full versions of paid articles after one to two months. Some articles are also shared on my Medium after two weeks to a month.
One question cuts through all of this: how do production loop implementations actually solve it?
The answer is consistent across every real implementation examined here. They all arrived at the same place independently. That convergence is not an accident; it is a signal that the solution is architecturally necessary, not a preference. Addy Osmani’s June 2026 taxonomy of loop engineering formalizes this as the sixth and final primitive: external state, defined as “a markdown file, a Linear board, or anything that lives outside a single conversation.” The accompanying observation puts the mechanism plainly: “The model forgets everything between runs. The repo doesn’t.”
Before examining what they did, it is worth understanding exactly why the model forgets. The mechanism is precise, and understanding it once makes every practical decision easier.
When teams building different tools for different purposes all land on the same structural answer, the answer is not a preference but a constraint. That is where the architecture begins.
Why AI Agents Forget: The Stateless LLM Architecture
The forgetting is not a bug. For production AI agents, the memory loss between sessions is not a configuration issue, a missing flag, or a feature that will be added in the next model version. It is a design property of transformer-based large language models, and it will not change.
Understanding the mechanism takes about five minutes and saves weeks of debugging.
The LLM Context Window Is the Only Agent Memory
Every call to a language model API passes a context window: a block of tokens that includes the system prompt, the conversation history, any tool results, and whatever else the engineer includes. The model reads that block, produces a response, and stops. No information from that call persists inside the model. The model weights do not update. No internal state is written anywhere.
The next API call passes another context window. If the previous conversation is included in that window, the model can respond as if it remembers it, because it does, in the same way you remember a document you are currently reading. Remove the document, and the memory is gone.
This is exactly what happens between sessions. The conversation transcript is not automatically re-submitted on the next run. The engineer’s loop code would have to explicitly include it, and for long-running loops, including the full transcript is not feasible: context windows have token limits, and a loop that processes hundreds of items will exhaust any window long before it finishes.
The model’s “memory” within a session is the transcript being replayed on each call. The model’s “memory” across sessions is whatever the engineer puts in the context window of the new session. If nothing is put there, the model starts fresh.
In-Context Memory vs. Cross-Run Durable State
Engineers constantly confuse two distinct problems here. They sound similar. They require completely different solutions.
In-context memory is the practice of enriching a single run with retrieved information: using RAG to pull relevant documents, injecting tool results from earlier in the session, or summarizing prior steps to fit within the context window. In-context memory improves what the model can do within one run. It does nothing for cross-run continuity.
Cross-run durable state is information that persists outside the conversation context in a system that survives process restarts. It is not in the context window; it is in a file, a database, a ticket system, or a git repository. The agent reads it at the start of each run and writes updates back before or after each significant step.
Conflating these two is one of the most common mistakes in early AI agent loop implementations. Engineers reach for RAG or in-context summarization to solve a state problem that those tools cannot address. In-context memory makes a single run smarter. Durable state makes multiple runs coherent.
Why Stateless LLM Design Is a Feature, Not a Bug
The statelessness of language models is not an oversight. According to one published analysis of LLM architecture, it is what allows the same model weights to serve millions of simultaneous users: with stateless inference, any available compute resource can handle any incoming request, with no requirement for sticky routing or per-user state management inside the model. [1] Persistent per-user state inside the model would require personalized weights for every user, technically and economically infeasible at current scales. The context window approach cleanly separates the stateless model from the stateful application layer.
This separation is the engineer’s responsibility to bridge. The model cannot hold state between runs. The loop infrastructure must.
Addy Osmani’s June 2026 six-primitive loop taxonomy makes this explicit. [2] It classifies Memory/State as Primitive 6 (the sixth required component of any production agent loop) and defines it as “a markdown file, a Linear board, or anything that lives outside a single conversation.” The accompanying note is blunt: “The model forgets everything between runs. The repo doesn’t.”
That framing shifts responsibility clearly. The repo (or the database, or the ticket system) is the memory. The model is a reasoning engine that operates on whatever memory you hand it.
What This Means for Your AI Agent Loop
Once you understand the mechanism, the engineering task is clear: the loop must read the durable state at startup, use it to skip already completed work, and write updates back after each significant action.
The exact form of that durable state (a file, a ticket, a database record) is a design choice with real trade-offs. Whether to have it is not. Every production loop that omits external state will eventually re-do work, fail to resume, or burn tokens on re-discovery.
The implementations that follow all learned this. What is interesting is that they learned it independently, and they all reached the same conclusion.
That pattern of independent convergence is itself evidence. Four implementations, built independently across different teams and technology stacks, each arrived at the same conclusion through practice rather than theory.
Convergent Evidence: What Every Production AI Agent Loop Does
There are hundreds of opinions about how Agentic AI loops should be built. There are far fewer production loop implementations with real usage and documented behavior. The ones that exist tell a consistent story.
Four implementations are examined here. They were built independently, by different teams, with different goals, using different technology stacks. Every one of them independently arrived at the same answer: durable external state is not optional.
cobusgreyling/loop-engineering
cobusgreyling/loop-engineering is a reference repository of production loop patterns with 3,900 stars and 509 forks as of June 2026. Every single one uses a state tracker. None of them rely on the conversation context as the sole record of what has been done.
Three patterns are worth examining closely.
Daily Triage writes triage decisions to a markdown file in the repository. At the start of each run, the loop reads the file to determine which items are already triaged. At the end of each step, it appends a record. The state lives in the repo. If the process crashes, the next run picks up where the previous one left off.
CI Sweeper reads CI failure history from an external source and updates Linear tickets. The Linear tickets are the state store. The agent does not need to re-examine CI runs it has already processed because the ticket records its prior decisions.
Issue Triage reads GitHub Issues state (labels, assignees, comments) and writes updates back. The GitHub Issues API is the state. The agent can always recover its prior work by reading the current issue state.
In each case, state lives in the repo, in a ticket system, or in a third-party API. It never lives only in the conversation.
AlessandroAnnini/agent-loop
AlessandroAnnini/agent-loop takes a different approach to persistence. External configuration is stored at ~/.config/agent-loop/mcp.json. This file contains MCP server definitions (the agent’s toolset) and persists across restarts. When the agent starts up, it reads this file and reconstitutes its tool configuration without any user intervention.
This is a clean example of configuration-as-state: the agent’s capability set is durable, not rebuilt from scratch on each run.
The agent-loop project also implements a repetition detector using SHA-256 hashing. The detector detects loops: situations where the agent is about to repeat an action it has already taken in the current run. This works well within a single session.
The limitation is documented: the hash state is in-process only. It is per-run memory. When the session ends, the hashes are gone. If the agent runs again, it has no memory of what it hashed in the previous run. Cross-run deduplication requires external state. This is an explicit design boundary, not an accident. The SHA-256 repetition detector solves the in-session problem. The cross-run problem remains open unless the application layer provides a persistent hash store.
Anthropic Claude Managed Agents (CMA)
Anthropic’s Claude Managed Agents (CMA) represent the most architecturally explicit treatment of the AI agent state problem among the implementations examined here. CMA launched June 9, 2026.
In the CMA model, a coordinator agent orchestrates multiple sub-agents. All sub-agents share a sandbox, a filesystem, and vault credentials. The shared filesystem is the primary state persistence mechanism within a deployment. When a sub-agent writes a result to a file, every other agent in the sandbox can read it. When the coordinator needs to track progress across Outcomes iterations (the CMA retry and continuation primitive), it reads and writes files in the shared filesystem.
This is State-in-a-File at the infrastructure level. Anthropic did not implement a complex database or a ticket system. They gave agents a shared filesystem and made that the state store.
The important caveat: this state persists across Outcomes iterations but does not survive sandbox teardown. If the sandbox is destroyed, the filesystem state is lost. CMA deployments that need cross-sandbox durability require additional persistence outside the sandbox.
Claude Code: /goal, /loop, /schedule
Claude Code’s own tooling provides the clearest illustration of the design boundary between session state and durable external state.
/goal runs a per-turn Haiku checker that evaluates the current context. It has no cross-run state. Close and reopen a session, and /goal starts fresh.
/loop is session-scoped. The conversation context is the only state. When the session ends, the loop’s memory ends with it.
/schedule is where the contrast becomes explicit. Scheduled routines run when the machine is off; they are designed for cross-session execution. But the scheduled routine itself has no automatic access to prior run history. The Anthropic documentation is direct about this: for a scheduled routine to have context about prior runs, that context must live in an external system: the repo, an API, or a file the routine can read and write.
That is Anthropic’s own tooling requiring external state for cross-run continuity. The engineers who built Claude Code understood the design property of the model they were building on and designed accordingly.
What This Evidence Means for Production AI Agents
These four implementations are not a curated sample of teams that happen to agree with each other. They were built independently, for different purposes, on different stacks, by teams who had no reason to coordinate their state architecture choices. They all arrived at the same place.
That convergence is engineering evidence. It is not opinion. The teams that shipped production AI agents all discovered, through the same experience, that durable external state is a required primitive. They built their state infrastructure before they had a taxonomy to name it. Addy Osmani’s Primitive 6 is a label for something that already existed in every production loop implementation. [2] The exact definition he settled on: “a markdown file, a Linear board, or anything that lives outside a single conversation.” His note on the underlying reason: “The model forgets everything between runs. The repo doesn’t.”
The question is not whether to add external state. The question is which pattern to use.
Every team that shipped without external state encountered the same failure modes before adding it. Those failures are not edge cases or misconfigurations; they are the predictable result of asking a stateless model to maintain continuity across runs. With that pattern established, the next question is which of the four persistence approaches fits a given loop’s requirements.
AI Agent State Management: Four Patterns for Production Loops
Before covering the AI agent state persistence patterns, it is worth being specific about what happens without them. Four failure modes consistently appear across all production loop implementations that omit external state. They are not hypothetical.
What Goes Wrong Without External State in AI Agentic Loops
Re-doing work. The loop has no memory of prior runs. It re-processes items it already handled. In the best case, this is wasted compute. In the worst case, it re-applies actions (posting duplicate comments, re-sending notifications, re-toggling states) that cause real problems downstream.
Cannot resume after failure. When a loop with no checkpoints fails halfway through a batch, recovery means starting over from the beginning. For a long-running loop, that can mean hours of re-work. For a loop that touches external systems, it can lead to duplicate side effects.
Cannot parallelize safely. Two agents processing the same workload without shared state will step on each other. There is no authoritative record of which items each agent has claimed. Conflicts are silent and unpredictable.
Token budget burned on re-discovery. Every run that starts without knowledge of prior runs must re-examine items that have already been processed. This re-discovery consumes tokens that could be spent on forward progress. In long loops, this cost accumulates quickly.
All four failure modes are avoidable with any of the four agent state management patterns below.
Pattern 1: State-in-the-Repo
If your loop runs on a codebase and your team lives in git, the simplest durable state is already there.
Mechanism: Markdown files committed to git, typically a DONE.md, TODO.md, or checkpoint file stored alongside the code.
Real example: loop-engineering’s Daily Triage loop writes triage decisions to a markdown file in the repository. At the start of each run, the agent reads the file. Items that appear in the file are skipped. Items that do not appear are processed, and the result is appended before moving on.
When to use it: Small-to-medium loops with an existing git workflow. Teams that want a human-readable audit trail of loop decisions. Loops where state updates are infrequent enough that git operations are not a bottleneck.
Trade-offs to weigh:
Survives everything. A committed file persists across machine restarts, process crashes, session termination, and re-deployments. It is the most durable of the four patterns.
Human-readable by default. Anyone with repo access can read the state file without a dashboard or query tool.
Slowest to update. Every state write requires a git add, commit, and push. For loops that update state on every item in a large batch, this overhead adds up.
Parallelizable via branches, but with merge cost. Two agents can write to separate branches and merge, but the merge must be handled.
State-in-the-Repo works because git is already present. The next pattern works for the same reason; but replaces the commit trail with something the whole team already has open.
Pattern 2: State-in-a-Ticket
When your work items are already tickets, maintaining a separate state file means your team reads two systems instead of one.
Mechanism: Linear or GitHub Issues as the state store. The ticket is both the work item and the record of what has been done to it.
Real examples: loop-engineering’s CI Sweeper reads CI failure history and updates Linear tickets. Issue Triage reads GitHub Issues state (labels, assignees, existing comments) and writes decisions back as labels and assignments.
When to use it: Teams already using Linear or GitHub Issues as the primary work-tracking system. Loops where the work items are naturally ticket-shaped. Situations where product managers or other non-engineers need visibility into loop progress.
Trade-offs to weigh:
Human-readable and team-visible. Engineers, PMs, and other stakeholders can see exactly what the agent has done and what remains, using tools they already have open.
Integrates with existing workflow. The agent’s output lives where the team already looks for status.
Requires a connector. The loop code needs to make API calls to Linear or GitHub. This is straightforward with existing REST APIs or MCP connectors, but it is an additional dependency.
Rate-limited by the API. High-volume loops may encounter API rate limits that slow state updates. (Linear and GitHub both cap authenticated API calls at 5,000 requests per hour.)
Ticket systems keep stakeholders in the loop, but they carry API overhead. When multiple agents share an execution environment and need to coordinate without rate limits or git operations, a shared filesystem closes that gap.
Pattern 3: State-in-a-File
When multiple agents share an execution environment, the fastest shared state is the filesystem they already have in common.
Mechanism: A simple file on a shared filesystem. The agent reads it at startup, writes updates as it works, and the file persists between invocations.
Real example: Anthropic CMA uses the shared sandbox filesystem as the primary state persistence mechanism. All sub-agents in a deployment share the filesystem. A coordinator writing a progress file makes that progress visible to every sub-agent without any additional infrastructure.
When to use it: CMA deployments where the sandbox persists between Outcomes iterations. Any deployment where multiple agents share a filesystem and need a lightweight coordination mechanism. Loops that need faster state updates than git operations allow.
Trade-offs to weigh:
Fast. No git overhead, no API calls, no serialization beyond writing a file.
Simple. No infrastructure to set up beyond the shared filesystem.
Does not survive sandbox teardown. If the CMA sandbox is destroyed, the filesystem state goes with it. This is a documented limitation. Loops that need cross-sandbox durability require additional persistence.
Not git-versioned. There is no audit trail unless the loop explicitly builds one.
File-based state is fast and simple, but it hits a ceiling when item counts grow large or concurrent agents need to claim work without stepping on each other.
Pattern 4: State-in-a-Database
Once a loop grows to hundreds or thousands of items, or when multiple concurrent agents need to claim work safely, only a transactional store can handle the coordination correctly.
Mechanism: Structured queries with resumable cursors. The agent queries the database to determine where it left off, processes a batch, and writes results back transactionally.
When to use it: Large-scale loops with hundreds or thousands of items. Concurrent AI agents that need locking to avoid processing the same item twice. Situations where query flexibility matters: filtering by status, priority, date, or other dimensions.
Trade-offs to weigh:
Highest setup cost. Requires a database, a schema, connection management, and either direct SQL or an ORM. This is the most infrastructure-intensive of the four patterns.
Best for large-scale concurrent loops. Transactional updates and row-level locking make it the only pattern that handles high concurrency correctly at scale.
Survives everything. A well-operated database is more durable than a git repo and more queryable than a file.
Enables resumable cursors. A loop processing a large dataset can store its cursor position (the last processed item ID) and resume from exactly that point after any failure.
AI Agent State Pattern Comparison
The four patterns compared across the dimensions that matter most for choosing between them:
State-in-the-Repo (Markdown files in git, loop-engineering Daily Triage as the real-world example): survives crashes, is parallelizable via branches, and has low setup cost.
State-in-a-Ticket (Linear or GitHub Issues, loop-engineering CI Sweeper as the real-world example): survives crashes, is parallelizable since the API handles it, and has a low setup cost.
State-in-a-File (shared filesystem; Anthropic CMA sandbox as the real-world example): survives only within the sandbox, parallelizable with a shared filesystem, no setup cost.
State-in-a-Database (structured queries with cursors): survives crashes, parallelizable with locking, high setup cost.
The right pattern depends on the specific loop’s scale, team workflow, and infrastructure constraints.
With the four patterns laid out, the natural next step is knowing which one to reach for in a given situation. The real decision hinges on three practical factors: the scale of the loop, where the team already tracks work, and what infrastructure is already running.
Choosing Your AI Agent State Management Pattern
The four patterns are not equally suited to every situation. The right choice depends on three factors: the scale of the loop, the existing team workflow, and the infrastructure already in place.
Agent State Pattern Decision Guide
Start with State-in-the-Repo if:
Your loop processes tens to low hundreds of items per run.
Your team already works in git and expects a trail of decisions.
You want the state to be auditable, human-readable, and recoverable without any tooling beyond
git log.You are building the loop for the first time and want the simplest possible state mechanism that still works correctly.
This pattern fits most initial production loops. It has the lowest setup cost, survives every failure mode, and requires no external services. Its primary weakness (git operation overhead per state update) only becomes a real bottleneck at high item counts or high update frequencies.
Move to State-in-a-Ticket if:
Your team already uses Linear or GitHub Issues as the primary tracker for work items.
The items the loop processes are naturally ticket-shaped: they have owners, statuses, priorities, and comments.
You want non-engineer stakeholders to see loop progress without learning to read git commits or query files.
You have or can add a Linear or GitHub MCP connector.
This pattern is particularly effective for loops that extend existing engineering workflows. The loop becomes a participant in the same system the team uses for planning and tracking, and its output is immediately visible in context.
Choose State-in-a-File if:
You are deploying on Anthropic CMA and the sandbox persists between Outcomes iterations.
You need a fast shared coordination mechanism between multiple agents in the same deployment.
You are willing to handle cross-sandbox durability separately (or the loop does not need it).
This is the right pattern for CMA-native deployments. It is the pattern CMA itself uses, and it works well within the sandbox model. Engineers who need state to survive sandbox teardown should layer State-in-the-Repo or State-in-a-Database on top.
Use State-in-a-Database when:
Your loop processes hundreds or thousands of items per run.
You need multiple concurrent AI agents to process the same workload without conflicts.
You need transactional guarantees: state updates that are atomic and recoverable.
You need flexible querying: for example, “resume from the oldest unprocessed item” or “show me everything that failed in the last 24 hours.”
This pattern has the highest setup cost of the four. It is not the right starting point for most loops. But once a loop reaches the scale where git operations or API rate limits become bottlenecks, a database is the only pattern that handles the load correctly.
What Every AI Agent State Pattern Must Guarantee
Each of the four patterns places the state within a system with three properties.
First, it survives the process. State written to git, a ticket system, or a database is not lost when the agent process ends. The next run can read it.
Second, it is readable by the agent on startup. The agent can query or read the state at the beginning of each run and determine what has already been done.
Third, it is writable after each significant action. The agent updates the state as it works, so a crash at any point leaves a recoverable record.
These are the minimum requirements. The patterns differ in where they store state, how durable that storage is, and what it costs to set up and operate. The requirements do not change.
External State Is the Spine of Every Production AI Agent Loop
The agent state “problem” is not really a problem; it is a design constraint. The model is stateless between API calls. That is not going to change. Every production loop implementation examined here discovered this constraint and built around it, and the ones that did so cleanly are the ones that work reliably in production.
The engineers who built cobusgreyling/loop-engineering did not write about durable state in the abstract. They shipped seven loop patterns and made every single one write to an external state store before it could be called done (3,900 stars and 509 forks as of June 2026). The engineers who built AlessandroAnnini/agent-loop persisted configuration to disk and documented exactly where their in-process repetition detector fell short. Anthropic’s own CMA infrastructure gave every agent access to a shared filesystem because the system's design requires shared, persistent state to function.
Addy Osmani’s June 2026 taxonomy gave this a name (Memory/State, Primitive 6), but the name came after the practice. The practice was already everywhere.
If you are building an AI agent loop today, the question is not whether to add external state. Every production loop that tried to skip it eventually added it, after the re-doing, the failed resumes, and the debugging sessions that would have been trivial with a state file to read. The question is which pattern fits your current situation and can be extended as your loop grows.
Start with the simplest pattern that solves your scale. Upgrade as you grow.
If this helped you, please consider subscribing to my Substack newsletter.
Likes, comments, and shares really do make a difference. They help grow the channel, support the work, and get these ideas in front of more builders who are trying to understand AI agents, harness engineering, and production AI systems.
Thank you for reading and for helping the work reach more people.
The Multi-Agent Coordination Problem: What Comes Next
Adding external state to a single-agent loop is well-understood at this point. The convergent evidence is clear, the patterns are documented, and the trade-offs are known.
The unsolved problem is coordination. When multiple AI agents share a state store (as in CMA deployments, or in large-scale database-backed loops with concurrent workers), questions of ownership, locking, and conflict resolution become real. Two agents that can both write to the same state file need a protocol for avoiding corrupted state. Two agents processing items from a shared database queue need a way to claim items without racing.
Transactional databases handle part of this with locking. Ticket systems handle part of this with assignment semantics. But neither fully solves the coordination problem for general-purpose agentic AI loops.
That is the frontier. The state problem has been solved. The coordination problem is next.
Related Articles
If this article sparked ideas you want to follow further, these pieces cover the patterns directly:
Loop Engineering and Autonomous Agent Systems: The foundational breakdown of Addy Osmani’s six-primitive loop engineering taxonomy: the exact framework this article builds on. Covers autonomous feedback loop design and iterative agent execution patterns, including multi-stage design flows, and what it means to architect agent loops rather than author prompts. External State is Primitive 6 in that taxonomy [2]; this article explains what the other five are and why all six are required.
Architecting Production-Grade Agents through LLM Orchestration and Agentic Loops : The implementation companion for engineers ready to go deeper after choosing a state pattern. Covers how production teams wire LLM orchestration into durable, observable agentic loops: including checkpointing strategies, tool routing, and the infrastructure choices that separate a working prototype from a system that runs unattended. Directly addresses what state management must plug into: a loop architecture designed to survive failures and resume cleanly.
Harness Engineering vs Context Engineering: The Model is the CPU, the Harness is the OS: Establishes the mental model that explains why external state is the harness’s responsibility, not the model’s. The model is a stateless reasoning engine: the CPU. The harness is the operating system that manages memory, scheduling, and persistence across runs. Explains why conflating prompt engineering with harness design produces systems that cannot self-correct, and why every production loop must own both layers to function reliably.
Why Single-Agent AI is Dead: Inside Anthropic’s New Blueprint for Long-Running Agents: Picks up where this article’s final section leaves off: once external state is solved for a single-agent loop, the next problem is coordination across multiple agents sharing that state. Covers Anthropic’s GAN-style Planner/Generator/Evaluator architecture, Sprint Contracts, and adversarial evaluation loops: the multi-agent patterns that emerge when a single coordinator is no longer enough and work must span hours, tools, and parallel sub-agents.
Claude Code Subagents and Main Agent Coordination: A Complete Guide to AI Agent Delegation Patterns. A hands-on guide to the coordinator/sub-agent delegation pattern: the practical form of the multi-agent coordination problem introduced at the end of this article. Covers how a main agent decomposes tasks, dispatches to sub-agents with scoped context, and synthesizes results without corrupting shared state. Essential reading for teams moving from single-agent loops with external state to multi-agent systems where ownership, locking, and conflict resolution become the new engineering challenge.
References
About the Author — Claude Certified Architect
Rick Hightower is a former Senior Distinguished Engineer at a Fortune 100 company, focusing on delivering ML / AI insights to front-line applications, and a practitioner building multi-agent production systems. Follow him on SubStack and Medium for more hands-on agent engineering content. You can also book him to speak and train your team: Check out Rick Hightower’s SpeakerHub.
Rick Hightower helps companies become AI-first through practical mentoring, executive and team training, and custom AI solution development. He is a former Senior Distinguished Engineer at a Fortune 100 company, where he focused on bringing ML and AI insights into real front-line business applications.
Subscribe to Rick’s newsletter to see videos and guides.
Rick is a Claude Certified Architect, AI systems practitioner, and builder of production multi-agent systems. He is currently working on authoring a book on Harness Engineering with Manning Publishing. He created Skilz, a universal agent skill installer supporting 30+ coding agents, including Claude Code, Gemini, Copilot, and Cursor, and co-founded one of the largest agentic skill marketplaces.
Today, Rick and the Spillwave team work with leaders and teams who want to move beyond AI experiments and build real AI capability inside their companies. He helps organizations adopt AI safely, train their people, redesign workflows, and build practical AI systems that create measurable business value.
Ready to make your company AI-first? Connect with Rick on LinkedIn, Substack, or Medium, book him to speak or train your team, or visit Spillwave to explore mentoring, training, and custom AI solutions for your organization.