One Big AI Agent or Several Small Ones? Scope Decisions

The first design decision anyone makes when building autonomous agents is rarely framed as a decision at all. You describe what you want, the agent gets built, and three weeks later you notice that "my assistant" has quietly accumulated eleven responsibilities, four schedules' worth of work crammed into one, and instructions so long that nobody remembers what half of them do.

This article is about ai agent design at the scoping level: whether to build one broad agent or several narrow ones, how to tell when an agent has grown past its useful size, how to split it, and how to name the pieces so you can still find them in six months. The short answer is that single-purpose agents beat kitchen-sink agents almost every time, and the interesting part is understanding exactly why, because the reasons tell you where the exceptions live.

We will use Skopx's Create Agent as the concrete reference, since its anatomy makes the tradeoffs visible: every agent has plain-language instructions, one trigger, per-integration grants, budgets, success criteria, and its own memory. But the principles apply to any platform where agents have those parts.

Why the kitchen-sink agent is so tempting

Nobody sets out to build a monolith. It happens through a sequence of individually reasonable additions.

You start with an agent that triages your inbox every morning. It works. A week later you think: while it is in there, it might as well flag invoices that are overdue. Then: it already reads email, so it could also watch for customer complaints and post them to Slack. Then: since it posts to Slack anyway, it could summarize yesterday's support threads too. Each addition is one sentence in the instructions. None of them feels like a new agent.

The pull toward one big agent comes from three honest instincts:

1. Fewer things to manage. One agent means one schedule to remember, one set of connected tools, one place to look.
2. Shared context. The agent that reads your inbox already knows things the invoice-chaser would need. Splitting them feels like throwing away context.
3. Setup cost. Adding a sentence to an existing agent takes ten seconds. Creating a new agent feels like a project, even when it is not.

All three instincts are real. The problem is that the costs of a broad agent are back-loaded. They show up not at creation time but at debugging time, approval time, and trust time, which is exactly when you can least afford them.

The case for narrow agents, mechanically

The argument for single-purpose agents is not aesthetic. It falls out of how the parts of an agent actually behave.

Instructions degrade under load. An agent's instructions are a prompt, and prompts have a practical attention budget. An agent with one job can have instructions that are specific, testable, and short: "Every Monday, compare this week's HubSpot pipeline to last week's snapshot, list deals that moved stage or went quiet for 14+ days, and write a report." An agent with six jobs has instructions where the pipeline logic sits next to the invoice logic sits next to the Slack summarization rules, and every run has to route through all of it. The model will occasionally apply rule four's tone guidance to job two's output, or skip a step because a later paragraph seemed to supersede it. Narrow instructions fail less and fail more legibly. Our guide to writing agent instructions goes deeper on this, but the scoping decision comes first: no amount of careful wording rescues an agent that is doing too many unrelated things.

Triggers do not compose. In Skopx, an agent has a trigger: manual, a schedule like "Every Monday at 9:00 UTC", or a webhook. A monolith forces every job onto the same cadence. If inbox triage should run every morning but the pipeline review is weekly, the combined agent either runs the weekly job daily (wasteful, noisy) or the instructions grow date-conditional logic ("if it is Monday, also do...") that is a classic source of silent failure. Two agents, two triggers, zero conditionals. The triggers guide covers cadence choices in detail; the relevant point here is that "these jobs want different triggers" is the single most reliable signal that they are different agents.

Grants become the union of everything. Each Skopx agent gets grants per integration toolkit, with tiers: runs automatically, asks first every time, agent decides when to ask, or drafts-only. A narrow agent gets narrow grants. The competitor-monitoring agent needs web search and maybe Notion write access, nothing else. The kitchen-sink agent needs the union: Gmail, Slack, HubSpot, Stripe, Sheets, all live in one agent's blast radius. That matters for two reasons. First, least privilege: an agent that goes sideways can only misuse what it holds. Second, approval ergonomics: with everything in one agent you end up setting broad grants to "asks first every time" out of caution, and then you are approving Slack reads because you were worried about Stripe writes. Splitting lets each agent's approval posture match its actual risk, which is the core idea behind human-approval patterns.

Budgets stop meaning anything. Skopx agents carry budgets: tokens per run, tokens per day, max steps, a minute cap, and three budget failures auto-pause the agent. Budgets are a safety instrument, and they only work when a "normal run" has a stable shape. A single-purpose agent's runs look alike, so you can set the token ceiling just above normal and treat any breach as a real anomaly. A six-job agent's runs vary wildly depending on which jobs fired and how much they found, so the budget has to be set for the worst legitimate case, which means it never catches the moderately-broken case. Worse, the auto-pause is collective punishment: three budget failures in the invoice-chasing branch pause the whole agent, and now your inbox triage is dead too because a different job misbehaved.

