What is an AI agent: how does it differ from a chatbot and from a script

What does this solve?

Working with a language model most often looks like a manual conveyor belt: a person copies data into a chat, receives text, transfers it to a table, letter or ticket, and goes for the next piece of data. The question “what is an AI agent” arises exactly when shifting takes more time than the task itself. The agent removes the person from the middle of the chain: he retrieves the data, calls the necessary tool, looks at the result and chooses the next step. The benefit appears in tasks involving several moves, where neither the number of steps nor what will be found along the way is known in advance.

How it works

The agent is assembled from four parts: a model, a set of tools, an execution loop, and a stopping condition. Everything else is a tie around them.

System prompt. Role, boundaries, response format, prohibitions, procedure for action in a controversial situation. Behavior in case of insufficient data is specified separately: ask, refuse, or mark the result as incomplete. Without this point, the model fills the void with guesswork.

Tools. Functions with name, text description and argument scheme. The model reads the description and uses it to select a challenge. The scheme is read by the executing code - it rejects calls with garbage arguments before execution. The tool can be a read request to a database replica, sending a letter, reading a file, calling an internal HTTP method, or searching the knowledge base.

Context. Everything that the model sees at the current step: system prompt, task, call history and their results. The context is finite, and its size dictates the rest of the decisions - what to put in whole, what to trim, what to squeeze.

Hinge. Code without magic. The executor sends the context, receives a response, and then there are two branches: in the response there is text - the cycle is completed; in the response there is a call to the tool - the executor makes the call himself, adds the result to the context and sends the request again.

One whole step

1. The executor collects the context and sends a request to the model.
2. The model returns either the final text or the tool name with arguments.
3. The executor checks the arguments against the schema and according to its own access rules.
4. The executor makes the call and receives the result - a string, JSON, an error.
5. The result is added to the context, the step is repeated.

The model does not perform anything itself. It names the tool and arguments, and executes the executor's code. From here both security and rights grow: the agent can do exactly what the functions were given to him, and not a step more.

What is the difference between a chatbot

Chatbot responds. The agent acts, but the text remains a by-product of the action.

What is the difference from a script

The script contains the order of steps directly in the code: first upload, then filter, then letter. The branching is also predetermined - the programmer listed the cases that he came up with. The agent chooses the next step at each iteration by looking at the actual result of the previous one. When the table is empty, the script crashes or goes into the “otherwise” branch; the agent reads the error message and tries another request.

The price for flexibility is non-determinism. The same input gives different execution traces. A script with one input always gives the same output.

Rule: the order of steps is known in advance and does not depend on the data - a script is written, not an agent.

Autonomy levels

• Prompt. The agent collects data and proposes an action, the person presses the button.
• Executor with confirmation. Reads on his own, writes only after explicit consent to a specific action.
• Autonomous in a sandbox. Full cycle on data copy or test circuit.
• Autonomous based on combat data. Full cycle with write permission, narrow set of tools, full magazine.

The transition occurs from bottom to top and one task at a time, and not for the entire agent at once.

How to connect

To understand, and not retell other people's definitions, it is enough to assemble a simple cycle on one task.

Step 1. Task with a verifiable result. Anything where the answer is checked mechanically is suitable: “how many orders without payment for the last week”, “find a letter with details in the correspondence”. “Do your marketing better” will not do.

Step 2. Model with support for calling tools. In the API this is a separate request parameter with a list of functions (tools, functions —name varies by vendor). The model's response comes as a structure with a challenge, rather than free text.

Step 3. Two or three tools. For the first assembly, reading (querying a database or file) and writing (sending a message) is enough. Each with an honest description: what it does, when to call, what it can’t do.

Step 4. Loop. Pseudocode in its entirety:

messages = [system_prompt, user_task]
for step in range(MAX_STEPS):
    reply = model.create(messages=messages, tools=TOOLS)
    if not reply.tool_calls:
        return reply.text
    for call in reply.tool_calls:
        check_allowed(call.name, call.arguments)   # свои правила доступа
        result = TOOLS[call.name](**call.arguments)
        messages.append(tool_result(call.id, result))
raise LimitReached

Step 5. Fuses. Hard iteration limit, tool timeout, white list of tables and addresses, separate role in the database with read-only access. Return a tool error to the model in text, rather than dropping the process: the agent often corrects itself when it sees the reason.

Step 6. Journal. Write each step: time, tool name, arguments, result length, spent tokens. Without a trace, behavior analysis turns into fortune telling based on the final text.

Step 7. Run on prepared examples. A dozen problems with known answers, each done several times in a row.

Useful scripts

• Parsing incoming mail: the agent reads the mailbox, takes out the contents and attachments, and opens a ticket with the fields filled in.
• Error duty officer: takes the latest entry from the tracker, searches for similar ones, raises the log, writes a short version into the chat with the culprit.
• Answer to the question based on the data: it selects queries itself, checks several sections, gives the numbers along with the calculation method.
• First line of support: answers based on the knowledge base, and when asking an unfamiliar question, gives the person the already collected context.
• Order in reference books: finds duplicate counterparties, combines cards, gives disputed pairs to the person.
• Review of changes: reads the thread, looks for discrepancies with the rules adopted in the project, leaves comments in the merge request.

Limitations

The cost increases faster than the number of steps. Each iteration resends the entire accumulated context. Ten steps are ten queries with a growing tail, not ten short questions.

An early step error reaches the end. The model rarely reverses its own conclusion: a misunderstood table in the second step turns into a confident result in the eighth. It is treated by checks between steps, and not by persuasion in the prompt.

No repeatability. The same input gives different traces. Everything where exactly the same result is needed - payroll calculations, postings, issuing a document - remains with deterministic code.

Rights are more dangerous than quality. The write agent repeats the error quickly and many times. Access is granted for one function, a combat record - where the action is reversible or goes through confirmation.

The tool cannot be connected without an API. Where the supplier does not have an interface, fragile automation through the browser remains: someone else's redesign breaks it without warning.

Responsibility is not delegated. A legally significant decision, a medical or personnel assessment, a conversation with a client on the verge of a conflict is up to the person.

How to check the result

A set of repeatable tasks. Collect about a dozen problems with pre-known answers and add three or four obviously unsolvable ones: no data, access is closed, the question is beyond your competence. Correct behavior on them is a clear refusal, not a plausible text.

Multiple runs of one task. The discrepancy in responses between runs shows places where the problem statement or tool description allows for double reading.

Reading the trace, not just the response. A true result with a meaningless middle means a coincidence that will fall apart on adjacent data. The log shows which tools were called, in what order, and what was returned.

Checking fuses. Verify the right to the table and make sure that the agent reports the refusal and does not make up numbers. Slip in a tool that always returns an error and see if the loop stops at the iteration limit.

Counting tokens and time for a task. The figure from the journal is compared with the person’s time for the same operation. Does not converge in favor of the agent - the task was chosen incorrectly, and this is visible before implementation, and not after.