Disclosure: Oleh Hebel founded Interface Report and runs Oleh Hebel & Co and Ship Index Grow, projects related to product design and AI education. No sponsor paid for or reviewed this article.

Direct answer: Some sequential subagents may work better as skills and tools in one agent loop. Preserve useful independent workers and compare complete outcomes before changing production.

Your customer asks one question. Your software starts a committee.

A refund request becomes a routing decision, a policy lookup, an account check, a specialist handoff and a final explanation. Somewhere along that path, a small but decisive detail can disappear: the customer already received a replacement. The final answer may sound coherent while the decision behind it is wrong. This is a hypothetical failure, but it captures a useful architecture question: which boundaries help the work, and which merely divide the people building it?

On October 22, 2026, Anthropic published guidance on folding some subagents into a main agent loop. Its Applied AI team reports that, across several enterprise deployments, a single agent using skills frequently delivered better quality and often lower cost and latency than the compared alternatives. Those are vendor observations, not a universal benchmark. The important opportunity is to test whether your own product has more coordination than its tasks require.

The customer pays for the whole decision

Product teams should judge a refund assistant by whether it reaches the right outcome with the right authority. A successful policy lookup is only one piece of that outcome. If the next component cannot connect the policy to the replacement shipment, the customer still gets a bad decision.

My design recommendation is to describe one complete customer outcome before drawing the architecture. Write down the facts that must survive from the initial request to the final action. Include identity, relevant transactions, exceptions and unresolved uncertainty. Then mark every place where those facts change representation. Each mark is a review point, whether the system uses one model call or twenty.

That exercise changes the discussion. Instead of asking how many specialists the platform supports, ask which specialist needs genuinely different context. A separate name, team or prompt is insufficient evidence. The architecture should earn its complexity through observable benefits for the person using it.

Load expertise without handing away the conversation

The alternative described in Anthropic's new guidance combines a main loop with skills and tools loaded when needed. It still recommends subagents for useful separation, including independent parallel tasks and context constraints. This is conditional advice about system design, rather than a declaration that multi-agent systems have failed.

For a product designer, the distinction is simple: a system can acquire a procedure without changing who holds the customer's situation. In our hypothetical refund flow, the assistant could retrieve the returns procedure, inspect the order and check the replacement record while maintaining one account of the request. Whether that works better must be established with your data.

Progressive disclosure also has an interface beneath the interface. Claude's tool-search documentation distinguishes tool definitions sent to the API from definitions loaded into the model's context. Deferred loading controls the latter. Discoverability therefore deserves its own evaluation; hiding an essential tool from the working context is useful only if the agent can reliably find it.

Choose boundaries you can explain

I would keep a separate research worker when it can investigate an independent question and return evidence that another component can check. I would examine a sequential handoff more skeptically when both sides need the same customer history and keep asking each other for missing details. These are proposed review criteria, not performance findings.

There is no contradiction in keeping some workers separate while simplifying the rest. Anthropic's June 13, 2025 account of its research system describes parallel exploration using separate context windows. That older example concerns broad research work; it is context for the tradeoff, not evidence that the same design wins in a transactional support product.

Permissions deserve a separate decision. Suppose a read-only assistant gains the ability to issue refunds during a consolidation. Even an improvement in answer quality would leave a serious authorization question unanswered. My recommendation is to verify permissions at the action boundary and test the denied cases explicitly. A simpler diagram should never become a reason to broaden what an agent can do.

A migration experiment worth running

Begin with a small, representative slice of real tasks that you are permitted to replay. Preserve the starting state and define the acceptable outcome before comparing versions. For the refund example, record whether the replacement should block an automatic refund, which evidence must be consulted and when a person must decide.

Run the current flow and one candidate change against the same cases. Keep model settings and tool access comparable. Include ambiguous requests, missing records, conflicting evidence and a customer asking for an action they are not allowed to perform. Repeat cases to expose inconsistent behavior; one successful answer does not establish reliability.

My proposed scorecard has four parts: correct business outcome, permission compliance, time to a verifiable result and total execution cost. Track human review separately. A fast response that creates extra investigation for a support operator may be a poor product improvement. Examine regressions case by case instead of allowing an average score to hide them.

For teams seeking a starting point, Anthropic links a single-agent loop migration kit. Its README labels it an unmaintained reference implementation and describes limited real-model testing on its example system. Treat it as material to inspect and adapt, with its published limitations intact. Interface Report has not run that kit or tested the performance claims.

Make the result legible to the user

A customer does not need a transcript of every internal handoff. They do need a stable account of what was checked, what remains uncertain and what will happen next. If an architectural change makes those explanations harder to provide, the team should count that as a product regression.

The strongest reason to simplify an agent is to improve the decisions people can rely on. Keep the workers that contribute useful independence. Consolidate only where a controlled comparison supports it. Then give one accountable team responsibility for the complete outcome, including the uncomfortable cases where the correct action is to stop and ask.

Reporting note: Primary sources checked October 23, 2026. Vendor observations are attributed; examples and proposed evaluation criteria are editorial analysis. No hands-on testing is claimed.

Related reading

Sources

Author: Oleh Hebel. LinkedIn