The Reality Of Managing 10 AI Agents In Production

Managing AI agents for business automation becomes a different job when several agents are working at once. The question stops being whether one agent can produce a useful answer. It becomes whether the team can see, review, and recover the work happening across the whole operation.

A sales agent prepares a follow-up. A support agent updates the same account. A research agent finds an outdated policy. Each action can look reasonable on its own while the combined result creates confusion for the customer and cleanup for the team.

In SaaStr's account of building toward ten production agents, Jason Lemkin describes the daily management and review involved. That account is SaaStr's experience, not an Innflow case study. It raises a useful operating question: what must be in place before adding another agent?

Book an operations demo

The following guide is an original operating playbook for a team managing several agents. Ten is an illustrative portfolio size, not a recommendation or a claim about the number of agents Innflow customers run. Start with the work your team needs done, then decide how many separately managed agents are justified.

What changes when you manage an agent portfolio?

One agent can sometimes rely on its builder remembering how it works. A portfolio needs shared records and explicit responsibility. Otherwise, every question about a failed job becomes a search for the person who last changed the instructions.

Each agent introduces an operating surface: inputs, tools, credentials, instructions, outputs, and exceptions. Some of these may be shared. A changed support policy can affect reply drafting, escalation, onboarding, and account research at the same time.

Shared dependencies create shared failures. If several agents rely on one stale document or an unavailable connector, adding more agents does not create resilience. It creates more places for the same weakness to appear.

Book an operations demo

There is also a coordination problem. Two agents can both believe they own a case. One can pass a recommendation to another without making clear that it is unverified. A receiving agent can treat a suggestion as permission to act.

The solution begins with a portfolio view: what each agent is responsible for, which systems it touches, what it may change, and where unfinished work goes. This view should be useful to an operator who has never read the original prompts.

Give every agent a clear operating record

Record the job and its limits

Create an inventory entry for each agent. Include its purpose, owner, backup owner, trigger, allowed tools, record scope, output destination, and escalation route. Link the current instructions and the evaluation cases used to approve changes.

Write the responsibility as a concrete job. “Prepare a summary of unresolved support cases for the morning review” is inspectable. “Own customer success” bundles too many decisions and permissions into a title.

Book an operations demo

Make the limits equally concrete. The summary agent may read selected support records and write an internal draft. It may not promise credits, close cases, or contact customers. Someone reviewing the inventory should understand the boundary without guessing what the agent's name implies.

Assign a person who can intervene

The owner should know what good output looks like and have a way to pause or change the workflow. Assigning ownership to a generic team name can leave incidents unresolved when everyone assumes someone else is watching.

Define the backup arrangement for absences. Specify which issues require technical help and which can be resolved by changing the business process. An expired account token and an unclear escalation policy need different owners.

Give the output a home

An agent's result should arrive where the next person works. A separate chat transcript is useful evidence, but it should not be the only record of a pending action or unresolved exception.

Choose a task queue, review view, document, or existing system of record. Include a stable case identifier so people can connect the result to the source. Avoid creating a second operational ledger that nobody reconciles with the first.

Run daily review around exceptions and sampled outcomes

A daily review should help the team decide what needs attention. It should not require rereading every token an agent generated. Build the review around unfinished work, unusual behavior, and a sample of apparently successful results.

Start with work that did not finish

Inspect paused runs, failed actions, missing inputs, expired approvals, and items waiting beyond the expected response time. For each item, determine who owns the next action and whether the agent may resume automatically.

Separate “waiting for a person” from “waiting for a system.” A review request can sit silently because nobody received it. A tool failure can keep retrying because nobody classified the error as permanent. Both can look like work in progress while nothing useful is happening.

Review successful-looking work too

Failures are not always accompanied by errors. An agent can update the wrong record successfully. It can send an inaccurate reply through a healthy email connection. Sample completed work and compare it with the original request and destination record.

Vary the sample across agents, task types, and unusual inputs. Do not let the easiest recurring task dominate the quality review. Record the defect and its consequence so the team can prioritize corrections sensibly.

Turn observations into changes

Classify the cause before editing instructions. Was the source outdated? Was the tool given the wrong identifier? Did the policy omit a mixed case? Did an external action succeed without a returned confirmation?

Then assign a change and test it against the relevant cases. Keep a record of what changed and why. Repeatedly adding exceptions to a prompt without reviewing the full instruction set can make the next run harder to understand.

Prevent agents from duplicating or contradicting work

Choose one owner for each external action

If a sales agent and a support agent can both message the same customer, decide how they coordinate. One might prepare drafts while a shared workflow owns sending. Alternatively, each might own a clearly separated channel or case type.

Use the business record to establish ownership. An agent should not infer permission to send a message merely because another agent mentioned the customer. The handoff needs to identify the requested action, its scope, and any required approval.

Pass evidence with the handoff

A good handoff includes the case ID, source links, verified facts, unresolved questions, and proposed next step. Distinguish the receiving agent's instructions from quoted customer or document content.

For example, “The vendor says the job is complete” is a source statement. “The job is verified complete” is an operational conclusion. Preserve that distinction so the next agent does not convert a reported status into a confirmed result.

Bound recursive work

Decide whether an agent may delegate, how many additional tasks it may create, and what ends the process. A chain of agents can otherwise keep asking one another for more research without producing a decision the business can use.

