Loop Engineering: The Problem and Why Claude Managed Agents Exist
Claude Managed Agents turns loop engineering into a platform primitive, replacing hand-built cron triggers, eval loops, and fan-out harnesses with native scheduling, Outcomes, and agents orchestration
Most teams do not realize they are building an operating system around their AI agents until it breaks in production. Claude Managed Agents matters because it asks a painful question: why are your best engineers still babysitting cron jobs, retry loops, and fragile fan-out harnesses instead of building the product?
Summary: Claude Managed Agents is Anthropic’s attempt to turn the hidden infrastructure behind production AI agents into a managed platform primitive. This article breaks down why modern agent systems are no longer just about prompts, but about loops: scheduled execution, quality evaluation, retry cycles, shared state, and multi-agent fan-out. It maps CMA’s core capabilities—native cron scheduling, the Outcomes maker/checker loop, and coordinator/sub-agent orchestration—against the real operational pain that teams face when building these layers by hand. The result is a practical guide to what CMA removes, what it does not, and where engineers still need to own the architecture before betting production workflows on the platform.
Before we get into it, please consider subscribing to my Substack newsletter.
If this kind of practical, production-minded AI work is useful to you: a subscribe, like, comment, or share really helps grow the channel and supports this work
Thank you for reading and helping these ideas reach more builders.
How Claude Managed Agents turns loop engineering into a platform primitive, replacing hand-built cron triggers, eval loops, and fan-out harnesses with native scheduling, Outcomes, and multi-agent orchestration.
Most teams building AI Agents end up owning three pieces of infrastructure they never wanted to build. The first is a scheduling layer to trigger agents on a reliable cadence. The second is an evaluation loop to judge whether output meets the bar. The third is a fan-out harness that distributes work when a job is too large for a single context window. None of this is differentiating product work. All of it is expensive to maintain, fragile under load, and almost always assembled from parts (cron daemons, Lambda triggers, custom retry harnesses, ad hoc coordinators) that someone has to own at 2 a.m. when they silently fail.
That is loop engineering: the infrastructure that repeatedly invokes an AI model, evaluates its output, and acts on the result. Claude Managed Agents (CMA), launched on June 9, 2026, is Anthropic’s bet that most teams shouldn’t build this infrastructure themselves. Before we get to the three primitives it provides, let’s name exactly what problem they solve.
Why Loop Engineering Is Expensive to Build by Hand
The failure modes are predictable: scheduling triggers silently miss windows, same-model self-graders rationalize rather than critique, and fan-out coordinators accumulate fragility with every new worker added. None of it is differentiating product work.
Boris Cherny, Head of Claude Code at Anthropic, put the shift plainly:
“I don’t prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops.”
That is the Agentic AI shift in practice: the craft of AI engineering is moving from prompt authorship to loop architecture. CMA is Anthropic’s answer to that shift: stop making every team reinvent the scheduling, evaluation, and fan-out layers from scratch.
Where Claude Managed Agents Fits in the Agentic Loop Taxonomy
Addy Osmani published his essay on a 6-primitive loop taxonomy in June 2026, a framework for classifying the components of agentic systems. CMA natively covers three of the six primitives:
Primitive 1: Automations: Scheduling and triggering; CMA provides native cron scheduling.
Primitives 2, 3, 4: Not mapped to CMA; you build these yourself.
Primitive 5: Sub-agents: Fan-out coordination; CMA provides multi-agent orchestration.
Primitive 6: Memory/State: Shared state across agents; CMA provides a shared sandbox and filesystem.
Primitives 2, 3, and 4 fall outside CMA’s scope. If your loop requires them, you build that infrastructure yourself. The platform is intentionally scoped, not a complete agentic runtime.
CMA launched June 9, 2026. Independent engineering analysis of its three primitives is scarce; the breakdown below draws from primary source material. Native cron scheduling is where the infrastructure reduction becomes concrete. Start there.
With the architecture overview and taxonomy mapping complete, Part 2 shifts from the why to the how, examining in detail the first of the three covered primitives. Native cron scheduling is where the infrastructure reduction becomes concrete: the POST /v1/deployments endpoint and its schedule object replace the external schedulers that previously sat between a team and their running agent.
Primitive 1: Native Cron Scheduling for AI Agents (POST /v1/deployments)
Native cron scheduling is the first primitive CMA ships for loop engineering. Instead of wiring together an external cron daemon, a Lambda trigger, or a GitHub Actions workflow just to fire your coordinator on a schedule, CMA lets you declare the schedule directly in the deployment API call. The scheduling infrastructure layer disappears.
The POST /v1/deployments API Shape
The endpoint accepts a schedule object inside the deployment request body:
{
“schedule”: {
“type”: “cron”,
“expression”: “<cron expression>”,
“timezone”: “<timezone string>”
}
}Three fields: type (always "cron" for scheduled deployments), expression (standard cron syntax), and timezone (an IANA timezone string). That is the verified interface from the primary source material (anthropics/launch-your-agent, cma-primitives.md, June 16, 2026). Do not expect additional fields such as retry_policy or priority; they are not part of the confirmed API shape.
What Native Cron Scheduling Replaces
Before CMA, a scheduled agent typically required at least one external piece:
An external cron daemon or process manager to fire invocations
An AWS Lambda trigger (or equivalent) for serverless scheduling
A GitHub Actions scheduled workflow for CI-adjacent orchestration
CMA handles trigger delivery and execution coordination at the platform level. You keep the coordinator’s task logic; the platform manages the call cadence.
The 1,000-Deployment Organizational Limit
Each organization gets a hard ceiling of 1,000 deployments. For most engineering teams, that limit is not binding; a team running dozens of scheduled AI Agents sits comfortably within it. For a large organization with hundreds of scheduled workflows, 1,000 becomes a concrete planning constraint worth factoring in before you commit scheduling infrastructure to CMA.
Taxonomy Placement: Osmani Primitive 1 (Automations)
In Addy Osmani’s 6-primitive loop taxonomy, scheduled agent invocations fall under Primitive 1: Automations. CMA’s native cron scheduling is a direct platform implementation of that primitive. If you’re mapping CMA against the taxonomy, this is the cleanest correspondence; Primitive 1 is fully covered.
Trade-off: Zero Scheduling Overhead vs. Platform Lock-in
What you gain is significant: no scheduling infrastructure to maintain, monitor, patch, or scale. Your coordinator runs on schedule without operational overhead at the trigger layer.
What you give up is portability and visibility. Your schedule lives inside CMA. If you move the workload to a different platform or add your own orchestration layer later, you will need to rebuild the trigger logic from scratch. You also cannot inspect or modify the internal scheduler behavior. The platform manages it, which limits your ability to debug timing edge cases or inject custom logic at the scheduling layer.
You still need to build the coordinator’s task logic, error handling within the agent run, and any downstream integrations that consume the agent’s output. Native cron scheduling removes the trigger infrastructure; everything the coordinator does after it wakes up remains your responsibility.
Native cron scheduling removes the trigger layer but leaves the quality-assurance problem untouched: once a coordinator wakes up on schedule and produces output, nothing in Primitive 1 tells you whether that output is any good. That gap is where Primitive 2 enters. The Outcomes system addresses exactly this failure mode by enforcing a maker/checker loop at the platform level, replacing the hand-rolled evaluation harness that most teams have bolted on after the fact.
Primitive 2: The Outcomes System (Maker/Checker Quality Loop)
The second primitive CMA provides is the Outcomes system, a platform-enforced quality loop that automatically evaluates agent output and drives iterative revision. It is the most novel of the three primitives and the one most likely to eliminate a category of infrastructure that teams currently build badly.
The Problem: Hand-Rolled AI Agent Evaluation Loops
If you have shipped a production agent, you have almost certainly written some version of this pattern: call the model, get the output, call the model again to check whether the output is good, and retry if it falls short. That approach has three persistent problems.
First, it is expensive to build correctly. Custom retry logic, prompt construction for feedback, and coordination state all add up to a bespoke harness that someone has to own and debug.
Second, it is fragile. Retry logic diverges from the quality criteria over time. Feedback constructed by hand drifts as the underlying task changes.
Third, and most critically, it suffers from grader capture. When the same model grades its own output, it tends to rationalize rather than critique. The model that produced the answer is poorly positioned to find that answer’s flaws. Platform-enforced grader isolation is the only reliable fix.
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.
How the Maker/Checker Architecture Works
The Outcomes system implements a maker/checker architecture with a hard isolation guarantee: the grader evaluating coordinator output is not the same model instance that produced it, and it runs in its own context window with no visibility into the coordinator’s reasoning trajectory. This is not a convention or a configuration option; CMA enforces it.
The cycle runs as follows:
The coordinator produces output.
A separate, isolated grader evaluates that output against a rubric.
The grader returns one of five named result states.
If the state is
needs_revision, the grader’s feedback is automatically injected into the next coordinator invocation and the cycle repeats.The loop continues until it reaches
satisfied,max_iterations_reached,failed, orinterrupted.
The platform handles steps 2 through 5. You write the coordinator logic and the rubric. Nothing else.
Writing the Rubric: Plain Markdown, Natural Language
The rubric is a plain markdown document. You write pass/fail criteria in natural language describing what good output looks like. There is no schema, no DSL, no templating system to learn.
A minimal rubric might look like this:
## Quality Criteria
- The response must directly answer the user’s question without preamble.
- All numerical claims must be supported by a calculation or a cited source.
- The tone must be appropriate for a technical audience: direct, no marketing language.
- The response must be under 400 words.Keep rubrics as plain markdown. That constraint also has a practical upside: rubrics written in natural language are readable by non-engineers and auditable without tooling.
The Five Result States
The Outcomes system produces exactly five named states. Use the exact names; they map to your control flow:
satisfied: Grader determined output meets the rubric. Loop exits successfully.needs_revision: Output does not meet the rubric. Grader feedback is injected and the coordinator re-runs.max_iterations_reached: The loop hit the configured iteration ceiling without reachingsatisfied.failed: A hard failure occurred, distinct from exhausting the retry budget.interrupted: The loop was stopped externally before completing.
Each state is a distinct exit condition. Your downstream code should handle all five. max_iterations_reached and failed are semantically different: the first means the loop ran out of attempts; the second means something broke before it could.
Iteration Configuration: Default 3, Ceiling 20
The max_iterations field controls how many revision cycles the loop will attempt before exiting with max_iterations_reached. The default is 3. The platform ceiling is 20.
Choose max_iterations based on the cost tolerance and latency requirements of the task. A data extraction job where each retry is cheap, and accuracy is critical, can justify pushing toward 20. A customer-facing response where each iteration adds latency should stay at 3 or fewer.
You cannot configure a ceiling above 20. That is a platform constraint, not a default you can override.
What the Outcomes System Replaces
The Outcomes system eliminates:
Hand-rolled eval wrappers that invoke the model a second time to grade its own output
Custom retry logic and loop state management
Ad hoc feedback injection (manually constructing the next prompt with failure details)
The grader-capture risk inherent in same-model self-evaluation
What You Still Need to Build
The Outcomes system does not eliminate the need for a well-constructed rubric. Writing useful pass/fail criteria in plain markdown is real engineering work: a rubric that is too vague produces satisfied states on mediocre output, and a rubric that is too strict drives every run to max_iterations_reached.
The grader’s internal reasoning is opaque to the API caller; what is returned is the verdict and the feedback injected back to the coordinator, not the grader’s full evaluation chain. Custom grader models are not mentioned in available primary source documentation. For workloads that require complex programmatic evaluation criteria or deterministic graders, the Outcomes system is not the right tool.
For workloads with articulable quality criteria in natural language that can tolerate up to 20 revision cycles, it replaces a substantial amount of bespoke evaluation infrastructure.
With the Outcomes system handling iterative self-correction within a single agent’s work, the next natural question is: what happens when a task is too broad for a single agent to handle sequentially at all? That is where multi-agent orchestration enters the picture, and where CMA surfaces its third core primitive. Rather than coordinating separate deployments manually, CMA provides coordinators with a structured fan-out model that includes shared infrastructure and enforced isolation between workers.
Primitive 3: Multi-Agent Orchestration in Claude Managed Agents
Building a multi-agent orchestration harness by hand is one of the more tedious pieces of AI infrastructure work. You need task dispatch, shared state management, concurrent session tracking, context isolation between AI Agents, and result collection: all before you write a line of business logic. CMA addresses this with its third core primitive: a native coordinator/sub-agent model that handles the fan-out infrastructure so your team doesn’t have to.
The Fan-Out Problem in Multi-Agent Orchestration
When a workflow contains genuinely parallelizable subtasks (research, code review, data extraction running simultaneously across multiple inputs), the straightforward solution is to fan out to multiple agents at once. Hand-rolling that fan-out is where things get complicated fast. You end up building custom task-dispatch harnesses to invoke agent instances in parallel, an ad hoc shared-state layer (often a Redis sidecar or similar) to coordinate results, manual session and context management to keep agents from colliding, and a result-collection layer to aggregate outputs back into a coherent whole. None of that is differentiated engineering. It is infrastructure, and it needs to be correct every time.
CMA’s multi-agent orchestration primitive natively covers this layer. It maps directly to Osmani Primitive 5 (Sub-agents) and Osmani Primitive 6 (Memory/State) from the 6-primitive loop taxonomy introduced in Part 1; and it is the clearest example of Agentic AI infrastructure moving from custom-built to platform-provided.
How CMA’s Coordinator Model Works
The coordination model is a flat star topology: a single coordinator delegates tasks to sub-agents, and each sub-agent executes independently. Think of the coordinator as the hub of a wheel (deciding which subtasks to assign and to whom), with sub-agents as the spokes, each focused on executing its individual assignment.
The coordinator dispatches tasks, sub-agents run concurrently, and their outputs flow back to the coordinator for synthesis. The platform handles session management and execution coordination across that concurrent fan-out. What engineers still build is the decomposition logic inside the coordinator: how to break a problem into parallelizable units that map cleanly to independent sub-agent assignments.
Hard Limits: Sub-Agents and Concurrent Sessions
CMA’s multi-agent orchestration supports up to 20 sub-agents per coordinator and up to 25 concurrent session threads. These are platform-level hard limits, not defaults you can tune. For workloads that fit within these bounds, the limits are rarely a bottleneck in practice. For workloads that genuinely require more than 20 parallel workers, CMA’s current model requires rethinking the decomposition strategy or breaking the problem into sequenced coordinator passes.
Surface these numbers early in your design. An architecture that assumes 50 parallel sub-agents does not fit CMA today.
Shared Resources Across Sub-Agents
All sub-agents within a coordinator’s session share a common sandbox: the same filesystem and the same vault credentials. This shared sandbox maps to Osmani Primitive 6 (Memory/State); it is the mechanism through which sub-agents can hand off intermediate results and access common secrets without any custom state-management layer.
The shared sandbox is a two-edged capability. On the collaborative side, one sub-agent can write a file, and another can read and extend it, enabling sequential handoffs within a concurrent execution. On the risk side, concurrent writes to the same path require explicit coordination discipline. In practice, CMA’s primary source documentation does not address write ordering for concurrent sub-agent access to the shared filesystem; managing write conflicts remains the application’s responsibility.
Context Isolation: What Sub-Agents Cannot See
While sub-agents share a filesystem, they do not share context. Each sub-agent has an isolated context window. A sub-agent sees its task assignment from the coordinator, its own conversation history, and nothing else: not the coordinator’s full context, and not the conversation histories of sibling sub-agents.
This isolation is a deliberate design choice with a practical implication: sub-agents cannot pass intermediate results through context. If sub-agent A produces something that sub-agent B needs, that handoff must go through the shared filesystem, not through a shared conversation thread. Designing multi-agent workflows on CMA means designing explicit file-based handoff conventions rather than assuming context propagation.
The Depth-1 Constraint and Its Design Implications
The most significant structural limit in CMA’s multi-agent orchestration is the depth-1 topology: the coordinator can dispatch to sub-agents, but sub-agents cannot spawn further sub-agents. There is no hierarchical multi-agent tree. Sub-agents are leaf nodes only.
This is a hard platform constraint, not a configuration parameter. Workflows that naturally require layered delegation (for example, a sub-agent that itself needs to fan out across a set of documents each handled by its own dedicated agent) cannot be expressed directly in CMA’s current model. Realizing those workflows requires redesigning the decomposition at the coordinator level: breaking the problem into a shape where all parallelism lives one hop from the coordinator, rather than cascading through multiple levels.
For most practical workloads, this is not a blocking constraint. The star topology cleanly handles a large class of parallelizable tasks. Where it matters is in architecturally complex workflows that assume recursive delegation. Those workflows require a fundamentally different decomposition strategy, and CMA’s depth-1 limit is a good forcing function to surface that complexity early in design rather than late in implementation.
Those structural boundaries- the depth-1 topology, the isolated context windows, the shared filesystem, the write-ordering discipline you own- are not quirks to work around but the honest edges of what the platform provides. Understanding where CMA ends, and your own engineering begins, is the practical core of adopting it well. The decision guide below maps each loop-engineering concern directly to what CMA delivers out of the box and what remains yours to build.
What CMA Provides vs. What You Build Yourself
CMA’s three primitives are now mapped. The harder question is when to use them and what you still own afterward. This decision guide maps loop-engineering concerns directly to CMA primitives and honest gaps so you can commit to the platform without discovering the limits mid-integration.
CMA vs. Build-Yourself: Loop Engineering Decision Guide
Scheduling and triggering: CMA provides POST /v1/deployments with schedule: {type: 'cron', expression, timezone}; the platform handles trigger delivery. You still build agent logic, error handling inside the agent, and downstream integrations that consume output.
Eval and quality loop: CMA provides an isolated grader that evaluates against a markdown rubric, five named result states (satisfied, needs_revision, max_iterations_reached, failed, interrupted), automatic feedback injection on needs_revision, and default 3 iterations with a max of 20. You still write the rubric itself in plain markdown and handle downstream logic for max_iterations_reached, failed, and interrupted outcomes.
Fan-out coordination: CMA provides a coordinator with up to 20 sub-agents, 25 concurrent session threads, and platform-managed session lifecycle. You still build task decomposition logic, write-ordering discipline on the shared filesystem, and result aggregation at the coordinator level.
Shared state and memory: CMA provides a shared sandbox, filesystem, and vault credentials across all sub-agents in a session. You still establish conventions for file naming, write-ordering, and conflict avoidance when multiple sub-agents write concurrently.
Observability: Not confirmed in primary sources: do not assume CMA ships dashboards, trace IDs, or log streaming. Treat observability as a gap you own until the platform documents it otherwise.
Portability: CMA provides none. Scheduling and orchestration are CMA-specific constructs. You own the migration path if you move off CMA to another platform.
The observability row deserves a direct call-out: do not assume CMA ships dashboards, trace IDs, or log streaming. Primary source documentation does not specify built-in observability tooling for CMA. Treat observability as a gap you own until the platform documents it otherwise.
What Claude Managed Agents Does Not Provide
Engineers must know where the edges are before they build against them. Two claims circulated at the June 2026 launch that turned out to be false.
SDK fork_session flag. This flag does not exist. Adversarial verification against the SDK and documentation found no evidence of it. Do not build integrations that depend on it.
In-process MCP servers via create_sdk_mcp_server(). This method does not appear in verified documentation. Do not use it.
Both are listed here explicitly to save you from discovering the truth through failed integration attempts.
When Claude Managed Agents Is the Right Fit
CMA fits well when:
AI Agents run on a regular schedule, and you want to avoid maintaining external trigger infrastructure
Workloads have clear, natural-language quality criteria that translate cleanly into a markdown rubric
Fan-out tasks decompose into fewer than 20 parallel sub-tasks
Teams want scheduling to be a platform concern rather than a separate operational one
The organization runs under 1,000 active scheduled agents
When CMA’s Limits Become Binding Constraints
Know the hard ceilings before you commit to the platform.
Depth greater than one required. CMA enforces a strict depth-1 topology: coordinators spawn workers, but workers cannot spawn further sub-agents. Workflows that require hierarchical delegation across more than two levels cannot be expressed inside CMA.
More than 20 parallel sub-agents are needed. The 20-sub-agent limit per coordinator is a hard ceiling. Large fan-out patterns that exceed it require a different approach.
More than 1,000 deployments at the organizational level. Organizations running large-scale scheduled agent fleets will hit this limit.
Complex, programmatic rubrics. The grader evaluates against plain markdown. If your quality criteria require dynamic templating, variable injection, or code-driven evaluation logic, the rubric format may not be expressive enough.
Platform portability is a requirement. CMA scheduling and orchestration are specific to the CMA platform. If you need the same agent loop to run on other infrastructure without rework, the native primitives create lock-in.
Fine-grained observability is critical. If compliance or operational requirements demand detailed audit trails or real-time tracing, CMA’s observability story is unverified. You will need to instrument that yourself.
Related Articles
If this article sparked ideas you want to follow further, these pieces cover the patterns directly:
Why Single-Agent AI is Dead: Inside Anthropic’s New Blueprint for Long-Running Agents Shows where loop engineering leads at scale: when a single coordinator is no longer enough, and work must span hours, tools, and coordinated sub-agents. Covers Anthropic’s GAN-style Planner/Generator/Evaluator architecture, Sprint Contracts, and adversarial evaluation loops: the multi-agent patterns that CMA’s Outcomes system and multi-agent orchestration primitive are built to support at the platform level.
Harness Engineering vs Context Engineering: The Model is the CPU, the Harness is the OS. Establishes the mental model that explains why CMA exists: the harness is the operating system the model runs inside, and context is its working memory. Explains why loop architects must own both layers, why conflating prompt engineering with harness design produces systems that cannot self-correct, and how CMA’s three primitives each target a distinct harness responsibility: scheduling, evaluation, and fan-out coordination.
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 that underpins CMA’s third primitive. Covers how a main agent decomposes tasks, dispatches to sub-agents with scoped context, and synthesizes results: the same star-topology model CMA enforces at the platform level. Essential reading for teams designing the task-decomposition logic the coordinator must still own after adopting CMA.
Architecting Production-Grade Agents through LLM Orchestration and Agentic Loops. The implementation companion for engineers who want to go deeper after adopting CMA’s primitives. Covers how production teams wire LLM orchestration into durable, observable agentic loops: including checkpointing, tool routing, and the infrastructure choices that separate a working prototype from a system that runs unattended. Directly addresses what CMA leaves in your hands: the coordinator’s task logic, error handling, and downstream integrations.
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.
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.
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.
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.