"Agent" has become one of those words that gets stretched to cover almost anything with a text box and an API key attached. A chatbot with a system prompt gets called an agent. So does a script that calls a language model in a loop. The label is doing so much work that it has mostly stopped meaning anything specific, which is a problem the moment you need to decide what to actually build.

The distinction that matters in practice is not how conversational the tool feels. It is whether the system lives inside a workflow, with state, permissions, and consequences, or whether it lives inside a conversation, waiting for the next message. Those are different pieces of software, and moving from one to the other changes what you need to build, test, and own.

What a chatbot is actually doing

A chatbot, however well-tuned, is fundamentally reactive. It receives a message, holds the conversation in context, and produces a response. Even when it calls a tool or looks something up, the loop still starts and ends with a human typing something into a box. The chatbot has no independent reason to act. It waits.

This is not a limitation to be embarrassed about. For a huge range of use cases, that reactive pattern is exactly right. Customer support, internal documentation search, first-draft writing help: these are all things a person wants to ask about, on their own schedule, in their own words. Wrapping that in more autonomy would not make it better. It would just make it less predictable.

What changes when the agent moves into a workflow

A workflow embedded agent does not wait for someone to open a chat window. It sits inside a process that already exists, whether that is order fulfilment, invoice approval, or a customer onboarding sequence, and it acts when the process reaches a point that calls for a decision or an action. The trigger is an event in a system, not a message from a person.

Three things change once you make that move, and each one carries real engineering weight.

State, permissions, and error handling are not implementation details on a workflow-embedded agent. They are most of the project.

The first is state. A chatbot's memory is usually scoped to a conversation. A workflow-embedded agent has to track where a specific case sits inside a multi-step process, often across hours or days, and often across systems that were never designed to talk to each other. That state has to survive restarts, retries, and partial failures, which means it needs somewhere durable to live, not just a context window.

The second is permissions. A chatbot answering questions needs read access and not much else. An agent that can move a shipment, adjust a price, or send an invoice needs write access to production systems, which means every action it can take has to be scoped, logged, and reversible in the same way you would scope, log, and reverse a human employee's access. This is where a lot of agent projects quietly stall, because the model was never the hard part. The access control was.

The third is error handling. When a chatbot gets something wrong, the person reading the response usually notices and asks a follow-up. When a workflow-embedded agent gets something wrong, there may be no one watching that step at all. The failure needs to be caught by the system itself: a validation check, a fallback path, a human-in-the-loop trigger for anything above a defined risk threshold. Silent failure in a background process is a different category of problem to a slightly unhelpful chat reply.

The practical stakes for a technical leader

None of this is an argument against building agents. It is an argument for being precise about what you are actually asking for, because the two designs come with different costs and different failure modes.

A chatbot is comparatively cheap to ship and easy to roll back. If it says something unhelpful, the cost is a bad interaction. A workflow-embedded agent is more expensive to build properly, because the durability, permissioning, and error handling described above are not optional extras. They are the majority of the engineering effort. The model call itself is often the smallest part of the system.

This has a direct effect on how a project should be scoped. If a team asks for "an agent" and what they actually need is a well-designed chatbot with good retrieval, building the workflow-embedded version wastes time on infrastructure the use case never required. Equally, if the actual goal is to remove a person from a multi-step operational process, a chatbot bolted onto the front end will not do it, no matter how good the model behind it is. The conversation interface was never the constraint.

The other stake is ownership. A chatbot's output belongs, in practice, to whoever reads it and decides whether to act on it. A workflow-embedded agent's output is the action itself. That shifts the review point earlier, into the design of the permissions and guardrails, because by the time the agent has acted, review is no longer possible in the same way. Teams that treat this as a deployment detail, rather than a design decision made up front, tend to find out the difference the hard way.

In short

The useful question is not whether something counts as an agent. It is where the system's trigger comes from and what it is allowed to touch once it acts. A chatbot answers what it is asked. A workflow-embedded agent acts inside a process, with state to track, permissions to manage, and failures that need to be caught without a person there to notice them. Knowing which one you are actually building, before you start, is what determines whether the project succeeds on schedule or discovers the real requirements halfway through.

If you are weighing up whether a use case needs a conversational assistant or a properly embedded agent, we are happy to talk it through. Contact us to explore what fits your workflow.