Human, Bot and AI Agent Workflow Design Depends on Transferable State

Introduction

At 14:06, an RPA job marks a parts check as successful. At 14:07, the maintenance planner opens the next task and has to repeat the lookup.

The robot found the asset record and confirmed that a replacement part exists. What did not arrive with the task was the candidate part number, the source record, the warranty condition the robot encountered or the fact that two compatible substitutes were available.

The automated step completed, but too little of its useful state reached the person expected to continue the work.

That gap becomes more consequential once a process moves among people, bots and AI agents. Each participant can perform its own task correctly while leaving the next participant with too little context to continue, too much unstructured history to interpret, or an output whose meaning changes depending on who receives it.

For human, bot and AI agent workflow design, the transfer therefore has to preserve more than completion status. The process needs an explicit record of what is currently known, what changed during the previous step, which result was produced and which unresolved conditions still affect what can happen next.

Current orchestration platforms expose much of the machinery needed to do this. In Camunda 8.9, a user task stops the process instance until the task is completed, with input and output mappings available to control the data entering and leaving the task. UiPath Maestro’s variable model similarly passes values among automations, agents, app tasks and human work.

The harder design problem sits between those participants: whether a different kind of worker can resume the case without reconstructing it from logs, chat history or system screens.

At a glance

• A technically successful task can still create an operational failure when its useful state does not reach the next participant.
• Mixed workflows benefit from explicit inputs and outputs at each transfer instead of relying on a shared narrative history.
• Human work introduces elapsed time, edits and partial decisions that can make assignment-time data stale before automation resumes.
• AI agents can resume more reliably from current process facts and structured results than from a replay of every earlier interaction.
• End-to-end testing has to examine the seams between worker types, not only whether each participant succeeds independently.

A successful task can still leave the next worker stranded

Consider a maintenance process in which an agent reads a technician’s free-text note and identifies the likely equipment family. A robot retrieves the asset, service history and approved parts from a legacy maintenance system. A planner then decides whether a substitute part is acceptable for a safety-sensitive repair. Once that decision is recorded, automation creates the work order and reserves inventory.

The process can break even when each participant behaves as designed. A robot returning `success=true` may confirm that an execution ended without carrying the information a planner needs. A human note saying “use alternate B” may be obvious to another planner but unusable by the automation that has to reserve the part. An agent can provide a detailed explanation while omitting the asset identifier, evidence reference or unresolved condition needed downstream.

UiPath Maestro’s current task model makes the range of participants explicit: a process can include unattended RPA, UiPath or external agents, API workflows and human tasks, with defined inputs and outputs around those activities.

The orchestration layer can therefore move work from one participant to another. The process design still determines whether what arrives is usable.

What has to cross the boundary

The next participant rarely needs everything the previous participant saw. It needs a deliberate representation of the case.

That representation will often include an identifier tied to the system of record, the established facts required for the next action, references to material evidence, a record of what changed during the previous step and any unresolved condition that affects what can happen next. Those elements can coexist with explanatory text without forcing the next worker to rediscover the authoritative state inside a transcript or execution log.

Camunda’s variable and mapping model illustrates the architectural principle. Input mappings can reshape process data for a local task, while output mappings control which results return to the wider process instance.

A maintenance planner does not need a robot’s UI selectors or retry history. The automation creating the final work order does not need the planner’s complete interface session. If an agent resumes after the planner’s decision, it needs the current case facts and recorded outcome rather than a reconstruction of every intermediate thought.

Keeping the shared process record focused on business-relevant state also reduces coupling. A robot can later be replaced with an API, the human task interface can change, or an agent implementation can be updated without requiring every downstream participant to understand the internal workings of the component it replaced.

“Completed” does not mean the same thing to every worker

A completion event can carry very different business meaning depending on the participant that produced it.

A robot may finish because a prescribed system action succeeded. A person may finish because a judgment was made. An AI agent may stop because its reasoning loop has reached what it considers a satisfactory result. Treating all three as the same generic lifecycle state leaves downstream work to infer what actually happened.

Camunda’s current guidance for AI-agent tools provides a useful technical example. Agent tools return their result through `toolCallResult`, and the platform’s modeling guidance for agent-tool output warns when a tool produces no result or writes it to the wrong variable. Structured output can carry several fields back to the agent instead of reducing execution to a generic success indication.

Human work benefits from the same precision.

After a maintenance planner reviews a substitute part, the downstream process may require the selected part identifier, whether the original proposal was rejected or amended, the current maintenance priority and a reference to the review record. Free text can remain available where explanation matters, but automation should not have to infer fields that determine the next system action.

A task is most useful to the rest of the process when its result describes the business outcome, not merely the fact that the task ended.

Human work can make assignment-time state stale

Human participation introduces elapsed time into a process.

