Make each agent do less — cost and incident response both improve

Two unrelated problems on the same platform — an expensive support assistant and slow incident triage — were solved the same way: narrow what one agent is responsible for.

A single large prompt trying to handle authentication, billing, troubleshooting, and retention at once becomes slow, expensive, and hard to evaluate — every response pays for capability it did not need.

The instinct to add capability to one prompt

The easiest way to make an assistant handle more is to teach one prompt more things: more tools, more instructions, more edge cases folded into the same system message. It works at first, and it fails quietly — every request starts paying the token and latency cost of capability it didn't need, and evaluation gets harder because a single response can be wrong for reasons that live in four different domains at once. Two places on this platform hit that failure mode from different directions, and both were fixed by shrinking what one agent owns rather than growing what it knew.

System design: one supervisor, four narrow workers

The customer and user-support assistant splits authentication, billing, troubleshooting, and retention into four specialist workers behind a single concierge supervisor, instead of one prompt carrying all four domains.

• The concierge supervisor runs the larger, more capable model — but only for triage, delegation, conflict resolution, and final response assembly, not for every step of every task.
• Each worker runs a smaller, cheaper model and receives only the tool schemas relevant to its own domain: the account worker cannot read billing data, and the billing worker cannot alter permissions.
• The supervisor is the only component that sees the full conversation, which is what keeps the audit trail for a multi-domain request coherent instead of scattered across four independent tool calls.

Running the expensive model only at the supervisor layer, and a cheap model at every worker, is the direct lever behind the platform's cost profile — most requests are narrow once triaged, so a small model handles them correctly and the large model is reserved for the one step that actually needs it.

What shrinking each worker's scope buys, concretely

• A smaller tool manifest per worker means fewer tokens spent selecting the right tool, and less room for the model to pick a similar-sounding wrong one
• Stable system instructions and tool schemas are cached at the prompt level, so repeated calls to the same worker don't re-pay the cost of static context every turn
• Every worker call carries a token and step budget and exits as soon as its narrow task contract is satisfied, instead of continuing to generate
• A worker that only ever sees one domain is also easier to evaluate — a wrong answer has one plausible cause, not four

None of these techniques is exotic on its own. What makes them compound is that they all follow from the same decision: give each agent less to be responsible for, and the savings show up at every layer that touches it.

System design: the same narrowing, applied to who investigates an outage

The second place this shows up has nothing to do with cost. Production exceptions on this platform don't wait for an on-call engineer to open a dashboard — they stream through a dedicated observability agent whose only job is to investigate one failure and hand off a pre-debugged ticket.

The agent parses the stack trace and exception metadata, runs diagnostic checks against infrastructure APIs to isolate the failing component, and — only when the failure risks data integrity — takes a bounded, reversible protective action such as pausing a pipeline, rather than only observing and waiting. It is built on the same typed, IAM-scoped tool-agent pattern as the finance and real-time data agents elsewhere on the platform, so its actions pass through the same audit stream as every other agent, not a separate, less-governed path just because it's infrastructure-facing.

Why "narrow the agent" beats "make the agent smarter" for MTTR

An engineer paged with a generic failure alert still has to do the investigation themselves: reproduce the context, find the failing component, form a hypothesis, check it, and only then start fixing anything. Narrowing the observability agent's job to exactly that investigation — and requiring it to produce a named root cause and a named fix, not a summary — removes that entire phase before a human is involved at all. The improvement in mean-time-to-resolution is not from paging faster. It's from deleting the step where a person has to rediscover what the system already knows.

From production: the ticket that already named the file and line

A source table renamed a column an ingestion pipeline depended on. Instead of a generic "pipeline failing" alert reaching an engineer, the observability agent's investigation produced an alert stating the pipeline was paused, a root cause naming the exact column rename in the `users` table, an automated action already taken — pausing the active ingestion batch through Step Functions before a single corrupted row could be written — and a remediation instruction pointing to the exact file and line to fix. The protective action and the diagnosis both completed before the human ever opened the ticket.

The concierge model's savings and the observability agent's speed come from the identical architectural move, applied to two different resources. The concierge model narrows what one model call is responsible for, so most requests are cheap. The observability agent narrows what one investigation is responsible for, so most incidents arrive at a human already diagnosed. Neither result required a more capable model — both required deciding, deliberately, what a single agent should not have to carry.

What to carry forward

• Split a growing prompt along domain boundaries before adding more capability to it
• Reserve the expensive model for triage and delegation, not for every step every worker takes
• Give each worker only the tools its own domain needs, not the full platform catalog
• Apply the same narrowing to operational agents — investigation scope, not just conversation scope
• Measure whether an agent's output removes a step for a human, not just whether it's accurate

Applied in the portfolio

• Enterprise Knowledge Base Multi-Agents on AWS Bedrock — A governed AWS Bedrock knowledge platform for multi-source ingestion, multi-agent reasoning, semantic retrieval, observability, and FinOps.