- Introduction
- Getting started
- Building with Maestro BPMN
- Understanding Maestro BPMN modeling
- Opening the modeling canvas
- Modeling your process
- Aligning and connecting BPMN elements
- Autopilot for Maestro (Preview)
- Process Repository
- Implementing a simple BPMN process
- Implementing a complex BPMN process
- Debugging
- Simulating
- Evaluations (Preview)
- Common implementation scenarios
- Building with Maestro Case
- Introduction to Maestro Case
- Maestro BPMN vs. Maestro Case: when to use case management
- The Maestro Case lifecycle: from event trigger to app experience
- Build your first case with Maestro Case
- Build a Maestro Case with a coding agent (preview)
- Defining case keys (system vs. external)
- Establishing task I/O and write-back contracts
- Exit rules and early stage termination
- Modeling primary and secondary stages
- Triggering a case from Data Fabric
- Implementing stage-level personas and permissions
- Setting SLAs and automated escalation rules
- Configuring a rework loop (re-entry)
- Configuring and testing the Case Manager Agent (preview)
- Case Manager input and output contract
- Maestro Case component dictionary
- Building with Maestro Flow
- Integrations
- Operating
- Monitoring
- Optimizing
- Reference information
Add the Case Manager Agent to a case plan, choose rules-first or agent-led behavior, configure its model and tools, and test it with evaluations before production.
| Maestro Case | Maestro BPMN | |
|---|---|---|
| Content applies to | ✅ | ❌ |
The Case Manager Agent is in Public Preview.
Overview
The Case Manager Agent is the AI reasoning layer of the Case Manager — the orchestrator that drives a case from creation to closure. Deterministic rules handle the predictable, high-volume paths. The Case Manager Agent handles everything the rules can't: events with no matching rule, ambiguous or unstructured signals, and judgment calls that would otherwise require a human to stop and re-route the case by hand.
This guide covers:
- What the Case Manager Agent does and how it fits alongside rules.
- When to add one — the inbound-event scenarios it is built for.
- Agent behavior selection — the two modes that decide when the agent is invoked.
- Adding the agent to your case plan.
- What is fixed and what you configure — the system prompt and input/output contract are predefined; model, context, memory, tools, and escalation are yours to tune.
- Testing the agent with evaluations before you put it into production.
Audience: Intermediate to Advanced — Automation Developers, Solution Architects, Technical Leads.
What the Case Manager Agent is
Every case runs on a single event stream. Rules and the Case Manager Agent both observe it:
- Rules are deterministic. A rule fires when its WHEN event matches and its IF condition holds, and its ACTION is applied — start a stage, complete a stage, exit a stage, close the case. Rules are predictable, auditable, and cheap. They are the right tool for decisions you can specify in advance.
- The Case Manager Agent reasons. It receives the triggering event, the current case execution state, and the decisions the rules layer already made, and it decides the next orchestration actions — which tasks to start, which to cancel, which stages to enter or complete, and when to escalate.
The agent decides; the engine executes. The Case Manager Agent never mutates the case directly. It returns a set of decisions, and the case engine applies them. This keeps every agent-driven action auditable and reversible, and keeps the agent inside the same guardrails as the rest of the case.
The Case Manager Agent orchestrates the case lifecycle. It is distinct from AI agents that run inside a stage as a task (categorizing data, extracting fields, drafting a response). Stage-level agents do work; the Case Manager Agent decides what work happens next.
When to use the Case Manager Agent
Rules require you to know the decision in advance. Much of what happens to a long-running case does not arrive on a schedule you can pre-wire — it arrives as events during execution that no fixed rule anticipated:
- A claimant uploads a document mid-review — is it the missing proof of loss, or an unrelated receipt? Which task or stage should that trigger?
- A case worker adds a comment or a customer replies to an email — does it change the disposition, reopen a stage, or need nothing at all?
- An inbound connector event (a payment posts, a partner system responds, a Teams message lands) carries a signal that only makes sense in the context of the case so far.
Without an agent, each of these ends with a human stepping into the case to re-route it by hand — reading the document, deciding it means "resume underwriting," and manually moving the case. That is exactly the bottleneck case management is meant to remove.
The Case Manager Agent catches those events and decides the next task or stage itself, reasoning over the full case state instead of a single field. You get the reliability of rules on the paths you can specify, and an agent that plans across events on the paths you can't.
| Signal | Rules alone | With the Case Manager Agent |
|---|---|---|
Event maps cleanly to a condition (Status == "Approved") | Rule fires, action applied | Rule still handles it — the agent is not needed |
| Event arrives that no rule anticipated (an out-of-band document upload, a new comment) | Nothing happens; a human must intervene | Agent reasons over the event and case state, then routes the case |
| Signal is unstructured or ambiguous (free-text note, a document whose meaning depends on context) | Cannot be expressed as a deterministic condition | Agent interprets it and picks the next action |
| Decision needs cross-referencing case history or conflicting signals | One rule can't weigh the whole case | Agent reasons over the full execution state |
This is the reactive-rules vs. proactive-agent distinction: a rule follows a fixed procedure; the Case Manager Agent reasons between events about what to do next to move the case toward its goal.
Agent behavior selection
When you add the agent you choose its behavior — when the Case Manager invokes it relative to the rules layer. This is the single most important decision, because it determines whether the agent is a safety net or the driver.
| Behavior | What happens on each event | Use when |
|---|---|---|
| Agent only invoked when no rules are matched (rules-first, agent as fallback) | Rules evaluate first. If a rule resolves the decision, that action is taken and the agent is never called. The agent runs only for events and decisions that no rule covered. | You have well-modeled deterministic paths and want the agent to catch the gaps and exceptions. Predictable, lower cost, easiest to audit. The recommended default. |
| Agent always runs and decides the next best action (agent-led, pure agentic) | Rules still evaluate and their decisions are passed to the agent as input, but the agent is invoked on every decision point and chooses the next best task or stage — using the rule decisions as guardrails and context. | The case is exception-heavy, hard to fully specify with rules, or you want the agent to own routing end-to-end. Maximum flexibility; the agent drives the case. |
In both modes the deterministic rules layer runs and its decisions are available to the agent — the difference is whether the agent reasons on every event or only on the ones rules left unresolved. Start rules-first and move toward agent-led as you gain confidence in the agent's decisions on your case type.
Add the agent to your case plan
- Open your Case plan in Studio Web and select the Case manager node at the top of the canvas.
- In the properties panel, under Agentify your case plan (Preview), choose Add agent.
- In the Select agent dialog, choose the agent type:
- UiPath Case Agent (Recommended) — UiPath's specialized case agent. It ships with pre-built case tools and is trained to make case orchestration decisions across industries. You can extend it with additional tools, context, and knowledge.
- Custom agent or process — bring your own agent (custom-built or external) as long as it conforms to the Case Manager Agent input/output contract.
- Set Agent behavior — see Agent behavior selection above.
- Select Add.
The agent now appears as a Case Manager Agent tab on the Case manager node. From there, open the agent's Definition to configure it and run evaluations.
What is fixed and what you configure
The Case Manager Agent is a governed, pre-built agent, not a blank canvas. The parts that define how it orchestrates a case are locked so that every case behaves consistently and safely; the parts that tune quality, cost, and reach are yours.
Predefined and locked
| Element | Why it's fixed |
|---|---|
| System prompt | Defines the agent's role, the decisions it may emit, and the invariants it must respect (for example: decide, never mutate the case directly; emit a matching stagesEntered entry for any stage it activates). This is what makes the agent a valid case orchestrator. It is shown read-only. |
| Input/output schema (I/O contract) | The exact case state the agent receives and the decision object it must return. The case engine relies on this contract to apply the agent's decisions. See Input/output contract. |
Configurable
| Element | What you control |
|---|---|
| Model | Which LLM powers the agent, plus model settings — temperature, max tokens per response, and max iterations. Choose a tenant model or bring a custom model via your own connection. |
| Behavior | Rules-first or agent-led (see above). |
| Context | Additional knowledge, policies, and reference data the agent reasons over — SOPs, eligibility criteria, playbooks. |
| Memory | What the agent retains across activations within a case, so decisions build on earlier ones rather than treating each event in isolation. |
| Tools | Additional tools beyond the pre-built case tools — for example, a lookup connector or a notification action. |
| Escalation paths | The conditions under which the agent hands off to a human instead of deciding autonomously (low confidence, conflicting policies, missing data) and who it escalates to. |
The flexibility is deliberately at the edges — model, context, memory, tools, and escalation — while the orchestration contract stays fixed. You shape how well and how far the agent reasons; you do not rewrite what a case orchestrator is allowed to do.
Input/output contract
The Case Manager Agent conforms to a fixed contract — the "specification" the Case Manager and any custom agent must honor.
The UiPath Case Agent uses the same contract as any other Case Manager task. For the exact input (caseCurrentExecutionState, caseRulesDecisions) and output (caseManagerDecisions, with tasksToRun, tasksToCancel, stagesEntered, stagesExited, stagesCompleted, and caseResolution) shape, see Case Manager input and output contract.
Pre-built case tools
The UiPath Case Agent ships with a Case Management Control tool group so it can read the live case without custom wiring:
| Tool | Purpose |
|---|---|
InstancesGetExecutionState | Get the latest CaseCurrentExecutionState (state portion) for the instance. |
InstancesGetCaseJson | Get the case plan JSON for the instance. |
GetCasePlanOverview | Get a case plan overview for the instance. |
GetCaseRules | Get the deterministic rules defined for the instance. |
CaseAppVariablesGet | Get global variables and element inputs, outputs, and input definitions. |
Add your own tools alongside these when the agent needs to reach beyond the case (a system-of-record lookup, a notification connector, and so on).
Configure the agent
Open the Case Manager Agent → Definition and set:
- Harness — Standard (default) or Advanced (Preview).
- Model — pick the LLM. Model choice is where you trade off reasoning quality, latency, and cost. Some models may require a confirmation step.
- Model settings — Temperature (precise ↔ creative), Max tokens per response, and Max iterations.
- Context, Memory, Tools, and Escalations — attach the knowledge, memory, additional tools, and escalation paths described above.
The system prompt and user prompt / I/O schema are shown read-only — review them to understand exactly what the agent sees and returns, but they are not editable.
Test the agent before production
Because the Case Manager Agent is a UiPath agent, it comes with the full power of UiPath's agent builder — including evaluations. Test the agent against representative cases before you deploy it, the same way you would test any other agent.
| Capability | Use it to |
|---|---|
| Evaluation Sets | Define input cases (case state + event) with the expected orchestration decisions. Run the agent across the set to measure how often it decides correctly. |
| Evaluators | Score each run — exact-match on decisions, or custom/LLM-based evaluators that judge whether the chosen action was acceptable. |
| Evaluations / Score | Track the agent's score across runs as you tune the model, context, and behavior, so you can prove it before it touches live cases. |
| Execution Trail & History | Inspect a single run step by step — what the agent read, which tools it called, and why it decided as it did. |
Iterate on model, context, memory, and behavior against your evaluation sets until the score meets your bar, then deploy the case plan. Evaluate before you agentify a production case — a routing agent that is wrong is worse than a rule that is missing.
Related resources
- Introduction to Maestro Case — where the Case Manager and its agent fit in the overall model.
- Maestro Case component dictionary — reference entry for the Case Manager and the rules layer.
- The Maestro Case lifecycle — how events flow through a case from trigger to app.
- Setting SLAs and automated escalation rules — the escalation constructs the agent can hand off to.
- Case Manager input and output contract — the exact input and output shape the agent must use.
- Overview
- What the Case Manager Agent is
- When to use the Case Manager Agent
- Agent behavior selection
- Add the agent to your case plan
- What is fixed and what you configure
- Predefined and locked
- Configurable
- Input/output contract
- Pre-built case tools
- Configure the agent
- Test the agent before production
- Related resources