Success criteria and reports blur. Every Skopx run ends in a markdown report evaluated against the agent's success criteria. "Did the pipeline review cover every open deal?" is checkable. "Did the agent do all nine of its jobs adequately?" is not, and the report for a multi-job run becomes a wall of loosely joined sections that nobody reads closely. Reports you do not read are runs you do not audit.

Debugging is proportional to scope. When a narrow agent produces a wrong report, the step timeline is short and the fault is usually obvious within a few expanded steps. When a broad agent produces a wrong report, you first have to work out which job the failure belongs to before you can even start. The practical techniques in debugging agent runs all get easier when the run only ever does one thing.

The honest case for consolidation

Narrow-by-default does not mean one-tool-per-agent. There are real costs to over-splitting, and they deserve a fair hearing.

Shared memory is genuinely valuable. Skopx agents have memory that persists between runs: cursors, baselines, the state that makes second runs produce delta reports instead of full rescans. Memory belongs to the agent. If your churn-signal watcher and your renewal-reminder agent both need "when did we last hear from account X", splitting them means each maintains that knowledge separately, or you route shared state through an external store like a Sheet or a database table both can read. That is workable but it is real plumbing. When two jobs continuously feed each other's state, that is an argument they are one job. How agent memory works covers what persists and why it makes reruns cheaper.

Sequencing inside one run is free; across agents it is not. If step B strictly requires step A's output from the same execution ("pull this week's numbers, then write the digest from them"), that is one agent. Two agents on offset schedules can approximate a pipeline, but you have introduced a timing dependency where a late or failed first run silently starves the second. Sequential dependency is the strongest legitimate reason to keep work together.

Agent count has a carrying cost. Every agent is a thing with a schedule, grants, budgets, and a run history you are nominally supervising. Ten well-scoped agents are easier to trust than one monolith, but forty agents you have stopped reviewing are worse than either. Skopx's workspace shows every agent in a rail beside the open one, which helps, but no UI rescues a fleet you have mentally abandoned. If you would not notice an agent being paused for two weeks, you probably should not have built it as a standing agent at all.

Some jobs are one job wearing three hats. "Read new support emails, classify them, and post the urgent ones to Slack" sounds like three functions but it is one pass over one stream with one output. Do not split along tool boundaries. Split along job boundaries.

A decision table

Score it honestly. In practice most kitchen-sink agents lose on four or more rows, and the "same trigger" row alone settles the majority of cases.

When to split: the tells

An agent that started well can grow past its scope. Watch for these signals in the run history, since the runs tell you before your intuition does:

• Conditional instructions appear. The moment you write "if it is Friday" or "only when triggered by the webhook, also...", you have two agents cohabiting.
• Token counts diverge. Skopx shows duration and token count per run. If your runs cluster into two distinct sizes, you are looking at two workloads sharing a name, and your budget protects neither well.
• Approvals mix severities. If your pending-approvals queue for one agent mixes trivial Slack posts with customer-facing email sends, the grant tiers cannot be set correctly for both. Split so each agent's approval posture is uniform.
• The report has chapters. When you find yourself skimming past sections of the run report to get to the part you care about, the part you care about wants its own agent, its own report, and its own success criteria. More on making reports worth reading in agent reports.
• You hesitate to edit. If changing the invoice rules makes you nervous about breaking the triage behavior, the coupling exists only in the prompt, which is the worst place for coupling to live.

How to split without losing your history

Splitting an agent is not destructive if you sequence it right. In Skopx, instructions are editable and versioned, run history is append-only, and pausing an agent is a kill switch for queued runs, which gives you a clean procedure:

1. Create the new agent first. Describe the carved-out job in chat at Create Agent. Give it only the grants that job needs, its own trigger, and budgets sized to its actual runs.
2. Run it manually a few times. Before it takes over, trigger it by hand and read the reports. Set write-shaped grants to drafts-only or asks-first while you validate, the same pattern described in testing agents safely.
3. Edit the original's instructions to remove the carved-out job. Instructions are versioned, so the previous behavior is recoverable if you split along the wrong seam.
4. Migrate state deliberately. The new agent starts with empty memory, so its first run is a full pass and a fresh baseline; expect a bigger first report and cheaper deltas afterward. If the old agent held a cursor the new one needs, state it in the instructions ("treat 2026-08-01 as the starting point").
5. Watch both for a cycle or two. The failure mode of a split is a job falling into the gap between the two agents, with each one assuming the other covers it. One explicit read of both agents' reports in the same week catches this.

At no point do you delete anything. The old agent's run history remains intact and auditable, which matters if you ever need to reconstruct what happened during the transition.

Naming and organizing a fleet

Names are the interface to a fleet of narrow agents. Two rules cover most of it.

