31 programs using AI, only 3 count as AI agents

Everything is called an agent now. Put a chat box on a website — agent. Write a scheduled job that calls an API — agent. String two prompts together — definitely an agent. The word has been used until it carries no information: when someone says "we have an AI agent," you have no idea what they actually built.

Last week I listed every program on my machine that calls AI and checked them one by one against a set of criteria.31 programs. Only 3 count as agents.

And here's the part worth talking about:All 3 are for internal use. Not one of the customer service bots we ship is an agent — and that's deliberate.

Three criteria

For a system to be called an agent, three conditions must all hold:

1. You give it a goal, not steps."Fix what's broken here" is a goal. "First read this file, then compare, then output" is steps. If you're giving steps, the AI is just filling in one blank.

2. It can actually act. It has tools — it can read files, edit files, run commands, call APIs. An AI without tools can only talk, and once it's done talking, that's it.

3. It decides its own next step. It runs in a loop: do something, look at the result, decide what's next. Not your code laying out the sequence for it to follow.

All three must hold for it to be an agent. Something with no tools that only talks is a chatbot. Something where your code hard-codes the flow and the AI just fills one slot is what the industry calls a workflow。

That's not an insult. In most cases a workflow is the right choice — more on why below.

A 30-second test

The fastest way to tell whether a system is an agent is to ask:

Take away all its tools. Can it still do 90% of what it did before?

Yes → not an agent; the tools were decoration. No → it is.

Every customer service bot we build passes the "still runs without tools" test — because theynever had tools to begin with. The startup parameters say "tool list: empty." Not a single one.

Where things land

The three that count as agents

① Overnight auto-repair. Our own LINE food-ordering service. It runs once every night: first it checks five health signals; if they're all zero, it stands down. If any signal fires, it hands the AI a goal and a set of boundaries and lets it do the autopsy, find the cause, change the code, and deploy. No human supervision — I'm asleep.

② The multi-agent system. Each member is a long-running AI process with its own memory, and they can hand work to one another. Before any of them acts, it gets stopped and asks me Allow or Deny. (I wrote up the process of building it inI started an AI shogunate）

③ Remote control from my phone. I send commands via messaging app, and the AI reads files, checks status, and reports back from my computer. Read-only by default; acting requires a one-time passcode.

The ones that don't (the other 28)

Every AI customer service bot we ship — restaurants, bookings, knowledge-base Q&A — has the same shape:

客人的問題
  → 我們的程式做檢索（RAG：把最相關的幾段資料撈出來）
  → 呼叫 AI 一次
  → 一段回答（有時附一個「轉真人」或「建預約」的標籤）
  → 我們的程式決定接下來做什麼

The AI does two things here: understand the question, and write it in plain language.What decides "what happens next" is our code, not the AI. That's a workflow.

Then there's a simpler batch: translation, post formatting, lead scoring — fixed pipelines where the AI is one classifier slot. Calling these workflows is generous; they're really just "calling an API."

Why customer service is deliberately not built as an agent

This is the part I most want to get across.

Because in a customer service setting, every advantage of an agent turns into a disadvantage.

When a customer asks "what time do you close," you don't need something that decides on its own whether to query the database, whether to call three APIs, whether to retry. You need something that gives the same answer every time.

And therisk is completely asymmetric: the upside of customer service is "answers well"; the downside is "makes false promises, corrupts data, sends the wrong emails." An agent raises the ceiling slightly and lowers the floor a lot.

Last month we did a full tightening pass: every one of the twenty-odd places in the system that calls AI was changed to an explicit whitelist of "only these tools allowed," and every customer-facing service was set tozero tools. What that change really did wasstrip the agent-ness out of customer service。

So when should you use an agent?

It's only worth it when all four conditions hold:

1. The task can't be spelled out in steps— you don't know what needs fixing either, only that it's broken
2. The outcome justifies the cost— agents are slow and expensive; one run can cost dozens of times a single call
3. The AI can actually do it— not that you hope it can
4. Mistakes are recoverable— you have tests, review, and rollback

The fourth is the dividing line. Don't hand an agent anything you can't take back.

Guardrails come from reversibility, not permissions

The night patrol runs withpermission prompts skipped. That sounds insane, but it's deliberate: an automated process running at 3 a.m. with nobody around, designed to "ask before acting," is a process that will never act.

Instead, risk is held back by four gates:

1. Reproduce before repairing— if the problem can't be reproduced, no changes allowed
2. Verify every link in the deploy chain— "the command didn't error" doesn't count as a pass
3. Automatic rollback on failure— revert to the last known-good version
4. Two rollbacks in a row trips the circuit breaker— stop and wait for a human

The difference:Permission approval controls what it does. Reversibility controls what happens when it does the wrong thing. In unsupervised settings only the latter helps — because the former requires someone to be there.

So is "AI agent" a term worth anything?

It is, but only when used correctly.

If you're evaluating a vendor and hear "we build AI agents," one question is enough:

"What tools does it have? And how do you take it back when it fails?"

If they can name a concrete tool list and a rollback mechanism, it's real. If the answer is "it's very smart, it figures things out," it's usually a single API call in agent packaging.

If what you're building is AI customer service —what you want probably isn't an agent. You want something with stable answers, read-only access, and a worst case of one wrong sentence. That thing is more boring, but it's the right thing.

FAQ

Does a RAG chatbot count as an AI agent? No. RAG means "retrieve first, then have the AI answer based on what was retrieved." The retrieval is done by code; the AI only handles the final generation. The AI isn't the one deciding the next step.

Does calling tools make something an agent? Not necessarily. What matters is who decides whether to call and what happens after the call. If the sequence is laid out by code, it's a workflow. If the AI looks at the result and decides the next step itself, that's an agent.

Is a workflow somehow lower-tier? No. Workflows are predictable, auditable, cheap, and fail in a contained way — which is exactly what most business use cases need. Agents are for tasks where the steps can't be spelled out and mistakes are recoverable.

How do I tell whether a vendor's "agent" is real? Ask for the tool list and the rollback mechanism. A real agent always comes with a clear account of what it can touch and how to undo a mistake.

Which should my company start with? Start with a workflow. Let the AI handle one slot in a fixed process — classification, summarization, drafts — and once it's stable, consider whether to hand over decision-making. Skipping this step and going straight to agents usually means paying for the right to say "we have AI too."

Further reading:

• I started an AI shogunate
• The real distance of automated lead generation: four days, 638 posts, for one reply seen by 3 people
• Google's newest forecasting model lost to a formula from 1994