Multi-Agent Orchestration and Deployment
Once your first single-skill agent is working reliably, the next stage is putting it to real use: giving it more than one skill, coordinating it with other agents and bots, and deploying it somewhere people (or systems) can actually reach it. This page covers that next stage.
Growing from one skill to several
A single-skill agent is easy to reason about, which is exactly why it's a good starting point. But most real business processes need more than one capability. Say your first agent recommends whether a customer complaint should get a refund, a replacement, or an escalation. A natural second skill might be one that actually drafts the customer-facing response once a decision has been made.
When you add a second skill, the Process Reasoning Engine (PRE) is the thing deciding, case by case, which skill to call and in what order. This is worth testing deliberately: run cases where only one skill should fire, cases where both should fire in sequence, and a few where neither applies. If the PRE picks the wrong skill for a case, the fix is almost always to make each skill's description and prompt more specific about exactly when it should be used, not to add more instructions to the agent as a whole.
Orchestrating multiple agents
Automation Anywhere's approach keeps orchestration inside the PRE itself rather than splitting it into a separate product. That means a single agent can call another agent as if it were just another tool. This is how you build up from one agent that handles a narrow task to a small system of agents that each own a piece of a larger process. For example, a "triage" agent might read an incoming case and hand it off to whichever specialist agent (billing, technical, account changes) is the right fit.
A few practical guidelines when you're coordinating more than one agent:
Keep each agent's responsibility narrow and well-named. A triage agent should triage, not also try to resolve the case itself. The clearer the boundary, the easier it is to test and debug each agent independently.
Decide up front which agent owns the guardrails for a given decision. If two agents could both plausibly approve a refund, make sure only one of them actually has that authority, or you'll end up with inconsistent behavior depending on which path a case happens to take.
Log enough at each handoff that you can reconstruct, after the fact, which agent made which decision and why. This matters as much for debugging as it does for compliance.
Connecting to bots, APIs, and documents
Agents rarely operate in isolation. The PRE can call existing RPA bots, hit APIs directly, and pull information out of documents, all as tools available to a skill. If you already have RPA bots doing the mechanical work in a legacy system, you generally don't need to rebuild that logic. The agent decides what needs to happen, then calls the existing bot to actually do it. This is usually the fastest path to a working agent, since you're reusing automation that's already been tested in production rather than starting from scratch.
Deploying to Control Room
Once an agent is tested and you're ready to make it available beyond your own testing session, it gets deployed and managed through Control Room and Automation Co-Pilot. This is where you'll:
Set who and what is allowed to invoke the agent, whether that's a person through a chat interface, another system through an API call, or a scheduled trigger.
Monitor real runs as they happen, including which skills fired, which guardrails were triggered, and where a human had to step in.
Roll out changes carefully. Treat a prompt or skill change the same way you'd treat a code change: test it against your existing set of sample cases before pushing it to a live agent that people depend on.
What's next
Once an agent is deployed and running real cases, the work shifts from building to operating. That means watching for drift (an agent that performed well at launch but starts making worse calls as real-world cases diverge from your original test set), tightening guardrails as you learn where the agent's judgment falls short, and expanding its skill set only as far as you can still confidently test.