Intermediate

FAQ vs Task vs Copilot Bots

Every chatbot built with an LLM falls into one of three fundamental patterns, each with a distinct architecture, a different relationship between user and system, and a different set of failure modes. Getting this choice wrong early is expensive — it shapes your data model, your memory strategy, your evaluation criteria, and your infrastructure.

The Three Patterns

FAQ Bot

Copilot Bot

Task Bot

Agent

Read-only / Stateless

FAQ Bot — answers questions, no side effects

Autonomous / Stateful

Agent — multi-step, self-directed goal completion

Autonomy is a spectrum — choose the simplest pattern that solves your problem

Dimension	FAQ Bot	Task Bot	Copilot Bot
Core purpose	Answer questions from a known knowledge base	Complete a specific action or workflow end-to-end	Augment a human working inside a tool or workflow
User interaction style	Question → Answer (single turn, often)	Goal → Multi-step dialogue → Action completed	Suggestion → Human decides → Accept / modify / reject
LLM's role	Retrieve + rephrase grounded content	Understand intent, collect parameters, call APIs	Generate, summarise, suggest — human in the loop
State required	Minimal — usually stateless	High — tracks collected slots, current step, completion	Context of open document / data / user session
Autonomy	None — read-only, no side effects	Medium — executes with user confirmation	Low — suggests, never commits without human
Failure mode	Hallucination / out-of-scope answers	Incomplete slot collection, wrong API call, partial action	User accepts bad suggestion blindly
Common examples	Support docs bot, policy Q&A, HR handbook	Restaurant booking, refund bot, onboarding wizard	GitHub Copilot, Notion AI, Excel Copilot, code review bot

Pattern 1 — FAQ Bot (Knowledge Q&A)

The FAQ bot answers questions from a defined knowledge base. Users ask things; the bot retrieves and synthesises grounded answers. It has no side effects and takes no actions. The canonical implementation is RAG (Retrieval-Augmented Generation).

Architecture

Documents

PDFs, web pages, help articles

→

Chunk + Embed

Split & vectorise into DB

→

User question

Embedded at query time

→

Retrieve top-k

Nearest-neighbour search

→

LLM synthesis

Grounded answer from chunks

→

Cite source

Surface chunk + document link

FAQ bot = RAG: retrieve grounded content, synthesise, cite. Never answer from training knowledge alone.

Grounding enforcement: System prompt instructs the LLM to answer only from provided context, to say “I don't know” if the answer is not in the retrieved chunks, and never to invent.

Citation: Surface the source document/chunk alongside the answer so users can verify.

When to choose FAQ Bot

Your primary goal is answering questions, not completing actions

Content changes regularly (policies, pricing, product docs) — RAG means no retraining

Risk tolerance for wrong answers is low — you need citation and grounding

You want to start simple and prove value quickly

Anti-patterns

Using a FAQ bot for tasks that require taking actions (booking, submitting forms)

Skipping grounding — letting the LLM answer from training knowledge rather than your docs

Not testing out-of-scope questions — the bot must gracefully decline, not hallucinate

Pattern 2 — Task Bot (Goal Completion)

The task bot helps a user accomplish a specific goal that involves multiple steps and ultimately calls an API or takes an action. It collects required information through dialogue (slot-filling), validates inputs, and executes — booking a restaurant, processing a refund, onboarding a new user.

Architecture

Intent classify

What does the user want to do?

→

Slot collection

Gather all required parameters via dialogue

→

Validate

Check formats, check backend system

→

Confirm

Show summary — user approves

→

Execute API

Call backend — booking, CRM, payment

→

Confirm result

Success / failure message to user

Never skip the confirmation gate before any irreversible action (payments, cancellations, sends)

When to choose Task Bot

There is a clear, bounded task with defined inputs and a backend API that executes it

The task currently requires form fills, phone calls, or email chains — bot can automate the collection

Users have a clear goal (not “explore information”) every time they interact

Anti-patterns

Executing irreversible actions without a confirmation step — booking, charging, deleting

Designing for the happy path only — real conversations involve interruptions, corrections, and restarts mid-flow

Exposing too many tasks in one bot — each task adds complexity; start with one and expand

Pattern 3 — Copilot Bot (Human Augmentation)