Name the job, not the technology. "Weekly pipeline review" beats "HubSpot agent". Tool-based names invite scope creep, because every HubSpot-adjacent task looks like it belongs in "HubSpot agent". Job-based names resist it: nobody tries to stuff invoice chasing into something called "Weekly pipeline review".

Encode the cadence when there is one. "Morning inbox triage", "Monday KPI digest", "On-signup lead enrichment". When the rail shows a dozen agents, cadence-in-the-name lets you audit at a glance whether the schedule and the name still agree. A useful discipline: if you cannot fit the job and cadence into five words, the agent may be doing too much to name, which is itself a scoping signal.

Beyond naming, run a periodic census. Once a month, scan the rail and ask of each agent: when did it last run, did anyone read the report, and would anything break if it were paused? Pause the ones that fail all three. A paused agent costs nothing and keeps its history; a forgotten active agent is spend and risk with no supervision. Broader patterns for organizing agents across a team are covered in agent team patterns.

Worked example: splitting a "revenue assistant"

A concrete, hypothetical walkthrough. Suppose you built one agent, "Revenue assistant", that grew to do four things: daily inbox triage for the sales alias, weekly pipeline review against a HubSpot snapshot, invoice chasing via Stripe and email drafts, and a Monday KPI digest from Postgres.

Run the table. Triggers: daily, weekly, event-ish, weekly. Fail. Shared same-run outputs: none, each job stands alone. Shared state: the pipeline review and KPI digest both use baselines, but different ones. Risk: invoice chasing drafts emails to customers, everything else is read-mostly. Fail. One success criterion: impossible.

The split that falls out:

• Morning sales triage. Daily trigger. Gmail read plus Slack post, runs automatically. Small per-run token budget because runs are uniform.
• Monday pipeline review. Weekly trigger. HubSpot read-only. Memory holds last week's snapshot; every run after the first is a delta report.
• Invoice chaser. Its own schedule. Stripe read plus Gmail in drafts-only mode, so every outbound email is a draft a human sends. This is the one agent where "asks first every time" on any send-shaped action is non-negotiable.
• Monday KPI digest. Weekly trigger. Postgres read-only through SQL with bound parameters, report to Slack.

Four agents, four one-screen instruction sets, four budgets that each mean something, and an approvals queue where everything pending is invoice-related and therefore worth reading carefully. The monolith's history stays where it is, paused, auditable, and recoverable.

Limits worth admitting

Splitting is not magic, and a few caveats keep expectations honest.

Narrow agents do not eliminate failure; they localize it. A well-scoped agent still misreads a thread or misses an edge case, and you still need to read reports, especially early. Cross-agent coordination is real work: Skopx agents do not share memory with each other, so anything two agents both need must flow through an external store or be independently derived, and that duplication has a cost. And splitting multiplies fixed per-run overhead slightly: four agents each load their own context, where the monolith loaded one. For most teams the reliability and auditability gains dwarf that overhead, but it is not zero.

Finally, scoping is not permanent. Agents whose jobs converge can be merged by the same procedure in reverse: build the combined agent, validate it manually, pause the originals. Treat scope as something you revisit when the run history argues for it, not as a decision you must get right on day one.

FAQ

How many agents is too many?

There is no fixed number; the real limit is supervision. The test is per-agent: if an agent could sit paused for two weeks without anyone noticing, it is not earning its place as a standing agent, regardless of whether you have five agents or fifty. A monthly census of the rail (last run, last read report, would-pausing-matter) keeps the count honest. Most individuals land somewhere between three and ten active agents; teams run more because supervision is distributed.

Is it wasteful to have several agents connect to the same tool?

No. Grants are per-agent, and three agents each holding a narrow Gmail grant is a better security posture than one agent holding a broad one, because each agent can only misuse what it was given and each approval queue stays interpretable. The connection itself is not duplicated effort; the same connected integration backs all of them. What you should avoid is several agents writing to the same destination without coordination, for example two agents both posting to one Slack channel on overlapping schedules, which reads as noise.

Can two Skopx agents share memory?

Not directly. Each agent's memory (cursors, baselines) is its own. If two agents need shared state, route it through something both can reach: a Google Sheet, an Airtable base, or a database table one writes and the other reads. If you find the shared state is large and continuously bidirectional, take that as evidence the two jobs may actually be one agent.

Should I split by tool, by team, or by job?

By job, almost always. Tool-based splits ("the Gmail agent") attract unrelated work that happens to touch that tool. Team-based splits can make sense as a second-level grouping, but within a team the unit should still be a job with one trigger, one testable outcome, and one risk profile. If you can state the job and its cadence in five words, you have scoped it about right.

Does splitting an agent lose its run history?

No. Run history in Skopx is append-only and stays with the original agent even after you pause it or edit its instructions. The new agents start their own histories from zero, which also means their memory starts empty: expect the first run of each to be a full pass that establishes baselines, with cheaper delta runs after that.