When a team says it wants “AI”, it usually means one of three shapes. They differ in what the model knows, what it's allowed to do, and how much can go wrong. Choosing the right shape is most of the design work — and choosing the wrong one is the most common reason AI projects disappoint.

Here's how each shape works, what it's good at, how it fails, and a simple way to decide between them.

Shape one: the chatbot

A conversation with a general-purpose model plus some instructions about tone and purpose. It's quick to build and genuinely good at drafting, rephrasing, summarising text the user pastes in, and brainstorming.

Its weakness is that it only knows what it learned in training. Ask about your refund policy or a customer's order and it has no way of knowing — but it may answer anyway, fluently and wrongly. That makes a plain chatbot a poor choice for anything where facts about your business matter.

Shape two: retrieval (RAG)

Retrieval-augmented generation adds a search step. Before answering, the system looks through your own documents — policies, manuals, product data, past tickets — and hands the most relevant passages to the model along with the question. The model answers from what you've actually written, and can link to its sources so people can check.

// Retrieval in three steps
const passages = await search(question, { topK: 5, user });
const answer = await model.answer({ question, context: passages });
return { answer, sources: passages.map((p) => p.url) };

The quality of a retrieval system depends far more on the search than on the model. A few details matter a lot:

  • Clean sources — outdated or contradictory documents produce outdated or contradictory answers.
  • Sensible chunking — splitting documents so each passage makes sense on its own.
  • Freshness — re-indexing when documents change, so answers don't lag behind policy.
  • Permissions — searching only what the person asking is allowed to see (note the user in the code above).
  • Saying “I don't know” — when nothing relevant is found, the right answer is to say so.

For most internal assistants, help centres and document-heavy workflows, retrieval is the right starting point.

Shape three: the agent

An agent can take actions. Given a goal, it decides which tools to use — look up an order, update a record, issue a refund, send an email, call another system — and works through the steps. That's powerful, and it's where mistakes stop being embarrassing and start being expensive.

  • Give it narrow tools — “refund up to the order total” rather than general database access.
  • Require a person to approve anything consequential: money, customer messages, deletions.
  • Log every step, so you can see exactly what it did and why.
  • Set limits on how many steps it can take and how much it can spend.
  • Test it against tricky scenarios, including users who try to talk it into things.

How to choose

  • Need words, not facts? A chatbot is enough.
  • Need answers about your own business? Use retrieval, and show sources.
  • Need things done in other systems? Consider an agent — with approval steps.
  • Not sure? Start with retrieval. It's useful on its own and becomes the foundation for an agent later.
Start with the least autonomy that solves the problem. You can always give a system more freedom; taking it back is harder.

A natural progression

The shapes build on each other. A help-centre assistant starts as retrieval over your support articles. Once it answers well, it gains one read-only tool: looking up an order's status. Later, with approval, it can draft a refund for a person to confirm. Each step adds autonomy only after the previous one has earned trust with real usage.

What stays the same

Whatever the shape, the essentials don't change: a set of real test questions with known good answers, run every time something changes; logging so you can see what the system did; a way for users to flag bad answers; and an interface that makes checking and correcting easy. Those habits matter more than which model you pick.