The copilot bot is embedded inside an existing tool and augments the human using it. Unlike the other two patterns, the copilot does not own a conversation — it assists within a context the human is already working in. It reads the current state (open document, code file, data row), generates suggestions, and the human decides whether to accept, modify, or ignore them.

Architecture

1. Context injection: The user's current context (open file, selected text, cursor position, active data row, current form state) is injected into the LLM prompt automatically.

2. Suggestion generation: LLM generates completions, rewrites, summaries, or next steps — framed as suggestions. Output is shown inline (ghost text) or in a side panel.

3. Human-in-the-loop (mandatory): The copilot never commits anything. Every action requires an explicit accept gesture (Tab to accept, click “Apply”, approve in diff view). This is the defining architectural constraint.

4. Diff / preview UI: For modifications, surface a diff view showing what changed so the user can see the exact delta before accepting.

5. Feedback loop: Track accepts and rejections per suggestion type. Low acceptance rates on a specific suggestion type indicate the model or prompt is miscalibrated for that context.

When to choose Copilot Bot

You are building inside an existing tool with rich context (IDE, CMS, spreadsheet, email client)

The user is an expert who makes final decisions — the AI speeds up execution, not judgment

Risk tolerance for mistakes is low — errors must be catchable before they propagate

Anti-patterns

Auto-committing suggestions without user confirmation — this is the line between copilot and agent

Injecting too much context — large windows are slow and expensive; be selective about what you inject

Not tracking accept/reject rates — without feedback data you cannot improve the suggestion quality

Hybrid Patterns

Combination	Example	How they compose
FAQ + Task	Customer support bot (answers questions + can issue refunds)	Intent classifier routes: informational queries → FAQ pattern, action requests → Task pattern
Copilot + FAQ	Code assistant with embedded documentation lookup	Copilot generates suggestions; can pull from docs RAG as part of context
Task + Copilot	Sales workflow bot (copilot drafts email, task bot logs CRM entry)	Copilot handles content creation, Task pattern handles the write-back to external systems

Choosing Your Pattern

Start here: Does the user need to do something (take action) or know something (get information)?

Know something → Is there a defined knowledge base of authoritative content? → FAQ Bot (RAG)

Do something → Is the task well-defined with a backend API to call? → Task Bot

Both, inside a tool the user already uses → Do they need AI suggestions within their working context? → Copilot Bot

Complex, multi-system, multi-step goals with minimal human involvement → → Agent (see Agents section)

Common Architecture Mistakes

Building an agent when you need a task bot

Agentic architectures are complex, expensive to evaluate, and harder to make reliable. If your use case has a bounded set of tasks with known APIs, a well-designed task bot is more predictable, cheaper to run, and easier to test.

Building a FAQ bot without grounding

A general-purpose LLM answering from its training knowledge is not a FAQ bot — it is an ungrounded chatbot. Without a retrieval layer and strict system prompt grounding, the bot will confidently answer from outdated or incorrect training data.

Designing a copilot that auto-commits

The moment a copilot takes an action without explicit human approval, it has crossed into agent territory. Keep copilots suggestion-only until you have built the trust, oversight mechanisms, and rollback capabilities required for autonomous action.

Mixing patterns in a single conversation thread

A bot that answers questions, takes actions, and provides inline suggestions simultaneously is difficult to evaluate and maintain. Start with one pattern; add a second only when the first is stable and you have explicit routing logic.

How Evaluation Differs by Type

Bot type	Primary metric	Key test cases
FAQ Bot	Answer faithfulness to sources; out-of-scope detection rate	Questions whose answers are in docs; questions whose answers are not; ambiguous questions
Task Bot	Task completion rate; slot accuracy; wrong-action rate	Happy path; mid-flow corrections; invalid inputs; ambiguous intents; abort requests
Copilot Bot	Suggestion accept rate; error rate in accepted suggestions	Varied contexts; expert users; novice users; edge-case inputs; adversarial content

Checklist: Do You Understand This?

Can you describe the core purpose and LLM role for each of the three patterns?
Can you explain when to choose a FAQ bot over a task bot, and vice versa?
What is the defining architectural constraint that separates a copilot from an agent?
Can you describe the slot-collection mechanism in a task bot and why a confirmation gate matters?
What is the primary metric for evaluating each bot type?
Can you name three anti-patterns — one per bot type?
If someone asks for a “support bot that can answer product questions and process refunds”, which combination of patterns do they need and how would you route between them?