Use limits on time, actions, and spending appropriate to the workflow. When a limit is reached, return the current evidence and the unresolved decision to the owner. Stopping with a useful package is better than extending an unproductive loop.

Measure accepted outcomes and management effort

Tool calls, messages, and completed runs measure activity. The operating question is whether that activity produced work the business could accept. Define an outcome for each agent before comparing performance.

A research agent might be measured by the proportion of summaries accepted after source review. A support-drafting agent might be measured by factual corrections and handling time. A coordination agent might be measured by correctly assigned cases and unresolved handoffs.

Include the human effort required to keep the system useful. Review time, investigation, rework, and configuration maintenance belong in the cost of operating the agent. Leaving them out can make an expensive process appear efficient.

A simple proposed scorecard can track these fields:

• Work attempted and work accepted, using a clearly defined unit.
• Cases requiring correction, with the type and consequence of the error.
• Time waiting for review and time spent performing the review.
• Duplicate or unintended actions, including actions caught before execution.
• Model and tool costs alongside human operating effort.
• Changes made during the period and the cases used to evaluate them.

Compare like with like. An agent handling complicated cases should not be penalized because another handles only clean requests. Break results down by task category and inspect the cases behind a surprising change in the average.

A four-week operating reset for a growing portfolio

Week one: map what is actually running

List every active agent and scheduled job. Identify duplicates, abandoned experiments, shared accounts, and outputs nobody uses. Follow at least one real case through each important workflow.

Record which agents can make external changes. Confirm that the named owners know they are responsible. Pause or narrow orphaned work through your normal change process rather than assuming an old experiment is harmless.

Week two: make exceptions visible

Create a common way to find unresolved work. Require each exception to identify the source case, the failed or missing step, and the next owner. Remove notifications that merely repeat the same unresolved alert without adding information.

Test whether a reviewer can complete the handoff. If the reviewer needs to search five systems just to understand the request, improve the review package before increasing the volume of agent work.

Week three: test changes and recovery

Build a small evaluation set for each important job. Include recent mistakes and representative normal cases. Test updated instructions before releasing them, and keep the previous version available.

Rehearse a shared dependency failure. If an account connection becomes unavailable, can the team identify every affected agent? Can it pause new writes while preserving work that already completed? The exercise often reveals missing ownership more quickly than another dashboard.

Week four: decide what to expand

Review accepted outcomes, management effort, and unresolved risks. Expand an agent that reliably produces useful work within its scope. Redesign or retire an agent that repeatedly moves work into a correction queue.

The goal is not to reach ten agents. It is to create a portfolio the team can operate. Sometimes one shared workflow with clear rules is easier to maintain than several agents whose responsibilities overlap.

Keep knowledge and instructions maintainable

Separate stable operating instructions from changing business information. Prices, service coverage, contact assignments, and policies should have identifiable sources and owners. A copied policy inside several prompts is easy to forget when the original changes.

Record freshness requirements for information that changes frequently. A vendor contact may remain valid for months, while an appointment slot can become stale in minutes. The agent needs the appropriate source for the action it is about to take.

Anthropic's context-engineering discussion treats selecting and maintaining relevant context as an ongoing engineering task. For a portfolio, apply that idea by documenting which sources each agent depends on and which changes should trigger a review.

Also preserve a change history. When performance shifts, the team should be able to see whether the cause coincided with a model change, a new tool, a revised policy, or a different input population.

Applying the playbook with Innflow

Use Innflow's agent and connected-workflow approach to evaluate one real operating job at a time. Begin with the result your team needs and the tools where the authoritative information lives. Confirm available connections and controls in the workspace you intend to use.

For a property team, a useful starting job could be preparing a daily maintenance exception summary. Define the properties included, the records available, and the person who reviews the result. Keep dispatch decisions and external messages within the authority you have explicitly assigned.

Bring the portfolio questions into the setup: who owns this agent, where does its work appear, how does it pause, and how does another person take over? Review deployment-specific access and data requirements with the team using Innflow's governance information.

These are evaluation criteria for your configuration, not a promise that every illustrated control is automatically enabled. Verify the complete path with a small set of cases before trusting it with a larger workload.

Frequently Asked Questions

How many agents should a business run?

Enough to cover distinct useful jobs without creating unnecessary coordination overhead. Start with responsibilities and ownership. Agent count is not a reliable measure of maturity or business value.

Does every agent need daily human review?

Review frequency should reflect the task, consequences, change rate, and observed performance. New or customer-facing workflows usually warrant closer attention. Define a cadence and escalation rules rather than relying on occasional curiosity.

What is the first sign the portfolio is becoming hard to manage?

People cannot quickly say who owns an output, whether an action completed, or which configuration produced it. Growing correction queues and repeated duplicate work are also useful signals.

Should agents manage other agents?

They can help summarize status or prepare review items. Delegation still needs explicit scope, limits, and accountable ownership. A supervisory agent's assessment should not replace evidence of completed actions.

Add the next agent only when its job is clear

AI agents for business automation need an operating model around them. Define ownership, inspect outcomes, maintain context, and make recovery routine. Those habits matter more than a growing list of agent names.

Pick one existing job and make it easier to manage this week. If you are evaluating Innflow, bring that workflow and its acceptance criteria. Build a result your team can trust, then decide whether another agent is the right next step.