Where an AI agent earns its place

An agent is a worker with tools, not a chat box with a personality. It earns a place when the job is repetitive, the tools are narrow, and a person can see what it did.

Start from the queue, not the model

Look at the work that already arrives: status questions, document sorting, a first draft of a reply, a lookup across three systems. If a trained person follows a checklist, an agent can follow a shorter one. If the job needs judgement you would not delegate to a new hire, do not delegate it to a model. The model is there to prepare the work, not to own the consequence.

Tools should be boring

Give the agent a search over your documents, a read of one record, and maybe a draft that a person sends. Do not give it a general “update anything” tool. Each tool needs an owner, a log, and a failure the user can see. When the tool times out, the agent should stop and say so, rather than invent the record.

Citations keep the answer attached to the business

If the agent answers from private files, the reply should point at the file and the passage. That is the difference between a demo and a system a manager will trust. Log the question, the tools called, and the final text. You will need that trail the first time the answer is wrong.

A tool the model cannot wander from

Each tool is a function with a name, a description the model sees, and a schema for the arguments. The function itself checks permission and refuses anything outside that schema. The model does not receive a database connection. It receives the result of a function you wrote.

If the tool moves money, changes a price, or sends a message to a customer, a person confirms it. The model can prepare the draft. The send button belongs to the operator who will answer for it.

JSON · A tool schema for one lookup

{
  "name": "read_request",
  "description": "Read one service request by its reference. Read only.",
  "parameters": {
    "type": "object",
    "properties": {
      "reference": {"type": "string", "description": "Request reference, such as LTL-1042"}
    },
    "required": ["reference"],
    "additionalProperties": false
  }
}

The record you keep when the answer is wrong

Store the question, the tool calls with their arguments and results, the model’s reply, and the person who sent it if a person sent it. You will open that record the first week, when a customer says the agent promised something the business does not offer. Without the record you have a dispute. With it you have a passage, a tool result, and a sentence you can correct.

Evaluate the agent on the real queue, not on a demo question you wrote to show the model succeeding. Take twenty requests from last month. Run the agent. Count how many drafts a person could send with a light edit, how many it refused, and how many it got wrong. The wrong ones are the spec for the next tool restriction, not a reason to write a longer prompt.

If the job is to draft a reply, the screen should show the draft and the sources beside it, and the send control should belong to the operator. If the job is only to look up a status, the agent should return the status and stop. A chat box that can also update the record is two products, and the second one needs a permission you would give a new hire.

Start with one queue for a month. Add a second tool only when the log shows a repeated lookup the first tool cannot do. An agent that gains a new tool every week has no evaluation, and you will not know which change made the answers worse.

Before you add a chat box

1. Pick one queue and write the checklist a person uses today.
2. Allow the agent only the tools on that checklist.
3. Store the question, the tool calls, and the reply.

On the site

• AI agents and LLM integration
• RAG systems