An AI system can look impressive on an architecture diagram. One agent plans the work, another researches, another checks customer records, and another prepares the response.
For the person waiting for an answer, the important questions are more direct: did the system understand the request, use the right information, and complete the task correctly?
Anthropic’s October 22, 2026 guidance brings attention to that gap. Across several enterprise deployments, its Applied AI team found that a single agent supported by reusable skills frequently performed better than more elaborate agent arrangements, often with lower cost and latency. These are deployment observations, rather than a universal benchmark. Read Anthropic’s guidance.
For business leaders, our interpretation is straightforward: an automation proposal should explain why its structure helps the work get done.
Anthropic suggests reviewing specialist agents that could become instructions or tools available to a main agent. Instructions can be loaded when relevant, rather than placing every procedure into one enormous prompt.
Its guidance preserves a role for subagents, including independent parallel work, verification, and tasks that need separate context. The decision depends on measurable performance and the boundaries of the work. See the recommended design considerations.
This gives businesses a useful question to put to an implementation partner: what does each additional agent contribute, and how will we verify that contribution?
Consider a hypothetical service business receiving a request for a website redesign.
The customer has included their current website, a preferred launch date, and a rough description of the problem. They have also asked whether the business provides ongoing maintenance.
A proposed system might assign separate agents to classify the enquiry, identify services, assess timing, and draft a response.
Before accepting that design, the business could test a simpler alternative. One agent could read the complete enquiry, retrieve the approved service information, check the account record, and prepare a response for staff review.
The acceptance criteria should reflect the customer’s actual request:
This example illustrates how to evaluate a design. It does not establish that one agent will always handle enquiries better.
Some tasks do not require an agent to decide how the whole process should run.
If an enquiry must always be recorded, assigned to an account owner, and acknowledged using an approved template, much of that sequence may fit a conventional workflow.
Anthropic distinguishes workflows, where code defines the path, from agents, where the model decides how to proceed. Its foundational guidance recommends starting with the simplest workable approach and adding complexity when the task justifies it. Read “Building effective agents”.
For the hypothetical enquiry system, that could mean combining fixed steps with a limited AI task: software handles recording and assignment, while AI helps interpret the enquiry and prepare a draft.
The business then has a clear place to inspect the AI’s contribution.
Research provides a different example. A team investigating several markets may have independent questions about competitors, customer needs, distribution, and local conditions.
Anthropic’s research system uses a lead agent to coordinate parallel investigations and combine the findings. Its published engineering account describes benefits for broad research tasks, alongside increased token use and coordination challenges. Those findings concern its particular research setup and models. Read how Anthropic built its research system.
For a business commissioning similar work, the useful design question is whether each investigation can proceed independently and return evidence that another reviewer can assess.
If every investigator needs constant updates from every other investigator, the proposed boundaries deserve closer examination.
A practical evaluation should begin with representative tasks from the business.
For the enquiry example, include a straightforward request, an existing customer, an incomplete submission, and a request containing conflicting requirements. Keep the expected handling explicit.
Then compare alternatives using the same cases. Record correctness, response time, operating cost, and the amount of staff correction required. Repeat cases where inconsistent behaviour would matter.
A response that reads well but omits a customer requirement should count as a failure. A faster system that creates more review work may offer little operational benefit.
For teams considering AI automation, this development makes the discovery and design stages especially valuable. The process needs a defined outcome before anyone chooses how many agents to build.
That connects directly to Metaveo’s automation approach, which includes workflow discovery, architecture, integration, validation, and measurement.
A useful starting brief is one recurring task, the information required to complete it, the actions permitted, and the evidence a reviewer needs to accept the result.
That brief gives the team a concrete basis for choosing between a fixed workflow, one agent, or several—and for deciding whether the implementation delivers value.