The fastest way to waste time with AI is to build the most complex version of a workflow before you know what the workflow needs.
Most teams do not need to start with an agent. They need to understand the difference between three patterns:
- Chatbots answer or draft through conversation.
- Automations run a predefined workflow.
- Agents decide the next step based on a goal, tools, and observations.
Each pattern can be useful. The problem starts when people use the word "agent" for all of them.
This guide gives you a practical decision framework. If you want the deeper definition first, read What AI Agents Actually Are. For the broader founder toolkit, see The Practical AI Stack for Founders or the AI Systems Lab.
The short version
Choose a chatbot when the user needs to ask questions, explore context, or co-create an answer.
Choose an automation when the steps are known in advance and the system should run the same way every time.
Choose an agent when the goal is clear but the path changes based on what the system finds.
Here is the decision table I use:
| Pattern | Best for | Avoid when | Human role |
|---|---|---|---|
| Chatbot | Interactive help, drafting, exploration, support answers | The same action must happen reliably every time | Ask, clarify, approve |
| Automation | Repeatable workflows with clear steps | The next step depends on uncertain research or tool results | Configure, monitor, handle exceptions |
| Agent | Bounded goals with variable paths | The action is high stakes and hard to inspect | Set boundaries, review logs, approve risky actions |
If two patterns could work, pick the simpler one.
Pattern 1: Chatbots
A chatbot is a conversational interface. The user asks, the model responds, and the user guides the next turn.
Good chatbot jobs:
- Answer questions from documentation.
- Draft customer emails.
- Help users explore product setup.
- Brainstorm positioning or messaging.
- Translate messy notes into clearer writing.
The strength of a chatbot is flexibility. The user can correct it, ask follow-up questions, and steer the conversation.
The weakness is reliability. A chatbot is often a poor fit when the business needs a predictable workflow to happen without constant user steering.
Example: customer support answer assistant
A support chatbot can be useful if it:
- Searches approved docs.
- Shows the source for the answer.
- Admits when it does not know.
- Drafts a reply instead of sending automatically.
- Lets a human edit before sending.
That is a good use of chat because the support rep stays in the loop.
It becomes risky when the chatbot is expected to fully resolve every ticket, make account changes, and decide refund policy without clear rules.
Chatbot checklist
Use a chatbot when:
- The user benefits from conversation.
- The answer can be reviewed before action.
- The system can cite or explain its source.
- The task is more about thinking or drafting than executing.
- A wrong answer is recoverable.
Do not use a chatbot when the user really wants a button that completes a known process.
Pattern 2: Automations
An automation runs a predefined workflow. It may use AI inside one step, but the overall path is fixed.
Good automation jobs:
- Summarize every new sales call and save it to the CRM.
- Classify inbound leads by company size and source.
- Turn form submissions into Slack notifications.
- Generate weekly metric reports from known dashboards.
- Draft renewal reminders 30 days before contract end.
The strength of automation is predictability. You know when it runs, what inputs it uses, and what outputs it produces.
The weakness is brittleness. If the workflow hits an unexpected input, it either fails or needs exception handling.
Example: inbound lead triage
A simple AI automation might:
- Receive a new lead form.
- Normalize the company domain.
- Ask an LLM to classify the likely segment using structured output.
- Save the segment to the CRM.
- Notify the correct Slack channel.
The model is useful, but it is not acting as an agent. It is one step in a deterministic pipeline.
That is fine. In many businesses, this is exactly the right level of AI.
Automation checklist
Use an automation when:
- The trigger is clear.
- The steps are known.
- The output shape is predictable.
- Exceptions can be routed to a human.
- You can test the workflow with sample inputs.
Do not use an automation when every run requires open-ended investigation.
Pattern 3: Agents
An agent is useful when the system needs to decide what to do next after observing results.
Good agent jobs:
- Research a company before a sales call.
- Investigate a failed test by reading logs, checking recent changes, and proposing a fix.
- Monitor competitor pages and decide which changes matter.
- Triage a messy support queue where the right next step depends on account history.
- Build a draft report from multiple sources with citations and gaps.
The strength of an agent is adaptability. It can handle a variable path without hard-coding every branch.
The weakness is control. Because the agent chooses steps, you need stronger boundaries, logs, and stop conditions.
Example: competitor change investigator
A simple automation can check a pricing page once a day and report text diffs.
An agent can do more:
- Notice a pricing page changed.
- Decide whether the change is meaningful.
- Open related docs or FAQ pages.
- Compare the new language to previous positioning.
- Draft a short brief with citations.
- Flag uncertainty if the evidence is thin.
This is agent-shaped because the path depends on what it finds.
Agent checklist
Use an agent when:
- The goal is clear but the path is not.
- The task requires tool use.
- The system can safely operate inside boundaries.
- There is a stop condition.
- A human can review the run log.
- You have examples for evaluation.
Do not use an agent when the system can quietly take irreversible actions without review.
The simplest-useful-system rule
The best AI system is the simplest system that completes the job at the required quality level.
I use this progression:
- Prompt: Can a reusable prompt handle the job?
- Structured output: Can the model produce JSON or a fixed schema?
- Retrieval: Does the model need approved context?
- Automation: Does this need to run on a trigger?
- Agent: Does the next action depend on observations?
- Human approval: Does any action cross a risk boundary?
Do not skip levels because "agent" sounds more advanced. Advanced is not the goal. Useful is the goal.
How to choose for common founder workflows
Customer research
Start with a chatbot if the founder wants to ask questions across interview notes.
Use automation if every interview should be summarized into the same format.
Use an agent if the system needs to gather supporting evidence from calls, tickets, and analytics, then decide which theme deserves deeper investigation.
Sales prep
Start with automation if every account brief uses the same sources.
Use an agent if the system needs to follow clues, search public sources, inspect CRM history, and decide which points are relevant for this account.
Keep the final brief human-reviewed either way.
Support operations
Start with automation for classification, tagging, and draft routing.
Use a chatbot for reps who need help answering from docs.
Use an agent only for bounded workflows like "collect required context for a bug escalation" or "prepare a refund recommendation for review."
Content and SEO
Start with automation for briefs, outlines, refresh reminders, and metadata checks.
Use a chatbot for editing and idea development.
Use an agent when the system needs to research a topic, compare sources, collect examples, and identify where human expertise is missing.
Failure modes by pattern
Every pattern fails differently.
Chatbots fail when they sound confident without grounding. Fix this with retrieval, citations, and clear "I do not know" behavior.
Automations fail when real-world inputs do not match the happy path. Fix this with validation, retries, and exception queues.
Agents fail when goals, tools, and permissions are too broad. Fix this with narrow jobs, short tool lists, run logs, and stop conditions.
The fix should match the failure mode. A brittle automation does not automatically need to become an agent. Sometimes it needs better validation.
A practical design exercise
Pick one workflow and write a one-page spec:
- What triggers the workflow?
- What is the desired output?
- What inputs are required?
- What steps are always the same?
- What steps depend on what the system finds?
- What can the system do without approval?
- What must always require approval?
- What should be logged?
- How will we know the output is good?
Then choose the pattern:
- Mostly conversation: chatbot.
- Mostly fixed steps: automation.
- Variable path with tools: agent.
This exercise is intentionally plain. It forces the team to design the workflow before getting distracted by model choices.
What I would build first
For most founders, I would not start with a general assistant. I would start with a narrow automation or agent around one painful recurring workflow.
Good first projects:
- Weekly customer research digest.
- Sales call prep brief.
- Support triage and draft replies.
- Competitor change monitor.
- Content refresh checklist.
These workflows have clear inputs, clear outputs, and enough repetition to justify the build.
Once one workflow is reliable, expand from there. Reliability compounds. A pile of impressive demos does not.
The bottom line
Chatbots help people think and draft.
Automations make known workflows repeatable.
Agents handle bounded goals where the path changes.
The right choice is usually the least magical one that works. Start small, instrument the workflow, and add more agency only when the system has earned it.