Claude Managed Agents: A Real Use Case, End to End

Most writing about agents stops at the demo. The agent answers a clever question, calls a tool, returns a tidy result, and everyone nods. The hard part — the part that decides whether you actually ship — is everything between the demo and the day the agent runs unattended against real data. So instead of theory, let me walk through one realistic build end to end: an invoice reconciliation agent, the kind of unglamorous back-office task where managed agents earn their keep. I will keep the company anonymous and the details representative, but the shape is exactly how these projects go.

The starting problem is familiar. A mid-sized company receives hundreds of supplier invoices a month as PDFs and emails. A finance analyst opens each one, finds the matching purchase order and goods-receipt record in the ERP, checks that quantities and amounts line up, flags discrepancies, and either approves the invoice for payment or kicks it back. It is rote, it is slow, it is error-prone at the end of a long day, and it is exactly the kind of judgment-plus-lookup work that a Claude Managed Agent can do well — if you build it carefully.

Framing the problem before writing a prompt

The first move is not to write a prompt. It is to watch the analyst work and write down the decision they actually make, because that decision is your specification. Watching, the real logic surfaces: extract the line items from the invoice, find the PO by number, find the goods receipt, compare quantities within a tolerance, compare amounts within a tolerance, check for duplicate invoices, and only then decide approve, hold, or reject. There are also unwritten rules — a trusted supplier under a small threshold gets auto-approved; anything over a larger threshold always goes to a human regardless. Those unwritten rules are the most important thing you will capture, because they are the difference between an agent that is useful and one that is dangerous.

This framing step is where most of the value is created. An agent is only as good as the specification of judgment behind it, and the specification only gets good when someone bothers to make the tacit explicit.

Designing tools and the decision flow

With the decision mapped, the tools almost design themselves. The agent needs to read an invoice, query the ERP, and record an outcome — and each of those becomes a scoped tool with strict inputs and outputs. Critically, the tool that records the outcome cannot move money; it can only mark an invoice as approved-for-payment, hold, or reject, and the actual payment run stays on the existing controlled rails. That single boundary keeps the blast radius small no matter how the agent reasons.

flowchart TD
  A["Invoice arrives (PDF/email)"] --> B["Agent extracts line items"]
  B --> C["Tool: find PO & goods receipt"]
  C --> D{"Quantities & amounts within tolerance?"}
  D -->|Yes, trusted & small| E["Mark approved-for-payment"]
  D -->|Yes, but over threshold| F["Route to human approver"]
  D -->|No / duplicate / missing PO| G["Mark hold & explain discrepancy"]
  E --> H["Write outcome + reasoning to audit log"]
  F --> H
  G --> H

Notice that the agent never directly pays anything. It makes a recommendation and records reasoning; the irreversible step stays gated. This is the use-case-level version of the irreversibility principle, and it is what lets the team feel comfortable letting the agent run. The prompt that drives this is written like a procedure manual: it states the tolerances as exact numbers, names the trusted-supplier and threshold rules explicitly, and instructs the agent to always explain the discrepancy in plain language when it holds an invoice, because the analyst who reviews the hold needs the reasoning, not just the verdict.

The eval suite that earns trust

Before a single real invoice touches the agent, the team builds an eval set from history — a few hundred past invoices where the correct human decision is already known, including the nasty ones: the duplicate that slipped through last year, the invoice with a transposed PO number, the supplier who changed their billing name mid-year. Each becomes a test case with a known-good answer, and a grader checks whether the agent reached the same decision and, for holds, flagged the same discrepancy.

This eval suite is the project's spine. It is what lets the team change the prompt and instantly know whether they made things better or worse, instead of guessing. The first run is humbling, as it always is — the agent catches the obvious matches but fumbles a few edge cases, approving an invoice with a quantity mismatch the tolerance was too loose to catch. The team tightens the tolerance, adds an explicit duplicate-detection instruction, reruns the suite in minutes, and watches the score climb. Three or four iterations of this loop, each one cheap because the evals are automated, and the agent matches the analyst on the historical set with the remaining disagreements being genuinely ambiguous cases a human should see anyway.

Shadow mode, then a careful rollout

Passing evals is necessary but not sufficient, because history is not live traffic. So the agent goes into shadow mode: it processes every real invoice in parallel with the analyst but commits nothing. For two weeks the team compares the agent's recommendation to the analyst's decision on live data, and every disagreement is a learning opportunity — sometimes the agent was wrong, occasionally the agent was right and the analyst had made a mistake, which is its own quiet validation.

Only after shadow mode agrees with humans consistently does the agent start committing real outcomes, and even then it starts narrow: auto-approving only trusted suppliers under the small threshold, routing everything else to humans exactly as before. As confidence and the audit trail accumulate, the team widens the autonomous band deliberately. Within a couple of months the agent handles the bulk of straightforward invoices unattended, the analyst spends their time on genuine discrepancies and supplier relationships instead of data entry, and every decision the agent made is sitting in an audit log anyone can inspect.

What made it ship fast — and what would have sunk it

The speed came from the managed part: the team never built orchestration, scaling, retry logic, or session management, so their entire effort went into the three things that actually mattered — the specification, the tools, and the evals. That is the real promise of managed agents made concrete. The project did not move fast because the model was magic; it moved fast because the platform absorbed the undifferentiated heavy lifting and left the team free to focus on encoding judgment and proving it.

What would have sunk it is equally clear. Skipping the eval suite would have meant shipping on vibes and discovering the quantity-tolerance bug in production against real money. Giving the agent a tool that could actually pay invoices would have turned a tolerable mistake into an unrecoverable one. Skipping shadow mode would have meant betting live cash flow on the assumption that history predicts the present. Every shortcut the team was tempted to take was a shortcut around the discipline that made the result trustworthy. The walkthrough is mundane on purpose, because mundane discipline, applied consistently, is exactly what gets an agent to production ten times faster without getting you fired.

Frequently asked questions

How long does a realistic agent like this take to build?

For a well-scoped back-office task, weeks rather than months — the bulk of which is framing the decision, designing tools, and building evals, not coding infrastructure. Because the managed platform handles orchestration and scaling, a small team can often reach shadow mode in two to three weeks and live autonomy not long after.

Why not let the agent pay the invoices directly?

Because payment is irreversible and high-stakes, it belongs behind a separate controlled rail. Letting the agent only recommend an outcome — approve, hold, or reject — keeps the blast radius of any mistake small while still capturing almost all of the time savings. The agent's judgment is valuable; its unchecked authority over money is not.

What if the agent encounters an invoice unlike anything in the evals?

A good agent design routes the unfamiliar to a human by default. Thresholds, tolerances, and a conservative "when uncertain, hold and explain" instruction mean novel or ambiguous cases land in the analyst's queue rather than being force-fit into an automated decision. The agent earns wider autonomy only as the evidence accumulates.

How do you know the agent is still correct months later?

The eval suite runs continuously as a regression guard, the audit log makes every live decision inspectable, and a sampling of real outcomes gets human-reviewed on an ongoing basis. Together they catch drift — a supplier changing behavior, a new invoice format — before it becomes a systemic error.

Bringing agentic AI to your phone lines

The same problem-to-production discipline — map the decision, scope the tools, prove it with evals, roll out in shadow mode — is how CallSphere ships voice and chat agents that handle real customer work end to end. See a live example at callsphere.ai.

---

Source & attribution: This is an independent, original explainer inspired by Anthropic's coverage on the Claude blog. Claude, Claude Code, Claude Cowork, Claude Opus, and the Model Context Protocol are products and trademarks of Anthropic. CallSphere is not affiliated with or endorsed by Anthropic.