AI agent orchestration is the design that sets the order and roles of multiple AI tasks. If you leave everything to one long-running conversation, usage grows fast, so MCPY splits work into a task ledger and short sessions. A model has no memory between calls, so every tool call resends the entire conversation so far. Below, we cover MCPY's measured numbers (October 3 to 6, 2026), the design steps, and the criteria for using subagents and multi-agent systems, alongside official Anthropic articles. It helps to understand the basic concept of an AI agent first.
Why running an AI agent in a long conversation gets expensive
Every tool call resends the whole earlier conversation, so cost is close to the number of calls multiplied by the conversation size built up by then. The server reuses the resent earlier part from cache, so it does not process it again. According to Anthropic's docs, cache read tokens cost 0.1x the base input price and the default lifetime is 5 minutes. The unit price is low, but the reused volume still counts as usage.
This gap showed up clearly in MCPY's operating records. MCPY runs its blog writer with Claude Code (headless mode) every hour. One conversation that a human and an AI had continued for several days reused about 820,000 cached tokens on every single reply. Between 01:45 and 02:50, 25 replies in that conversation used 20.33 million tokens, while the 12 posts the writer produced in the same period used 18.34 million tokens. Twenty-five chat replies used more than 12 articles.
The same pattern appeared in other work. An orchestrator conversation that ran for 10 days made 1,847 calls, was about 930,000 tokens per call at the time, and had a cumulative 970 million cache-reuse tokens. It delegated to subagents 132 times, but the results piled up in the orchestrator conversation, and auto-compaction happened 4 times. A design conversation that ran for 17 days made 744 calls with a cumulative 350 million tokens and had 0 subagent delegations.
Auto-compaction did not solve the problem because it only trims the conversation when it hits the cap (about 1 million tokens) and cannot stop it from filling up again. In its context engineering article, Anthropic explains that as the number of tokens in the context window grows, the model's ability to accurately recall information in it declines. A long conversation does not just raise usage. It can also weaken accurate recall.
AI agent orchestration design: ledger, program, short sessions
The design rests on three pieces. State lives in a ledger (a database or a document), a program decides the order, and the actual work is done by short sessions that are used once and thrown away. Anthropic's article on long-running agents assumes that a new session starts with no memory of the previous one. So it leaves a progress log file, a feature list, and git commits, has each session handle only one feature at a time, and has each session start by reading the progress file and git history and picking a high-priority unfinished item.
| Component | What it does | What it should not hold |
|---|---|---|
| Ledger | Stores tasks, status, result summaries, and human-check flags | Full conversation transcripts |
| Orchestrator | Picks a task from the ledger, bundles only the needed documents, and launches a new session | Running as an AI conversation (a program decides the order) |
| Work session | Does one task and ends. Gets only the model and tools that task needs | Handling several tasks in a row |
| Conversation with a human | Covers only goals, decisions, and confirmations | The full work content |
The key choice in this design is to make the orchestrator a program, not an AI conversation. When deciding the order does not need model judgment, MCPY has a program read the ledger and pick the next task. No conversation builds up while the order is being chosen. Anthropic's Building effective agents calls a system that links models and tools through predefined code paths a workflow, and one where the model directs its own process and tool use an agent. For complex work where the needed subtasks cannot be predicted in advance, it says the orchestrator-workers pattern, where a central model splits up and delegates tasks, fits well. Most recurring work has an order you can know in advance, so a program is enough.
When to use subagents and multi-agent systems
A subagent is a helper agent that works in a separate context window and returns only a summary, so use it to hand off work whose search results or logs would otherwise fill the main conversation. According to the Claude Code docs, a subagent runs with its own context window, a specified system prompt, limited tool access, and separate permissions, and you can set the tools it uses with the tools field and the model with the model field. A typical case is searching many files and reporting back only the result. For an example of working with subagents, see the post on building CRM documentation with Claude Code subagents (in Korean).
With multi-agent systems, weigh the cost first. According to Anthropic's article on its multi-agent research system, an agent uses about 4x the tokens of a chat, and a multi-agent system uses about 15x. So it fits work that is valuable enough to justify that cost and that explores several branches at the same time. The same article says to give each subagent an objective, an output format, guidance on tools and sources, and clear task boundaries. Without these, agents duplicate each other's work or miss needed information.
MCPY's measurements showed that using subagents alone is not enough. The orchestrator conversation that delegated 132 times still grew to 930,000 tokens because the results piled up in the conversation. Anthropic's context engineering article describes a structure where a subagent returns only a summary, usually condensed to 1,000 to 2,000 tokens. Delegation works only if you limit results to a summary format and keep long outputs in files, receiving just the path.
How to build the work session result format and check it
When a work session ends, fix the format of the result it writes to the ledger. MCPY uses five fields.
- Status: one of done, blocked, or needs human check.
- 5-line summary: what was done and the result.
- Output path: keep long content in a file and write only the path.
- Next suggestion: candidates for what to do next.
- Questions: what a human needs to decide.
Review is split into two stages. First run the work through fixed gates such as tests, rendering, and evaluation, and hand only judgment reviews, such as human-style judgment, to a new session. Items that need a human check are flagged in the ledger and asked about through Telegram or a hub. The conversation with a human covers only goals, decisions, and confirmations, and work content is read from the ledger and output files.
You can check that it runs properly with three points. First, check that the documents a work session reads at the start are only what that task needs. Second, check that the final context size of a session ends at a similar level every session and does not keep growing over a day. Third, check that you can tell from the ledger alone how far the work has gone and what a human needs to decide. If all three hold, the structure does not depend on a single conversation.
Results from applying this to the MCPY writer
The MCPY blog writer has shifted gradually in this direction. The changes are a queue file, a precheck, a new session for each post, a command that saves by file path, a quality gate, Telegram, and parallel runs. Over the three days from October 3 to 5, the writer ran 103 times, and the total API-equivalent amount shown by Claude Code was about $243. It runs on a subscription login, so there is no actual charge. Usage is deducted from the subscription limit, and the displayed amount is what the same volume would cost through the API.
The steps to reduce what builds up within a single post followed the same principle. Of the 102 tool manuals that were loaded on every call regardless of the writer, only the 23 needed were kept. The 100 related keywords in search volume results were cut to 20. Duplicate-check results went from the full text of other posts to titles and summaries. Original-size image checks were replaced with 900px reduced copies. The run that fired every hour even with nothing to do was changed to run only when there is work. For the first post under the new settings, the peak size that builds up fell from 210,000 to 120,000 tokens, and the average fell from 160,000 to 95,000 tokens. The equivalent cost per post dropped from $1.89 to $1.43, about 25% less. Quality scores stayed within the previous range (style 0.77, facts 0.85).
| Item | Before | After |
|---|---|---|
| Peak size | 210K | 120K |
| Average size | 160K | 95K |
Cutting output alone had a small effect. The first step, which stopped rewriting the body text into tools, cut output from 57,000 to 25,000 tokens per post, but the equivalent cost only dropped slightly, from $2.57 to $2.13. Most of the cost was cache reuse. If usage limits are a concern, also see Claude Code pricing plans and usage limits.
AI agent orchestration: where to start today
There are two things to do today. Pick the longest-running conversation, move its decisions and remaining work into a single document, and close that conversation. Then have a new session read only that document and continue the same work, and compare how much smaller the amount read at the start is than in the earlier conversation.
Frequently asked questions
Are AI orchestration and multi-agent the same thing?
No. Orchestration is deciding the order and roles of multiple tasks, and multi-agent is a structure where several agents split the work. You can do orchestration with just a program and no agents.
Do subagents reduce tokens?
They do if search results do not pile up in the main conversation, but not if the delegated results come back long. MCPY's orchestrator delegated to subagents 132 times, yet the results piled up in the conversation and it grew to about 930,000 tokens per call.
What should I build the task ledger with?
One database or one document is enough. Anthropic's long-running agent article also leaves state in a progress log file, a feature list file, and git commits. What matters is not the tool but a format that a new session can read and continue from right away.
Sources
Found this useful? Share it
Related posts
Related projects
Get new posts by email
Insights on marketing, analytics, and dev, delivered to your inbox.