One generalist agent or several specialists: how to choose

In 60 seconds: Start with one agent and one bounded workflow. It can cover several tasks when they share data, policies, permissions, and a similar definition of quality. Split it when tests show confusion between tools or instructions, one function needs more sensitive access, or each area requires different evaluations and owners. Multiple agents do not add mysterious intelligence. They separate context, memory, tools, permissions, and instructions. That separation can improve control, but it also adds model calls, handoffs, synchronized state, and new failure points. A coordinator can preserve one interface for users when its routing and synthesis costs are justified.

A company wants to automate sales follow-up and administrative work. The first question is often whether one agent can handle both. Technically, it can. The useful question is whether it can do so with clear boundaries, measurable results, and reasonable access to company systems.

An agent that prepares CRM follow-ups and another that builds ERP reports may use exactly the same model. Specialization comes from the configuration around that model. The instructions, data included in each run, available tools, credentials, and review criteria can all differ.

OpenAI describes an agent in terms of a model, tools, and instructions, and recommends maximizing a single agent first. Its guide suggests splitting when logic becomes hard to follow or the agent repeatedly chooses the wrong tool among similar options. This is a better starting point than mirroring the org chart. Four departments do not automatically require four agents.

What each pattern means

A generalist agent uses one operational configuration for several kinds of request. It may select different tools and adapt instructions to the task, but it keeps one identity, one execution loop, and usually a common access and oversight policy.

A group of specialized agents separates some of that configuration. A sales specialist might read opportunities and prepare tasks. A reporting specialist queries approved views and produces a report. A coding specialist works in a repository, while an SEO specialist reviews pages or prepares CMS changes. They can respond directly or work behind another component.

The useful boundary has five parts:

Part	What to ask before splitting
Instructions	Do the rules conflict, or do they only need clearer organization?
Context and memory	Do tasks share useful history, or does each carry irrelevant data into the other?
Tools	Are their names and uses clear, or does the agent confuse similar actions?
Permissions	Should every task have the same read and write access?
Evaluation	Can every function use the same cases, risks, and approval criteria?

This list keeps the decision grounded in system design. If two agents use the same model, splitting does not automatically improve its underlying capability. It changes the information and operational power available to each run.

One agent compared with several

Dimension	One generalist agent	Several specialist agents
Context	Reuses shared history and handles requests that cross functions. It may also accumulate irrelevant material.	Each run can receive less, more focused information. Shared facts must be transferred or retrieved again.
Latency	A direct path usually needs fewer decisions and calls.	Routing, delegation, and synthesis can take longer. Independent work can run in parallel when the task allows it.
Cost	Shares infrastructure and may solve a request in fewer steps. A large context or oversized model can still be expensive.	Supports a different model and budget for each function, but every handoff and verification consumes resources.
Accuracy	Works well when tools and policies are compatible. Overlapping instructions can cause confusion.	Narrow scope makes specific instructions easier to write. End-to-end accuracy still depends on correct routing and handoffs.
Evaluation	Has fewer components, although the test set grows with each function.	Each specialist can have its own cases and metrics. The coordinator and agent combinations also need testing.
Permissions	One identity is simple to operate but can accumulate access over time.	Credentials can be scoped by function. The team must govern more identities, secrets, and audit records.
Maintenance	A change ships in one place. Instructions may become long and fragile.	Teams can update one function without touching the others. Versions, contracts, and handoffs add work.
User experience	Provides one entry point and preserves a cross-functional conversation more easily.	Gives focused answers when the user chooses correctly. Without coordination, users may repeat context or decide where to go.

Anthropic recommends adding complexity only when it is needed and notes that systems with more steps tend to trade latency and cost for better task performance in appropriate cases. There is no free improvement. Compare architectures on real workflow cases, not on agent count.

When one generalist is enough

One agent is a strong candidate when tasks share a system of record, policy, and risk level. Consider an internal assistant working on a defined sales account. It can summarize an opportunity, find a missing next step, and prepare the sales section of a weekly report. The work comes from the same approved CRM views, uses read access, and remains subject to review.

It can also handle different tools when their purposes are distinct. Actions named find_opportunity and create_report_draft are easier to distinguish than several vague search or update tools. Before splitting, improve names, parameters, instructions, and error handling, then run the evaluation set again.

Shared memory helps when a request depends on the previous one. “Show me opportunities with no activity” followed by “summarize the first three for my meeting” should preserve filters and source references. An early split may force the system to reconstruct that state at every handoff.

Context design matters as well. Anthropic defines agent context as the set that includes instructions, tools, external data, and message history. Sending everything available does not guarantee a better answer. In this guide, context is a budget selected for the task.

For the broader rollout around this decision, the guide to AI agents for business covers three pilot workflows and the controls to set before granting write access.

Four examples where the boundary moves

Sales follow-up

A bounded agent can find opportunities without a next step, explain the evidence, and prepare a task. If it also answers questions about the same pipeline, a generalist remains reasonable. A split becomes more useful when country, brand, or channel policies conflict, or when one capability can send messages while another must stay read-only.

Our guide to a first agent for recovering forgotten sales shows how to start with one population, one owner, and reviewable actions.

Reporting

