Several different things get sold under the same words, and the difference is easiest to see by sending one task through each of them.
Two separate questions decide what you are buying. The first is capability: what can this thing do beyond writing text back to you. The second is responsibility: who keeps it working next month. A tool can be highly capable and still be entirely your problem to run.
The one task
Here is a sample task, written as a hypothetical to make the comparison concrete. It is not a recorded run or a customer result.
A client emails to ask whether a change to their project is in scope, and what it will cost. Answering it properly needs the signed scope, the current project state, the rate card, and someone's judgement about the relationship.
Through workflow automation
If the steps and the decisions can be written as rules, a rules-based workflow can carry a version of this task. It can detect the inbound email, pull the matching project record, check whether the change type appears on the rate card, and draft a templated reply for someone to send. It does what the rules say and stops when an item falls outside them. The existing explainer on workflow automation covers that shape in more detail.
Through a manually prompted chat session
You paste the email in and ask for a draft reply. A chat product connected to tools can go further than text: it can search a document store, call an API, or read a connected inbox if it has been given that access. In this particular pattern you opened the session, you supplied the context the product could not reach, and you decide what happens to the answer. Chat products increasingly ship scheduled tasks and autonomous tool use as well, so read the product's own documentation rather than assuming the manual pattern.
Through an agent
An agent can plan a sequence and use tools to carry it out. OpenAI's agents guide describes agents as able to plan and complete tasks using tools, work with other agents, and maintain context across steps, and it asks you to choose a runtime based on where orchestration runs and who manages the state between tasks. Agent capability comes with a hosting, state and permissions decision attached, and the answer depends on the product: some are vendor-hosted and some leave the runtime to you.
So the agent version of this task could watch the shared inbox, pull the signed scope and the project record, compare them, and prepare a reply with the relevant clause attached. Whether it sends that reply, or stops and waits for your delivery lead, is a boundary someone has to set. It is a configuration rather than a property of agents.
Through a managed worker
The capability can be the same. What changes is who is accountable. An outside provider writes the scope against your real process, connects the systems, runs it, watches it when a connected tool changes its API, and fixes it. Your team still sets policy, grants access and approves the consequential steps. That split should be written down rather than assumed, because managed describes an operating model rather than a technical standard.
Capability and responsibility are separate axes
| Who starts it | What it can reach | Who keeps it running | |
|---|---|---|---|
| Workflow automation | A trigger or a schedule | The systems you connect it to | You, or whoever built it for you |
| Chat session, prompted manually | A person opens it | Whatever tools and documents it has been connected to | The product provider runs the chat service; your team checks how it is used |
| Agent you build or buy | A trigger, a schedule, or a person | The tools and credentials you grant it | Depends on the product: vendor-hosted, self-hosted, or split |
| Managed worker | A trigger, a schedule, or a person | The accounts and permissions you grant | The provider, under a written agreement |
Nothing in the first column settles the last one. Ask for the answer to "who runs it" in writing, naming the party responsible for hosting, state, logging and credential renewal.
Where the work actually goes wrong
Capability is one question. The item that does not fit the rules is a separate one, and it is where the error risk sits.
A good design makes uncertainty visible instead of guessing. When an item is outside what the rules cover, it should wait somewhere a person will see it, with the reason attached. An item that waits can be handled; an automated mistake may only surface when a client points at it.
Three things make that possible. Each action should be logged where you can read it later. Anything that reaches a client or affects an employee should wait for a named person until the system has proven itself on real items. And authority should widen one action type at a time, after it has held.
When plain automation is enough
If the steps and decisions can be written as rules, write them as rules. Test each step against its expected output and check what happens when an input or connected tool changes. You can add an AI step where the workflow needs to interpret varied text. The cost comparison depends on your volumes and tooling. AI agents covers where the agent pattern earns its place.
The useful question is the smallest thing that would carry this work: rules where the decisions are fixed, a model step where the input varies, an agent where the sequence itself has to be worked out, and a managed arrangement when you want someone else responsible for keeping it alive.
Five questions for anyone selling you an agent
- Which exact actions can it take, and in which systems?
- Which of those need approval, and who approves?
- What happens when it is unsure, or when a tool call fails?
- Where is each action logged, and can it be undone?
- Which parts of this would plain automation handle, and why is an agent needed for the rest?
A proposal that answers all five is describing a system you can operate. If the answers are missing, ask for them before you compare prices.
Common questions
Is RPA the same as workflow automation?
Robotic process automation is one form of rules-based automation, often used to interact with software through its screens. Workflow automation also includes connections through APIs. An AI step can help interpret varied text or document layouts, but its output still needs testing. Approval and logging matter in each approach.
Can we start with workflow automation and add AI later?
Yes, and it is often the sensible order. Automate the deterministic path first, so you learn where the exceptions are. The exceptions you collect are the specification for any AI step you add afterwards.
Does this replace staff?
A system can take on agreed responsibilities. Treat a claim that a whole role disappears as something to test against your own workflow, including the cases where a person still needs to decide or act.
Who operates it after launch?
Whoever the agreement names. A vendor-hosted tool may cover hosting while your team maintains its connections and workflow rules. A self-hosted system leaves more of the operation with you. Under a managed arrangement the provider takes on the agreed operating work. Name the responsibilities in the contract.
What happens when it gets something wrong?
The design decides this. Items outside the rules should stop and wait for a person with the reason attached. Log each action where you can read it, keep consequential actions on approval, and check which changes can be reversed. Ask what the failure path looks like before you ask about accuracy.
Can we take it in-house later?
That is a contract question. Ask how code, credentials, data, documentation, hosting and support responsibility are treated on exit, and get the handover terms written into the engagement rather than agreed later.
How do we widen what it is allowed to do?
One action type at a time, after the current boundary has held on real items. Expand the permitted list in writing, keep the log, and keep consequential actions on approval.
Where we sit
Outproduce runs the managed version. One monthly fee, as many workers and roles as the work needs, model usage and infrastructure included, and the building, running, fixing and extending under one agreement. The managed AI employee page sets out what that role covers.
Send us the task you would have used in the example above, with the part that currently stalls, and we will tell you which of these shapes it needs.
Sources
This article describes operating principles and public sources. It is not a client result. Build Records carry the basis for every Outproduce system claim.