A second AI agent can be harder to scope when it depends on decisions made during the first build. Excluded edge cases, partial connections, and manually handled exceptions become dependencies. Document those boundaries before assuming the existing setup can support another workflow.
A narrow first AI agent can work well while leaving decisions outside its scope. When a founder identifies the next workflow, existing tools and connections may help. They may also carry undocumented restrictions. The second build should check those restrictions before treating the first setup as reusable.
Why is the first agent easy?
A first workflow can benefit from a deliberately narrow scope. Log the excluded cases, agreed manual handling, and permission limits as part of the build. A working core workflow does not mean those exclusions disappear for the next project.
Narrow scope is useful when the retained cases work reliably and exceptions have an owner. It becomes a problem when the choices are not documented: ignored inputs, partial connections, and accepted output limits can affect later work.
Keeping the first workflow boring and narrow is sound implementation practice. But the decisions that made it narrow must be documented for the work that follows.
What does the second agent inherit from the first?
The second workflow a business automates is usually adjacent to the first — same toolset, same team, faster to build because the infrastructure is already in place. That logic is sound. The assumption behind it often is not.
The second agent may reuse some code or connections. It also relies on decisions made during the first build. A CRM connection may be read-only, while the new workflow needs to write. Rush orders may have remained a manual exception, while the new workflow needs a reliable rush-order field. Those dependencies need review before reuse.
Reusing a connection also carries its boundaries: excluded cases, partial permissions, and manual exception paths. Document those before another workflow depends on them.
These are dependencies that documentation can reveal. Some need a business rule; others need a permission review or additional connection work. Identifying them early helps keep the new scope realistic.
Where do second builds typically break?
Three useful failure patterns to check are scope creep, connection conflicts, and inherited assumptions. They are planning risks, not a measured ranking of why second agents fail. McKinsey’s May 2024 survey reported that half of respondents said their organizations used AI in two or more business functions.[1] That finding describes adoption breadth; it does not establish the primary barrier to a second agent build.
Scope creep through adjacency. Because the second workflow is adjacent to the first, teams try to extend the first agent or combine both workflows into one. The scoping discipline that made agent one succeed gets abandoned on the grounds that the second workflow is basically the same thing. That is where the complexity enters.
Integration collision. The first agent connected to a shared tool in a way that worked for its specific job. The second agent needs the same tool for a different job — different permissions, different field mappings, different trigger logic. If nobody documented how the first connection was built and why, the second build starts by reverse-engineering decisions made months ago by someone who may no longer be involved.
Assumption inheritance. Both agents share an assumption that was reasonable when the first was built but is no longer accurate — a deal stage naming convention, a product taxonomy, a client categorization. Neither agent is individually wrong. Both agents produce incorrect outputs together, in ways that compound.
| Failure pattern | How it appears | Prevention |
|---|---|---|
| Scope creep through adjacency | The second build is framed as an extension of the first; edge cases from both enter the scope | Treat the second build as a separate scoping exercise regardless of workflow similarity |
| Integration collision | The second agent needs a tool connection built differently from the first | Document the first agent's connection method and permissions before writing the second scope |
| Assumption inheritance | Both agents produce incorrect outputs together without either being individually wrong | Audit shared data structures and naming conventions before the second brief is written |
The first agent worked because someone forced the scope. The second reveals everything that was forced out.
What should you audit before scoping build two?
The second build is when implementation debt becomes visible. Preventing it requires an explicit audit of the first agent before the second scope is written.
Four items make up the audit. First: document every edge case that was explicitly excluded from the first build and why. Second: review the integration layer — every connected tool, what permissions were used, which fields were mapped, and what was left unmapped. Third: check the exception paths — the inputs the first agent flags as unhandled and the manual process that currently covers them. Fourth: review the outputs — not whether the agent runs, but whether those outputs still match how the business currently defines success for that workflow.
This review can expose assumptions before they become dependencies of the second build. It cannot guarantee a launch date or prevent every later issue; continue checking the shared rules as both workflows change. See why projects can stall after launch.
Document excluded edge cases
Pull the first agent's exception log. List every input type that was excluded from scope or flagged for manual handling. For each: was the exclusion intentional and does it still apply? Is the second workflow dependent on any of these edge cases being handled?
Review the integration layer
For every tool connected to the first agent: what permissions were used, which fields are mapped, which fields are left empty, and what changed in those tools since the first agent was built? The second agent that needs write access to a tool the first only reads from requires a permission change that should be identified in scoping, not discovered in the build.
Check the exception paths
Review every exception the first agent flags — what happens to it after the flag? Is there a manual process that has been covering it since launch? Is that process documented anywhere? If the second workflow requires that exception to be handled automatically, the solution needs to be in the second brief before build starts.
Review whether current outputs still match business standards
Pull the last 30 outputs from the first agent and evaluate them against the business's current definition of correct. If the first agent has drifted — outputs that were acceptable six months ago are no longer accurate — that drift should be corrected before the second agent inherits any of the same logic.
The audit effort depends on the first workflow, the available documentation, and who can explain the exceptions. Review the needed access and evidence before estimating it. A fixed two-to-four-hour promise can conceal missing records or a permission review.
How do you prevent two agents from changing the same record?
Assign responsibility for each shared field before the second agent receives write access. If one agent changes a deal stage while the other prepares a follow-up, define which state wins, when the second must recheck it, and who resolves a conflict. Test both acting on the same example record before allowing live changes.
Keep each agent’s permissions limited to its own work. A connection reused from the first build should not silently grant the second broader access. Log which workflow made each change, hold ambiguous updates for review, and test the first workflow again after changing shared fields or permissions.
Download the second AI agent checklist (PDF)
Frequently asked questions
Why can the second AI agent be harder to build than the first?
It can depend on excluded edge cases, partial connections, or manually handled exceptions from the first build. Existing infrastructure helps only when its boundaries are understood. This is a planning risk, not a claim that every second agent is harder.
What is assumption inheritance in AI agent implementations?
It occurs when another workflow relies on an undocumented data structure, naming convention, or process rule from the first build. If that shared rule becomes outdated, both workflows can produce incorrect outputs. Assign ownership and test the shared rules.
What should you audit before building a second AI agent?
Review excluded cases, connections and permissions, manual exception handling, and whether current outputs still match business requirements. Also identify shared fields and who may change them.
What failure patterns should you check in a second agent build?
Check scope creep through adjacent tasks, conflicting connection requirements, and inherited assumptions. Keep a separate scope for the new workflow and test the first one again when shared fields or permissions change.
How long does the audit of the first agent take?
The time depends on workflow breadth, documentation, exception history, and access reviews. Agree the evidence needed before estimating the effort. A universal two-to-four-hour audit or guaranteed prevention of later stalls is not supported.
Why can scope creep occur on the second agent build?
A related workflow can look like a small extension, leading the team to combine jobs and exceptions that need different rules. Define the second workflow’s trigger, output, permissions, and escalation independently before deciding what can be shared.
Notes
- McKinsey & Company, "The state of AI in early 2024: Gen AI adoption spikes and starts to generate value," May 30, 2024. Historical survey evidence on adoption across business functions, not a finding about second-agent failure causes.