A reporting agent can share a model and infrastructure with sales when both query the same views and return read-only results. Separation becomes useful when reporting covers financial close, multiple subsidiaries, or definitions governed by another team. Finance does not need a magically smarter agent. It needs different sources, permissions, cutoff rules, and tests.

Coding

A coding agent needs repositories, a terminal, tests, and review rules. This is a strong boundary from a sales assistant because its tools can modify code and trigger pipelines. The guide to safe repository access for a coding agent explains how to scope the account, repository, environment, and approvals.

SEO

Reviewing titles, internal links, and structured data can begin as a tool within the same agent that maintains a site. CMS publishing changes the decision. It introduces write access, editorial control, canonical URLs, and a different risk from producing a recommendation. If the same evaluation cases do not cover analysis and publication, separating the capabilities may make control easier.

The coordinator and specialists pattern

A coordinator receives the request, chooses the relevant specialist, and combines the result. The user keeps one conversation while specialists operate with scoped instructions and tools.

The OpenAI Agents SDK orchestration documentation distinguishes two common variants. With a manager, the coordinator remains in control and calls specialists as tools. With a handoff, it transfers the conversation and the specialist becomes the active responder. Code can also route known categories when a team wants more predictable behavior.

This pattern can help with a cross-functional request such as: “review inactive opportunities, calculate this week’s summary, and prepare an update for the internal website.” The coordinator can request structured output from sales, reporting, and SEO, then present one response.

The contracts between components need explicit design:

• the data each specialist receives and what remains excluded
• the required output format
• how outputs cite source records
• what happens when sources conflict
• where shared state lives
• which actions require approval
• the time, cost, and retry budget for each run

The coordinator can fail too. It may choose the wrong specialist, drop a filter during a handoff, duplicate work, or combine incompatible answers. Its decisions need traces and evaluation cases. If almost every request goes to one specialist, the coordination layer is probably unnecessary.

Permissions are a valid reason to split

Separate identities can reduce the impact of an error. A reporting agent does not need to deploy code. An SEO reviewer does not need publishing access. A sales agent that prepares a draft does not need permission to approve discounts.

Control AC-6 in NIST SP 800-53 defines least privilege as allowing only the access needed to perform assigned tasks. For agents, that supports function-specific credentials, temporary access where appropriate, and extra approval for sensitive actions.

Creating more agents does not apply least privilege by itself. If every agent inherits the same administrator account, the separation exists only in prompts. A real boundary requires credentials or policies that the surrounding system enforces outside the model.

Signals that it is time to split

A split is justified when tests or production runs show repeated evidence:

• the agent still chooses the wrong tool after names and descriptions have been improved
• correct instructions for one function interfere with another
• one task carries sensitive or irrelevant context into requests that do not need it
• one function needs write access or data the others should never receive
• teams need independent release cycles, owners, or evaluation suites
• part of the workflow can run in parallel and the benefit exceeds coordination costs
• incidents are hard to attribute inside an overly broad configuration

A severe incident should not be the first signal. A bank of evaluation cases can reveal the boundary before access expands.

Signals of overengineering

The architecture is ahead of the problem when:

• each specialist owns one tool and they always run in the same order
• deterministic code could route the workflow with less cost and variation
• several agents share almost identical models, instructions, credentials, and context
• users repeat information because no component preserves state correctly
• the team has more tests for handoffs than for the business result
• nobody can name the failure each separation is meant to fix
• task volume or value cannot support the added operations work

Functions, modules, or fixed workflow steps can provide technical separation in these cases without turning every component into an agent.

A practical decision tree

1. Does the task have a clear trigger, output, and owner? If not, narrow the workflow before selecting an architecture.
2. Do the functions share data, policies, permissions, and evaluation criteria? If yes, test one agent with clearly bounded tools.
3. Does it repeatedly fail because instructions are complex or tools overlap? Improve descriptions, parameters, and context first. Split if the problem remains in evaluations.
4. Does one function need much more sensitive permissions or data? Separate its operating identity even if users keep one interface.
5. Do users know which function they need? Let them access the specialist directly. A coordinator is optional.
6. Do requests commonly cross functions and need one answer? Test a coordinator with structured contracts, limits, and traces.
7. Does the improvement exceed the added latency, cost, and maintenance? Keep the split architecture only if measurement confirms it.

How to evolve from a small workflow

Start with one valuable task and a set of real cases, including missing data, ambiguous requests, and prohibited actions. Run one agent in read-only mode or with human approval. Record the result, selected tools, time, cost, corrections, and exceptions.

Next, organize the implementation by capability even while one agent remains. Keep sales, reporting, coding, or SEO tools, policies, and tests in identifiable modules. This prepares a future split without paying the coordination cost yet.

When a boundary fails persistently, extract only that function. Give it its own context, permissions, and evaluation set. Compare the new version with the baseline: success by case, selection errors, total time, cost, and review load. Add a coordinator when users need one entry point or several functions must collaborate on the same request.

The final architecture may remain one agent, settle on two direct specialists, or add a coordinator. The right count is the smallest one that meets the goal with acceptable quality, scoped permissions, and an operating model the team can maintain.

Kiia designs these pilots around the process and its boundaries. We can map one workflow, define its evaluations, and use evidence to decide whether to expand one agent or separate capabilities. See our approach to systems integration and bring five recent cases to the conversation, including two that went wrong.