Quick answerBefore an AI agent is allowed to trigger actions across multiple internal systems from a single conversation, define the maximum blast radius that conversation can reach, require explicit authorization scoping per system rather than one blanket permission, and build a rollback plan for the combination of actions, not just for each system individually. This is a design and approval question for when everything is working correctly, separate from what happens when a tool or system is down.
Not the same question as a system being unavailable
Fallback behavior when tools or APIs are down covers what the agent should do when something it depends on has failed. This is the opposite scenario: every system involved is healthy and reachable, and the question is whether a single conversation should be allowed to touch several of them at once in the first place. A conversation that updates a CRM record, triggers a billing adjustment, and kicks off a fulfillment workflow, all from one customer request, is a fundamentally different risk profile than three separate single-system actions, even if each individual action is well tested on its own.
Why multi-system actions are riskier than the sum of their parts
The risk in orchestrating multiple systems is not that any one action is more dangerous in isolation, it is that combinations create failure modes none of the individual systems' own safeguards were designed to catch. A billing adjustment that is safe on its own and a fulfillment trigger that is safe on its own can interact badly together, for example if the fulfillment system assumes the billing change has already been reconciled when it has not. Each system's individual guardrails have no visibility into what the other system in the same conversation just did.
This is a related but distinct concern from the contractual safeguards needed for agent-to-agent integrations, where the other party is an external agent rather than your own internal systems. The multi-system orchestration case is entirely internal, which makes it easy to underestimate, since there is no external contract forcing you to think through the authorization boundary explicitly.
Scope authorization per system, not per conversation
The most common design mistake is granting an agent a single broad permission level and letting it decide at runtime which systems to touch based on the conversation. Instead, define explicit combinations that are pre-approved as a set, and require anything outside those pre-approved combinations to route to a human before executing, even if each individual action within it would be allowed on its own. This mirrors the discipline used for shadow AI and unauthorized tool governance: the risk is not any single capability, it is capabilities combining in a way nobody explicitly reviewed.
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Plan the rollback for the combination, not just each piece
Before approving a multi-system action set, walk through what reversing it actually looks like if something downstream goes wrong partway through. If a conversation successfully updates one system and fails on the second, you need a defined recovery path for that partial state, not an assumption that each system's own rollback mechanism will somehow compose correctly with the others. Test this rollback path deliberately, the same way you would test a rollback for any production change, rather than discovering it does not work during an actual incident.
Review the pre-approved set on a schedule
Treat the list of pre-approved multi-system combinations as living governance, not a one-time approval. As the agent's capabilities and the underlying systems evolve, combinations that were low-risk when approved can become higher-risk, and new combinations that were never explicitly reviewed can quietly become possible as new tools get added. Revisit the approved list on the same cadence you use for other production risk reviews, and require any new combination to go through the same explicit approval process the original set did.
FAQ
Q: Does every multi-system action need human approval in the moment? No, only combinations outside your pre-approved set. The pre-approval process front-loads the review so that routine, well-understood combinations can execute automatically, while anything novel gets a human check.
Q: How is this different from just giving the agent narrower permissions per system? Narrow per-system permissions help, but they do not address the combination risk. Two individually narrow permissions can still create a risky outcome together that neither one creates alone, which is why the review has to happen at the combination level.
Q: Who should own the approved-combinations list? Whoever owns the agent's overall risk posture, typically in coordination with the owners of each system involved. No single system owner has visibility into every combination the agent might attempt, so this needs a cross-system owner.