Agentic workflows are processes in which AI agents interpret an objective, use tools and carry out parts of a larger task. The surrounding process defines how work moves between participants, what information they share, and where a person must make a decision.
For a company, this can mean coordinating an investigation across departments, comparing contractor proposals or preparing a change for review. The useful result is a piece of work that another participant can inspect and continue, with its evidence and outstanding questions intact.
This guide explains how to structure that coordination, handle interruptions and use Swarm to keep the work available across people, agents and tools.
How do agentic workflows work?
An agent receives a responsibility, gathers relevant information and decides which permitted actions to take. It may search records, inspect a document, call a tool or ask for clarification. The workflow establishes what happens before and after that activity.
The distinction matters because an agent's freedom to choose its next action does not require every part of the process to be dynamic. A company can require technical review before commercial approval while allowing the reviewing agent to decide which supplied documents need closer inspection.
The LangGraph documentation distinguishes workflows with predetermined paths from agents that choose their own processes and tools. In practice, a system can combine both: a fixed review sequence containing steps performed by agents.
Consider a proposal assessment. The process might require a scope check, a cost comparison and a final human decision. Within the scope check, an agent can follow references, identify exclusions and request missing specifications. Completing that analysis does not authorize it to accept the proposal.
A useful workflow therefore describes two things: how a participant may work and how the organization decides that the work is ready to move forward.
How is this different from automation or a chatbot?
A conventional automation follows specified operations. If an invoice meets a rule, it might be routed to a particular queue. That can be the right approach when the inputs and required behavior are predictable.
An agentic step is useful when the next useful action depends on interpreting the material. Two contractor proposals may describe the same obligation differently. An agent can compare their meaning, inspect the supporting documents and explain an unresolved difference.
A chatbot is an interface through which someone can request that work. The conversation alone does not specify who owns the next step, which decision is authoritative or whether an external action actually completed. Those responsibilities need to exist in the application or operating process.
Our guide to agentic AI explains the agent's action loop. A workflow adds the coordination around it: responsibilities, handoffs, review and recovery.
When does a team need more than one agent?
Start with the smallest arrangement that can produce a useful, reviewable result. One agent with appropriate tools may be sufficient for a bounded investigation. Splitting every small task creates more records to reconcile and more opportunities to lose context.
Microsoft's agent design guidance recommends choosing the lowest complexity that meets the need. Its patterns include sequential work, concurrent contributions and handoffs between responsibilities.
Several participants become useful when there are distinct questions to answer, different access rules or contributions that can be prepared independently. A technical reviewer and a commercial reviewer may need different documents and different acceptance criteria. Their results still need a named owner who can resolve disagreements.
Before adding another agent, ask what responsibility it owns, which information it needs and how its output will be used. If those answers are unclear, dividing the work is likely premature.
Which workflow patterns are useful?
Four arrangements provide a practical starting point. Choose them for the work being done, then make their transitions explicit.
A sequence for dependent work
One result becomes an input to the next step. A team might establish the accepted requirements before comparing proposals against them. The comparison should identify which requirements it used so that a later revision can be checked.
Parallel contributions for independent questions
Several participants examine different aspects of the same brief. Scope, cost and installation planning can be assessed separately when they share the same accepted assumptions. The project owner then reconciles their findings.
Parallel work needs a rule for conflicting conclusions. A merged summary should preserve the disagreement until someone with the right authority resolves it.
Routing for different responsibilities
A request moves to a participant qualified to handle it. A missing technical specification can go to an engineer, while a question about payment terms goes to the commercial owner. Routing should include a fallback when the intended participant is unavailable.
A bounded review cycle
A participant prepares a result, receives specific feedback and revises it. Define what counts as sufficient evidence, how many attempts are permitted and when a person should take over. Repeating the same unsupported conclusion is not progress.
These are process choices. A team can implement them in code, a supported orchestration framework or an explicitly managed sequence of work. Naming a pattern does not establish that a particular product executes it automatically.
What should each step specify?
A step should be understandable to someone who did not watch the preceding conversation. Record enough information to establish the assignment and judge the result:
Objective: the question to answer or the change to prepare.
Inputs: the accepted brief, relevant evidence and applicable revisions.
Responsibility: the person or agent doing the work and the person accepting it.
Permissions: which records may be read and which actions may be taken.
Output: the expected result, including sources and unresolved questions.
Completion criteria: what must be checked before another step relies on it.
Recovery: what to preserve and whom to notify when work cannot continue.
Completion should mean something observable. For a proposal comparison, it could mean that every required item has a cited assessment or is explicitly marked unresolved. A confident recommendation without that evidence has not met the same standard.
Also separate preparing an action from performing it. Permission to draft a clarification email does not establish permission to send it. The person reviewing a recommendation may have no authority to approve a purchase.
Example: comparing contractor proposals for an equipment upgrade
Consider a manufacturer planning to replace a packaging line. Several contractors have supplied proposals with different exclusions, installation plans and assumptions. Engineering, finance and operations need a shared comparison before the project owner can recommend a supplier.
This is an illustrative workflow, not a customer case study or a report of an executed Run. The team supplies the documents and defines its approval process. No automatic access to procurement systems or control of physical equipment is assumed.
Establish one accepted brief
The project owner records the required throughput, acceptable materials, installation window and budget constraints in a Space. The brief identifies its owner and the revision accepted for this assessment.
The team adds the proposals and available supporting records. A contractor's claim about performance remains a claim to assess. The workflow should distinguish a supplied statement from a test result or a requirement accepted by the company.
Assign three bounded assessments
A technical agent compares the proposed equipment with the requirements. It identifies unsupported claims, exclusions and questions for engineering review.
A cost agent compares the supplied commercial figures. It separates equipment, installation and ongoing charges where the proposals provide them. An omitted charge remains unknown; the agent should not invent a price to complete the table.
An installation agent examines the stated sequence, dependencies and expected interruption to production. It identifies what operations must confirm before relying on a schedule.
Each assessment uses the same accepted brief, with access appropriate to its responsibility. A technical agent does not need private negotiation notes merely because they belong to the same project.
Save evidence before reconciling the results
Each agent saves its findings with references to the relevant proposal sections. The result distinguishes confirmed information, assumptions and open questions. The project owner can inspect the evidence behind a recommendation without reconstructing several private conversations.
Suppose one contractor excludes electrical work, while another includes it. The cost assessment records the difference. Engineering then determines whether the excluded work is required. The combined comparison should not treat the headline prices as equivalent before that question is resolved.
Pause when a missing answer changes the decision
The installation assessment finds no contingency for a delayed equipment delivery. The agent records the missing information and prepares a clarification for the project owner. It does not silently assume that the contractor will absorb the delay.
The owner reviews the question and sends it through the company's permitted communication process. When the answer arrives, the team adds it to the evidence and requests the affected assessment again. Other completed work can remain available while this question is unresolved.
Recheck the affected work when requirements change
Suppose operations shortens the installation window. The owner saves the revised requirement and identifies which earlier decision it replaces. The installation assessment needs another review; a proposal that previously met the brief may no longer qualify.
The responsible participant must retrieve the new requirement before updating the result. Saving a revision does not automatically refresh information already held in another agent's session. The workflow needs an explicit recheck or a separately configured mechanism for detecting the change.
Keep selection and execution with their owners
The project owner reviews the assessments, resolves remaining disagreements and records the recommendation. The company's authorized people retain supplier selection, contractual commitments and spending decisions.
The final handoff includes the accepted requirements, the evidence reviewed and any unresolved condition. If the project proceeds, the next team can begin from that record. A later session can identify what was decided without treating every draft suggestion as an instruction.
What happens when a step fails or stalls?
Plan for an interrupted session, an unavailable tool and an incomplete response before the workflow depends on them. The next participant needs to know what finished, what remains uncertain and whether repeating an action could cause harm.
For an analysis step, retain the sources inspected, completed findings and remaining questions. A replacement participant can check that record and continue the assignment. It should verify the applicable brief before accepting an earlier conclusion.
An external write needs more care. A tool timeout can leave the outcome unknown: a message may have been sent even though the caller received no confirmation. Repeating it immediately can create a duplicate.
The AWS Builders' Library explains how idempotent API contracts make retries safer by recognizing repeated requests for the same intended operation. Whether that protection exists depends on the receiving system and the operation being called.
For a company workflow, retain any returned receipt or operation identifier. If the outcome is uncertain, check the destination when permitted or ask an authorized person to reconcile it. Do not turn an unknown result into a fresh request with a new identity and assume that this prevents duplication.
Set limits on retries, waiting time and resource use. When a limit is reached, preserve the partial work and record why it stopped. A blocked assignment should remain visible to its owner, with a clear next action.
Where should human approval sit?
Place human decisions where authority, uncertainty or consequences require them. In the proposal example, people accept the requirements, resolve material gaps and approve contractual commitments. Agents can prepare the evidence for those decisions.
Approval needs a specific object and scope. A reviewer should know which revision, proposed action and affected audience they are accepting. If a material requirement changes afterward, the team needs a rule for whether the earlier approval still applies.
Keep execution approval separate from result review. A person may authorize an assessment to run and later reject its conclusion. An agent can also complete an assessment successfully while recommending that the company take no further action.
These distinctions make autonomy adjustable. A team can permit routine research within a defined scope while reserving external communication, spending or changes to shared systems for authorized people. The permissions of the actual tools must enforce those limits.
How does Swarm support agentic workflows?
Swarm organizes shared work in Spaces. A Space can hold the objective, discussion, evidence, Artifacts, Tasks, Runs and human decisions that authorized participants need as the project continues.
Keep the brief separate from the execution
A Task records work to be done. A Run represents an attempt to execute work through an available, authorized route. Saving a Task, a connection or a schedule does not keep a closed conversation working.
Agent execution requires an active supported client or a configured execution environment. Applicable access rules, execution policies, approval requirements and capacity still matter. A saved schedule is not evidence that a worker is available.
Give the next participant a usable record
Save findings and relevant source references with the result. Keep unresolved questions visible. A succeeding participant can retrieve the permitted records, inspect the evidence and establish which decision applies.
The connected application still chooses what it supplies to its model. Our context engineering guide explains that selection, while the RAG and memory guide covers retrieval and persistent records.
Connect tools without confusing access with authority
Swarm's supported connections let compatible clients work with permitted Space records and operations. MCP describes one way clients discover and call those supported tools. A Space connection does not grant access to an unrelated service, a local codebase or a restricted source.
Swarm also distinguishes approval to execute work from review of its result. An agent cannot provide a required human approval for itself. A successful Run or a saved trace alone is not proof that an external action occurred; retain the relevant evidence.
The public connection guide describes the supported operations and execution requirements. A team's complete workflow may still need application code, explicit coordination or a compatible runtime. A Space provides shared records and operating controls; its existence does not automatically implement every routing rule or recovery policy described here.
How should a team evaluate the workflow?
Test a complete handoff, including the cases that should pause or fail. For the proposal assessment, try an omitted cost, two conflicting revisions, an inaccessible attachment and an interrupted session. An acceptable response should expose the problem and preserve the work needed to resolve it.
Track whether results meet the completion criteria, whether their evidence supports the conclusions and how often people need to correct them. Record time, resource use and repeated work alongside successful outcomes. These are proposed evaluation measures, not measured improvements from Swarm.
Also test the boundary between steps. Can another participant tell which requirement applies? Does a retry create a duplicate external effect? Does a rejected result remain distinguishable from an accepted decision? A workflow that handles the ordinary path but hides these states will be difficult to trust.
Common questions about agentic workflows
Do agentic workflows require several agents?
No. One agent can perform an agentic step within a larger process. Add participants when separate responsibilities, permissions or independent contributions justify the coordination cost.
Can part of the workflow be deterministic?
Yes. A fixed sequence can contain an agent that chooses how to investigate a question. Deterministic checks can validate required fields or route accepted results without asking a model to decide every transition.
Can people participate without blocking every step?
Yes. Define which actions can proceed within existing authority and which need a new decision. A person can review an exception or final recommendation while permitted evidence gathering continues elsewhere.
Does persistent memory make a workflow autonomous?
No. Persistent records support continuity. Work still needs an active execution environment, appropriate permissions and a process for deciding what to do next.
Start with one reviewable handoff
Choose a recurring piece of work with a clear owner and an inspectable result. Define its inputs, permitted actions and completion criteria. Test whether another person or agent can continue from the saved record after an interruption.
In Swarm, begin with a Space for that objective. Add the accepted brief and relevant evidence, connect an authorized client, then complete one bounded assignment. Expand the workflow when that first handoff is reliable enough for the next participant to use.