A chatbot primarily exchanges messages and helps a person think or draft. An agent pursues a goal across multiple steps, selects tools, observes results, and adjusts its next action. Use the least autonomous design that completes the job. A fixed workflow or chatbot is often easier to test and control than an open-ended agent.
Who this is for: Product leads, operators, and developers deciding how much autonomy an AI-assisted workflow actually needs.
- Choose autonomy from the work required, not from the appeal of the agent label.
- Prefer conversation for judgment-heavy tasks and bounded workflows for repeatable operations.
- Add tool permissions, stop conditions, and approval points before an agent can affect real systems.
Start with the unit of work
A chatbot is a good fit when the useful output is a response that a person reads, revises, or applies. Examples include explaining a policy, drafting interview questions, and comparing options. The person remains the workflow controller. They decide what question comes next and whether anything should happen outside the conversation.
An agent becomes relevant when the system must choose and execute several actions to reach a goal. A research agent might search, open sources, extract claims, notice a gap, and search again. That loop is more than a long answer because observations from tools determine later actions. The distinction is control flow, not personality or conversational style.
Match uncertainty to control
Some processes look multi-step but do not require an agent. If every invoice follows parse, validate, route, and archive, ordinary application code can control those steps while a model handles one ambiguous field. Deterministic orchestration makes the sequence visible and limits the places where generated decisions can alter behavior.
Agents are more useful when the next valid step cannot be listed completely in advance, yet the available actions can still be bounded. Incident investigation is one example: the agent may inspect different logs depending on the first signal. Even then, a person should approve disruptive actions such as restarting a service or changing access.
Compare operating risk
Tool access changes the risk. A wrong chatbot answer can mislead a reader; a wrong agent action can send a message, expose data, or modify a record before anyone notices. Inventory each tool, its data scope, whether the action is reversible, and the consequence of repeated calls. Grant narrow credentials rather than reusing a broad employee account.
Consider failure recovery as part of the choice. A conversation can ask the user to clarify. An unattended agent needs explicit limits for time, steps, cost, retries, and conflicting evidence. It also needs a durable record of instructions, tool requests, tool responses, approvals, and final status so an operator can reconstruct what happened.
Choose the simplest sufficient pattern
Use a decision ladder. First ask whether a form, search interface, or conventional rule solves the need. Next consider a chatbot that proposes work for a person. Then consider a fixed sequence with one or two model decisions. Choose a looping agent only when adaptive tool selection materially improves completion of the defined task.
Revisit the decision after observing real cases. A prototype agent may reveal that ninety percent of requests follow three predictable branches, making a constrained workflow preferable. The reverse can also happen when staff repeatedly leave the chatbot to perform manual lookups. Current platform features change, so confirm implementation details in official documentation during each quarterly review.
Choose a pattern for refund requests
An online shop wants AI assistance with refund emails, eligibility checks, and payment-system updates.
- Separate the tasks: explain policy, extract order details, check eligibility, draft a response, and issue money.
- Classify each action by ambiguity and impact. Drafting is reversible, while issuing a refund changes a financial record.
- Select a fixed workflow that retrieves order and policy data, lets the model draft a recommendation, and asks an employee to approve the refund.
- Pilot against past cases and record false eligibility decisions, missing evidence, and employee corrections before considering more autonomy.
Automation pattern decision card
Complete this card before calling a proposed feature an agent.
- Outcome: Define the finished work and the person accountable for it.
- Variability: List which next steps are predictable and which depend on new observations.
- Authority: Name every readable and writable system plus the narrowest required permission.
- Control: Set approvals, stop conditions, retry limits, and a recovery owner.
- Evidence: State how tests and logs will show whether the chosen pattern works.
Common mistakes
- Building an agent because a product needs a chat interface, even though no adaptive action is required.
- Giving the model a broad goal and broad credentials without defining completion or prohibited actions.
- Using an autonomous loop where a short deterministic sequence would be easier to verify and repair.
Try one
A team wants a system that summarizes a weekly dashboard, asks managers about anomalies, and updates the approved commentary field. Should it be a chatbot, workflow, or agent?
A reasoned answer chooses a constrained workflow with conversation. The summary and questions can be generated, but a manager supplies judgment and approves the final commentary before the write. An open-ended agent adds little because the data source, dialogue, and destination are known. Credit answers that identify read versus write permissions, preserve an audit record, and explain what new variability would justify adaptive tool selection.
Sources
- OpenAI agents guideOfficial guidance for building agent workflows with current OpenAI platform capabilities.
- OpenAI safety best practicesOfficial recommendations for testing, constraints, and human oversight.