A chatbot primarily exchanges messages. An agent may also retrieve private information, choose tools, and take actions. The practical difference is authority, not personality.
/ 01
Level one: answer
A public assistant can explain approved services, summarize public information, and route a visitor. Its knowledge should be limited to public-safe sources, it should disclose that it is AI, and it should say when the approved material does not answer the question. Conversation alone does not make it an agent.
/ 02
Level two: recommend
A recommendation system uses context to propose a next step, draft, classification, or schedule. A person reviews the source and proposed result before anything consequential happens. This is often the best first operating model because it creates evidence without granting write authority.
/ 03
Level three: act
An action agent can create records, schedule meetings, send approved messages, or update systems. OpenAI's practical definition emphasizes that an agent uses a model to manage workflow execution and tools to gather context or take action within guardrails. Each tool needs narrow authorization, typed and validated inputs, allowlisted actions, rate limits, confirmation rules, and an auditable result.
Keep the agent's words separate from tool authority. Saying 'I booked it' is not evidence; the calendar provider's confirmed event ID is. On tool failure the agent must report the failure and preserve control rather than invent success.
/ 04
Choose the least authority that solves the problem
Do not grant write access simply to make a demo feel impressive. Start with answers or recommendations, measure accuracy, and add one action at a time only when the business can control exceptions and recovery. If deterministic rules solve the workflow, an agent may add cost and unpredictability without adding value.
/ 05
Use an authority ladder for every tool
Document each tool on an authority ladder: read public data; read private data; draft; create reversible records; communicate externally; change money, access, legal status, or production. Require stronger authentication, confirmation, logging, and review as authority rises.
Tool descriptions should state purpose, permitted inputs, prohibited actions, expected output, timeout behavior, and escalation. Capture edge cases in instructions and tests rather than relying on the model to infer policy.
- What identity is acting?
- Which organization's records are in scope?
- What is the narrowest required permission?
- Can the result be reversed?
- What evidence proves success?
- Which failure returns control to a person?
- How is the tool disabled immediately?
/ Practical takeaway
Classify the system by authority, not personality. Add tools one at a time, require provider evidence, and increase controls as actions become harder to reverse.