Cloudflare Agents vs Workflows is a useful comparison when an interactive assistant starts doing work that outlives the conversation. The agent may need to explain progress, while a background process needs to survive interruption and wait for approval. Those are related responsibilities with different lifecycles.
Use Agents for an interactive identity that receives events and communicates with users. Use Workflows for durable sequences of background steps, including waits and retries, where that execution model fits. Combine them when the conversation and the long-running task need to progress independently, and keep external business effects explicitly reconcilable.
Imagine an employee requesting a supplier assessment. The assistant asks for missing information and shows status. The assessment gathers records, prepares a report and waits for a colleague’s decision. Closing the browser should not lose the task, and reconnecting should not start the assessment again.
This article uses that hypothetical design to explain the boundary. It does not assume every assistant requires both products or that durable execution makes every external operation safe to repeat.
Cloudflare Agents vs Workflows: compare lifecycles
Cloudflare’s Agents and Workflows documentation describes complementary roles: Agents support ongoing interaction and identity, while Workflows support durable background execution. Choose based on those roles before choosing a starter template.
For the supplier assessment, the conversation has an employee-facing lifecycle. The task has a business lifecycle. The employee may disconnect, another authorized colleague may review the result, and the assessment may continue waiting after the original chat ends.
| Requirement | Agent responsibility | Workflow responsibility |
|---|---|---|
| Ask the employee a clarification | Present the question and receive the response | Wait for required task input where appropriate |
| Show progress | Present the current task state | Record progress through defined steps |
| Survive a closed browser | Reconnect the authorized user to their task | Continue or wait under the execution contract |
| Handle approval | Show the exact proposal and caller context | Apply the approved transition under task rules |
| Explain failure | Give the user a useful next step | Retain the failed stage and recovery evidence |
The table describes a proposed division of labour. It is not a claim that adopting the SDK automatically supplies the application’s permission model or business-state ledger.
Start with a task record, not a chat transcript
Give the assessment a stable task reference. Store its owner, source revisions, requested outcome and current state in a form that does not depend on rereading the conversation. The transcript can explain intent, but it should not be the only record of accepted work.
The user interface should distinguish a request being discussed from a task being accepted. If the employee clicks submit and the response is lost, reconnecting must reveal whether the task exists. Asking the model to infer this from the last chat message is unreliable.
Define states meaningful to the process owner: awaiting input, gathering evidence, ready for review, approved, rejected and failed, for example. Include who can move between them and what evidence is required.
The task reference should survive changes to the conversational interface. A later email or dashboard can present the same accepted assessment without becoming a second source of authority over what the task is doing.
Keep durable steps small enough to explain
The Workflows overview describes durable multi-step execution. Use that capability around steps whose inputs, outputs and recovery behaviour are clear. A single giant step that gathers sources, generates text and changes several systems is difficult to inspect when something fails.
For the assessment, separate obtaining source records from generating a report and from applying an approved business decision. Record which source revisions supported the report. A retry after a source change should follow an explicit policy rather than quietly producing a different assessment.
Do not confuse a persisted step result with proof of an external side effect. A destination may accept a request just before the calling process loses the response. The application needs an operation reference or another reconciliation method to establish what happened.
A step boundary is useful when it makes the next action obvious. If an operator cannot tell whether to retry, refresh evidence or contact a reviewer, the boundary is probably missing some business context.
Make approval a versioned business event
Approval should refer to the exact assessment version and proposed consequence. If the source records or report change after the reviewer opens the page, require the application to resolve that mismatch before proceeding.
Authenticate the reviewer and check their task permissions when the event arrives. A URL that identifies an assessment is not sufficient authority to approve it. Do not let a tool result or generated sentence substitute for a colleague’s approval.
| Approval condition | Expected response |
|---|---|
| Current report and authorized reviewer | Accept the permitted transition |
| Report replaced after the page opened | Request review of the current version |
| Duplicate approval event | Return the established result without another effect |
| Reviewer no longer authorized | Refuse the transition |
| Assessment already rejected or cancelled | Follow the documented terminal-state policy |
Treat cancellation similarly. Stopping future steps does not necessarily undo a request already accepted by an external system. Show the user which work stopped and which outcomes still need reconciliation.
Reconnect from authoritative state
When the employee returns, load the task state under their current permissions. Show the latest recorded stage and observation time. A conversational summary may help, but it should not overwrite the task record with a guessed status.
Keep progress notifications separate from the authoritative state. A missed notification should not mean a missed task transition. Conversely, receiving a notification should not authorize the recipient to inspect the underlying supplier records.
Test reconnecting during a wait, after a failure and after another colleague acts. Include stale browser tabs that try to submit an old decision. These are normal operating conditions for business processes that cross shifts or teams.
For broader outcome testing, our agent evaluation guide explains why successful tool calls alone are insufficient. Here the key question is whether the right task continued and the user sees its real state.
Choose the smallest architecture that meets the need
An assistant that performs a short lookup may not need a separate background workflow. A scheduled data transformation may not need a conversational agent. Adding both creates more configuration, state relationships and incident paths to maintain.
| Workload | Sensible starting point | Reason to add another layer |
|---|---|---|
| Interactive lookup | An authenticated application or agent | Work must continue beyond the interaction |
| Scheduled processing | A background workflow | Users need live task interaction |
| Approval-heavy assessment | Separate task state and durable processing | Agent can improve clarification and status presentation |
| Open-ended conversation | Agent with bounded tools | A specific accepted task needs independent execution |
The architecture should make ownership clearer. If nobody can explain whether the agent or workflow owns the task’s current state, write that contract before adding more tool calls.
Budget for coordination and failure testing
Implementation cost grows with the number of systems, task transitions, approval roles and uncertain external outcomes. The amount of chat text is a poor proxy for that work.
Ask for a GBP estimate that separates task design, agent interaction, workflow execution, destination integration and acceptance. Include maintenance of dependency versions and the procedure for handling tasks already in flight during a deployment.
Current usage charges must be verified for the selected services and workload. Estimate waits, repeated attempts, inference, storage and observation work separately. A background task that rarely runs can still need careful operational support because its business consequences matter.
A useful pilot should demonstrate browser closure, a process interruption, a duplicate approval and a destination timeout. It should leave an operator able to find the assessment and establish the next safe action without reconstructing the chat.
We can define that contract in a scoped AI integration pilot . Request an agent workflow proposal with the task stages, connected systems and approval roles. That makes the choice of runtime follow the work your team actually needs to complete.
Frequently Asked Questions
Are Agents and Workflows competing products? They have different strengths and can work together. Agents suit ongoing interaction and identity; Workflows suit durable sequences of background steps. Choose the combination from the application’s lifecycle rather than assuming every task needs both.
Does every AI assistant need a Workflow? No. A short interactive task may be adequately handled without one. Consider durable background processing when accepted work must continue independently, wait for events or recover through defined stages.
Does durable execution prevent duplicate business actions? It does not remove the need to reason about external systems. A destination can complete a request even if its response is lost. Use stable operation references and a documented reconciliation policy for consequential effects.
Where should approval state live? Keep it in an authoritative task record associated with the exact proposal version and reviewer. The conversation can present and explain the decision, but it should not be the only record of approval.
What happens when a user closes the browser? The application should preserve accepted work independently of the connection. On return, authenticate the user and load the current task state rather than starting the job again or asking the model to infer progress.
What should a pilot test? Test the ordinary journey plus disconnection, interrupted processing, stale approvals, duplicate events and uncertain destination outcomes. The report should show which component owns each state and how an operator recovers.
How much does the combined implementation cost? Cost depends on task transitions, system integrations, permission roles and recovery requirements. Request a scoped GBP estimate with separate interaction, processing, acceptance and support work rather than a price based on chat features alone.