AI agent, copilot, chatbot, workflow and RPA: the differences

The label reveals little about the actual architecture

One vendor calls a product an “agent” even though it answers a question and waits for the next click. Another sells a “copilot” that changes records on its own. There are LLM workflows, RPA robots with chat interfaces and chatbots that call internal APIs. The names sound like distinct product categories, but they are not reliable technical specifications.

Six questions are more useful for architecture: Who starts the work? Who selects the next step? Which data may the system read? Which tools can it choose? Which actions may it execute? Who handles the consequences when a decision is wrong?

The AI automation pillar guide explains how bounded AI steps fit controlled business processes. The AI automation in e-commerce guide maps suitable commerce processes. This page deals with the architecture terms that are routinely mixed during product selection.

The comparison at a glance

This is an architecture comparison, not a legal classification. European Commission guidance on the AI-system definition says assessment depends on the concrete characteristics of a system. A label such as “copilot” or “agent” therefore determines neither the architecture nor its regulatory treatment.^[1]

An address change exposes the differences better than a definition

A customer writes: “Please send my order to the company address from my previous order.” Payment is complete. The shop contains a private address, the CRM has several company contacts and the ERP may already have released the order to the warehouse. The interface can look identical while the technical responsibility is entirely different.

The chatbot explains or collects information

A basic chatbot explains the change deadline or asks for the order number and new address. Without dependable system access, it must not claim the change is complete. Its output is an answer or a structured handover record.

The copilot prepares a decision

A service copilot shows the employee the order, fulfilment status and possible company addresses. It drafts a reply and may prepare a change. The employee checks identity, address and shipping state before confirming. The system reduces research and typing without silently transferring accountability.

The workflow follows a defined case tree

A workflow checks a fixed sequence: identity confirmed, order not released, destination country unchanged and address validated. If all conditions pass, it calls a defined API; otherwise it creates a ticket. An LLM may classify the email or extract address fields without controlling the process.

RPA operates the legacy system

If the ERP lacks a usable API, an RPA flow can enter the approved address into the intended fields. It clicks and types along a known path. RPA does not decide whether the change is permitted; that decision belongs before the UI run.

The agent selects among several next steps

An agent may decide whether to read order data, request missing information, call address validation or hand the case to service. The actual write still needs fixed permissions, thresholds and approvals. Understanding the request does not grant permission to reroute an order already in fulfilment.

Chatbot and copilot mainly differ in the working relationship

A chatbot is first an interface for conversation

A chatbot accepts conversational input and produces replies. It may be rule-based, LLM-based or the front end of a workflow. The channel does not reveal whether an answer comes from model memory, a knowledge base or current commerce data. Tool access alone does not make the interface an autonomous agent.

A copilot works visibly beside a person

“Copilot” describes an assistance role: the system summarises, researches, drafts or prepares an action in the context of the person’s current work. Microsoft similarly distinguishes a built-in Copilot from specialised agents that add knowledge, skills and external services. That distinction also shows why the label is not a fixed technical boundary.^[2]

A copilot fits work where domain judgment remains frequent but people should not collect every document and system context manually. It is not a security control. Suggestions need sources, visible uncertainty and an explicit difference between prepared and executed.

Workflow and RPA are predictable automation on different layers

A workflow has a defined control flow

A workflow connects triggers, checks and actions through modelled paths. Individual steps may use AI to classify an email, extract PDF values or draft a response. Branches and permitted actions remain in code or workflow configuration.

Anthropic makes the same architecture distinction: workflows orchestrate models and tools through predefined code paths, whereas agents let the model direct the process and tool use dynamically. For cleanly decomposable work, Anthropic recommends the simpler approach and notes that agentic complexity trades additional latency and cost for flexibility.^[3]

RPA replaces missing programmatic access

Robotic process automation operates an interface as a person would. Microsoft describes desktop flows as automation for repetitive rule-based work across web, desktop and legacy applications. This is useful in an API prison, but less stable than a supported API: window state, selectors, sessions and UI changes become operating concerns.^[4]

An AI agent controls part of its own execution

An agent receives a goal, context, instructions and a set of permitted tools. The model evaluates the current state, chooses a next step, processes the tool result and decides whether to continue, ask, stop or hand over. Part of the path is created during execution.

OpenAI explicitly separates simple chatbots and single model calls from agents: in an agent, the model manages workflow execution, recognises completion or failure and selects tools dynamically within guardrails. Those tools may retrieve data, perform API actions or operate a computer interface.^[5]

Tool access is necessary but insufficient

A chatbot that always calls one search function is not automatically an agent. The key is whether the model controls execution over multiple states. Conversely, an agent may have read-only tools and merely prepare suggestions. Autonomy and write permission are separate axes.

More flexibility expands the test surface

A fixed script has known paths. An agent may use tools in an unexpected order, stop too early or misjudge a plausible intermediate state. It needs maximum step counts, time and cost budgets, permitted state transitions, idempotent actions, human handover and tests of full trajectories rather than isolated replies.

A production system often combines the terms

A service copilot may start a deterministic workflow. The workflow may use one AI classification step and RPA for a legacy ERP. An agent may use the same copilot interface while holding read-only tools. The design becomes understandable only when each layer is named separately.

Which approach fits which process?

The sensible answer is often a combination, but not the most complicated combination. If a fixed branch works, an agent does not improve operations automatically. If specialists must reinterpret every exception, a pure workflow may collapse under a growing rule set.

• Start with the smallest component that reliably reaches the process outcome.
• Separate read, suggest, prepare and write permissions.
• Prefer supported APIs to RPA when both routes are operationally and economically available.
• Expand agent autonomy only after realistic tests and visible failure paths.
• Measure correction effort and critical errors, not only reply quality or demo speed.

Measurement follows the responsibility assigned to the system

A chatbot needs factual, grounded answers and reliable handover. A copilot also needs acceptance and correction rates and evidence that handling time falls. A workflow needs throughput, exception rate and failed-action tracking. An agent additionally needs visibility into tool selection, step count, stopping behaviour, cost and attempted actions outside policy.

The NIST AI Risk Management Framework calls for documenting specific tasks, methods, knowledge limits and human oversight. Tests should resemble deployment conditions, and system behaviour and components should be monitored in production. These controls follow the system’s actual function, not the label on its product page.^[6]

A selection project should therefore begin with a process diagram, a permission-and-risk matrix and representative test cases. Only then is it useful to ask which product or framework best supports the selected architecture.

A defensible selection takes seven steps

1. Document the process outcome, input, volume and exceptions.
2. Identify systems of record and authoritative sources for every field.
3. Mark decisions that can be implemented entirely with rules.
4. Find variable interpretation tasks where AI has a measurable advantage.
5. Define read, suggest, prepare and write permissions separately.
6. Define success metrics, critical failures, fallback and human approval.
7. Only then select chatbot, copilot, workflow, RPA or agent components.

The potential analysis applies this separation to one concrete business process. A valid result may be an ordinary API, a small workflow or better data ownership—with no agent at all.