Camunda’s user-task lifecycle guidance accommodates interrupted work and advises applications that support pauses or returns to persist draft or intermediate data before the user leaves. AWS Step Functions uses a different mechanism but exposes the same durable-wait requirement: callback tasks with task tokens can pause an execution until an external process or human response returns success or failure.

Those mechanisms preserve the workflow while it waits. They do not freeze the business around it.

A maintenance planner may open a task on Monday afternoon and finish it on Tuesday morning. During that interval, stock can be reserved by another job, the asset can enter a different maintenance state, a technician can upload new inspection evidence or the approved maintenance window can close.

Resuming from Monday’s snapshot can therefore produce a perfectly executed Tuesday action against stale premises.

Where those changes affect the next action, the return from human work can include a refresh of the relevant source state before automated execution continues. The planner’s decision remains part of the case, but the process no longer assumes that every fact present at assignment time still describes the operating situation.

This is different from the durable-state question covered elsewhere in the automation architecture. The issue here is what happens to business facts while responsibility temporarily sits with a person.

Agent re-entry should start from current case facts

AI agents make it tempting to treat conversation history as the handoff mechanism.

During a prototype, sending the entire history back to the model can appear sufficient. In a long-running business process, that history may contain superseded facts, exploratory suggestions, rejected alternatives and information that mattered earlier but no longer represents the case.

The agent then has to infer authoritative state from material that was never designed to serve as a system of record.

Camunda’s current AI-agent model maintains conversational context for iterative agent work while the workflow engine separately stores process variables and executes the surrounding BPMN process. That separation allows the agent’s conversational continuity and the process’s current business state to serve different purposes.

Suppose the agent recommends one replacement part and the maintenance planner selects another. When the agent later resumes, the approved selection can be supplied as current process data. The model does not have to derive from an earlier dialogue that its original recommendation has been superseded.

Conversational context may still be useful for reasoning continuity, but the state required by other workers should remain explicit enough that the process does not depend on one model’s ability to reinterpret its own history.

Component tests can pass while the seam still fails

A robot can pass its test suite. The agent can perform well against its evaluation set. The human task can accept and validate its expected inputs. The combined process can still fail between those tests.

UiPath’s current Maestro testing guidance explicitly separates component testing from end-to-end process testing, including whether steps connect properly, data moves as expected and the final business outcome is correct.

That distinction changes what a useful test case looks like.

The robot can execute successfully while omitting a field the planner requires. The planner can amend a proposed value instead of simply approving it. The agent can return a valid response that lacks an identifier required by the next automated task. A human task can stay open long enough for important source data to change before it is completed.

None of those conditions necessarily indicates a defective component. They expose whether the interface between participants can absorb ordinary variation in the way work is completed.

If every participant passes independently while the process still requires a person to inspect logs or repeat a lookup, the missing test sits at the handoff.

FAQs: human, bot and AI agent workflow design

What is human, bot and AI agent workflow design?

It is the design of an end-to-end business process in which human work, robotic automation and AI-agent activity participate in the same workflow.

The design problem includes task assignment, but also the state, result and unresolved conditions that have to survive when responsibility passes from one participant to another.

What information should pass from an AI agent to a human worker?

The human should receive the information required for the next decision: relevant case facts, evidence or source references, the proposed outcome where appropriate, and unresolved conditions that require human judgment.

A full interaction transcript may be retained where there is a valid reason, but it is usually a poor substitute for structured task context.

What should a human return to an automated workflow?

Where downstream automation depends on the decision, the human result should be machine-readable.

That can include the selected outcome, amended values, relevant identifiers, comments that need to be preserved and a completion result that the workflow can route without interpreting free text.

How should a workflow handle a long-running human task?

The workflow should persist the task and relevant intermediate state while it waits.

When the person completes the work, facts that can change over time may need to be refreshed before automated execution resumes. Inventory, eligibility, account status, price, capacity and policy data are common examples.

Should an AI agent receive the entire prior conversation when it resumes?

Not by default.

Selected conversational context can remain useful, but current process facts should be explicit enough that the agent does not have to reconstruct authoritative state from a long history containing obsolete or exploratory information.

The process record has to survive the worker

Mixed automation becomes fragile when every participant is locally capable but the transfer between them still depends on reconstruction.

A durable design gives each participant enough context to act and requires it to leave behind a result that another kind of worker can interpret. Human delays are reflected in the process rather than hidden inside an open task. Agent re-entry starts from current case facts. Automated steps return business-relevant results rather than generic success signals.

That separation also gives the process room to evolve. A robot can give way to an API, a human interface can move to another task application, or an agent implementation can change without forcing downstream work to learn the internal history of the component that came before it.

The useful test is straightforward: another participant should be able to continue from the process record itself. If resuming the work still requires reading the previous worker’s logs, replaying its conversation or repeating its lookup, too much of the process remains trapped inside the worker.