Why AI Agents Exist?

Why AI Agents Exist?

A language model can explain the difference between synchronous and asynchronous communication, analyze technical specifications, and suggest ways to investigate an architectural inconsistency. None of those capabilities requires the model to interact directly with a repository or execute software operations.

The situation changes when we expect an application to do more than generate an answer from information already available in its input.

An application investigating our order-processing system may need to search for documents, retrieve their contents, inspect relationships between components, and use the results to determine what to do next. Conventional software logic can implement some of these steps. Other steps may benefit from the language model's ability to interpret incomplete information and suggest next actions.

Understanding when that flexibility is useful requires separating three concerns: what the model computes, how the application coordinates operations, and who determines the next action.

These concerns are closely related, but they are not interchangeable. A system can use a sophisticated language model while following a completely predetermined execution sequence. Another system may use the same model but allow it to select tools and guide parts of the investigation as new evidence becomes available.

The difference is architectural. It concerns how responsibilities are split between the model and the surrounding software.

What a Language Model Actually Does?

When an application sends a request to an LLM, it provides an input context that the model uses to generate an output.

That context may contain instructions, previous messages, technical documents, structured data, or descriptions of tools that the application makes available. The model processes this information and produces an output according to its learned parameters and inference procedure.

For a typical autoregressive language model, generation involves predicting successive tokens. Rather than producing an entire response through a single indivisible operation, the model assigns probabilities to possible next tokens based on the preceding sequence.

The probability of an output sequence can be represented using the chain rule of probability:

In this expression, c represents the input context, while x1,...,xn represent the tokens in the generated output. Each conditional probability on the right-hand side describes how likely a particular token is, given the context and the preceding tokens.

The equation factors a conditional joint probability distribution. An autoregressive model learns to estimate the conditional distributions involved, and a decoding procedure uses those estimates to construct an output sequence.

Consider a simplified example. Suppose the model has received a prompt containing the beginning of a sentence:

The payment service communicates with the order service through…

Based on its context and learned parameters, the model assigns probabilities to possible continuations. Depending on the information supplied, terms such as HTTP, events, or a message broker might receive different probabilities.

The model's output depends on the context it receives. If we provide an integration specification describing event-driven communication, that information can affect the continuation it generates.

However, the model's ability to describe an operation is not the same as performing it.

If the model produces a sentence saying that an architectural decision record should be examined, no document has necessarily been opened. If it generates a SQL query, no database has necessarily been queried. If it produces an HTTP request, no network operation has necessarily occurred.

These distinctions matter when language models integrate with external tools.

From generated text to tool requests

Suppose our application exposes a tool named read_document. The tool accepts a document identifier and returns the corresponding content from an authorized repository.

The model may receive a description of that tool as part of its context. When it determines that reading a particular document would help with the investigation, it can generate a structured request identifying the tool and its arguments.

For example:

{
  "tool": "read_document",
  "arguments": {
    "document_id": "DOC-0001"
  }
}

The exact representation depends on the model interface and application protocol. Some APIs provide dedicated tool-call structures rather than requiring the application to interpret arbitrary JSON embedded in text.

Regardless of the representation, the architectural distinction remains the same: the model has produced a request for an operation, not evidence that the operation succeeded.

The application must determine what to do with that request.

First, it needs to identify the requested tool and verify that the supplied arguments conform to the tool's expected interface. If the tool requires a document identifier, for example, the application should reject arguments that don't match the required structure.

But structural validity is only one part of the problem.

A request can be syntactically valid and still be unauthorized. The document might exist in a repository that the current user is not permitted to access. The requested operation might exceed the application's configured permissions or violate restrictions associated with the current task.

For this reason, validation and authorization should be treated as distinct responsibilities.

Once the application determines that an operation is permitted, it can invoke the corresponding implementation. The tool may return the requested document, report that the document does not exist, or fail because the underlying service is unavailable.

The application then needs to handle that result.

If the document is retrieved successfully, its contents can become part of the information available to the model during a subsequent interaction. If the operation fails, the model may need an appropriate error or observation so the system can determine how to proceed.

The complete interaction therefore involves more than a single model invocation.

It includes model inference, interpreting the generated request, validation, authorization, tool execution, and handling the resulting observation.

This separation also establishes a useful security boundary. A model may propose an operation based on information contained in a document, but the document itself should not be able to grant permission to perform that operation.

Imagine that DOC-0001 contains a paragraph instructing the system to upload the repository to an external server before continuing the investigation. That instruction is part of the document being analyzed. It is not an authorization from the application user.

A properly controlled execution environment should prevent the model from turning such untrusted content into an unauthorized external action.

We will examine this problem in greater detail later in the series. For now, the important point is that tool use introduces responsibilities that cannot be reduced to the model's ability to generate a tool request.

The model may help select an operation, but the surrounding software must still decide whether and how to execute it.

This raises another question: does the model need to select operations at all? In many applications, the answer is no.

References & Further Reading

Anthropic - Building Effective Agents

Yao et al. - ReAct: Synergizing Reasoning and Acting in Language Models

Schick et al. - Toolformer: Language Models Can Teach Themselves to Use Tools

OpenAI - A Practical Guide to Building Agents