Most of what a coding agent does is boring.
\nRead a file. List a directory. Grep for a symbol. Parse the output of a build command. Eight or ten turns of that, and maybe one where the agent actually has to think — should this be a class or a free function, should this function be idempotent, why does the test pass on CI and fail locally. The easy turns vastly outnumber the hard ones.
\nThe bill doesn't know the difference. Every turn is priced the same. A Claude Opus token spent parsing ls costs the same as a Claude Opus token spent designing a migration. That's the unspoken pricing of running agents in production, and it's the source of a specific kind of pain — watching a meter tick up while the model does work a seven-billion-parameter model on a laptop could have done just as well.
The obvious fix is to swap the smart model for a cheap one. The obvious failure mode is then noticing, a week later, that the cheap model occasionally ships bad code. Not often. Just often enough to erode trust. Switch back to the smart model and the meter resumes.
\nIndex is a terminal-native multi-agent runtime built around the opposite bet: most of the work should run on a cheap executor, and only the hard turns should reach for a frontier model. That part isn't novel — plenty of systems route between model tiers. The part worth talking about is how the escalation happens. Index makes it a tool.
\nAn agent in Index is defined by a JSON file. A research agent looks like this:
\n{\n "name": "research",\n "role": "research-analyst",\n "model": "ollama/qwen2.5-coder:7b",\n "advisor_model": "claude-opus-4-6",\n "goal": "Research topics with depth. Synthesize findings."\n}\nmodel is who does the work. advisor_model is who gets consulted when the work gets hard. The executor's system prompt describes the advisor, when to use it — ambiguous tradeoffs, multi-step planning, decisions the executor doesn't feel confident making — and a budget, typically two consults per turn.
When the executor decides it needs help, it writes this into its own response:
\n/advise Should these two API responses be treated as duplicates or merged?\nThe fields overlap 80% but the "source" field differs. Dedupe on\nrequest_id or on payload hash?\nThe runtime parses that line out of the response, builds a one-shot API call to the advisor model, and returns the answer as a tool result in the next turn. The executor reads the answer and proceeds. The advisor's tokens are billed at the advisor's rate but attributed to the executor's ledger, so /tokens shows exactly how much of each agent's spend went to its own model versus the seniors it consulted.
That's the mechanic. The design choice hiding inside it is the part worth writing about.
\nMost systems make escalation a decision the framework makes for the agent. A confidence score triggers a fallback. An uncertainty classifier routes the request. A learned dispatcher between the caller and the agent decides when to bring in the smart one. The agent never knows it was second-opinioned, and the user never knows why the decision was made.
\nThat's convenient, and it feels like progress — who wouldn't want less work? — but it buys a specific kind of debt. Escalation isn't debuggable, which means it can't be tuned, which means the framework either over-escalates (paying for a router call on every turn) or under-escalates (missing cases the router couldn't classify). And because the framework does the deciding, the executor never has to notice when it's in over its head. The router does the noticing.
\nMaking escalation a tool puts the noticing back on the agent. The executor has to read its own reasoning and decide: am I confident enough to proceed, or is this the kind of thing to ask about? That's a harder prompt to write. It's also a more honest one. Small models tend to over-consult, large models tend to under-consult, and most real agents need a system prompt that nudges them to do both well.
\nThe reward for putting the work in is that escalations are explicit and debuggable. A consultation in the transcript means the executor chose to ask. No consultation means it didn't feel the need. The behavior is legible in a way a hidden router can't be.
\nThe other decision worth naming: the advisor sees only the question text. No conversation history, no file context, no prior tool results. The API call is literally a single user message with a terse system prompt asking for a direct answer, no preamble.
\nThat sounds like a limitation. It's the single best thing about the pattern.
\nForcing the executor to frame its question as a self-contained one-shot produces two effects. First, the executor has to articulate the decision in full — the tradeoff, the constraints, why it's stuck. Articulation is often where the answer becomes obvious; a nontrivial fraction of consultations are never sent because the executor realizes mid-framing that it already knows what to do. Second, the advisor call stays small. One user turn, one response, maybe 1500 tokens end to end. It caches well, costs less than a single turn of a long-context conversation, and doesn't pollute the advisor with the executor's working memory.
\nHistory-lessness is a constraint that produces better questions. Nothing about the design planned for it to work that way. It just does.
\nThe routing layer — the thing that decides which agent (not which model) handles a user's request — is embarrassingly low-tech. A master agent called index receives every incoming request, reads a roster of the specialist agents in the current session along with their roles and goals, and follows rules like these in its system prompt:
Route based on what is being requested:\n - Research, facts, URLs → /agent research\n - Code review → /agent reviewer\n - Essays, docs, reports → /agent writer\n - Shell, git, Docker, infra → /agent devops\nThat's the entire router. No embeddings, no classifier, no learned dispatcher. The master reads the rules and the roster and picks an agent by writing /agent research <task> into its response — exactly the same way the executor writes /advise.
The obvious objection is that this should be smarter. The counter is that routing wrong in ways a developer can read beats routing right in ways no one can debug. When a task goes to the wrong agent, the reason sits on the screen. Changing how routing works is editing a text file.
\nDelegation is also capped at two levels. A user's request reaches the master, the master can delegate once, and the specialist can delegate once more to a sub-specialist. Any attempt deeper returns an error string to the caller, which the agent has to handle. This prevents the long tail of multi-agent horror stories where something loops itself into bankruptcy. It also means agents occasionally have to punt work back to the user, which is the point. A shallow, legible tree beats a deep opaque one.
\nAfter a typical session, /tokens prints something like this:
index claude-sonnet-4-6 $0.08 (42k input, 3k output)\nresearch ollama/qwen-7b $0.00 (local)\n advisor → claude-opus-4-6 $0.03 (2 consultations)\nreviewer claude-sonnet-4-6 $0.04 (18k input, 2k output)\nThe research agent did most of the heavy lifting. It ran locally and cost nothing. When it needed judgment, it consulted Opus twice, for three cents total. The reviewer ran at Sonnet rates on work that actually needed Sonnet. The master just did routing.
\nThis isn't the only way to build a multi-agent runtime, and it isn't always the right way. It's a version a developer can reason about. When something goes wrong, the transcript shows the decision the agent made. When a bill comes in higher than expected, the ledger shows which model consumed the budget and why. When an escalation feels wrong, tuning the advisor's system prompt changes the rate.
\nAutomatic routing solves a real problem. It also solves that problem by hiding the thing most worth understanding. The trade Index makes is to leave the escalation visible, put it in the agent's own hands, and pay the occasional tax of writing a prompt that teaches a model to know when to ask for help.
\nWhich is what a senior engineer does anyway.
\n"}]}