How AI agents work:
tools, memory and human oversight

Below are its eight building blocks and the distinctions between them that are worth understanding before you commission or evaluate such a system. Technical statements are accompanied by links to primary sources; recommendations are marked separately.

The running example

The example is fictional. A small manufacturing company wants to compare several packaging suppliers on price, delivery time, minimum order quantity and payment terms. The desired result is a comparison table in which every figure links to its source, a calculation of the total cost per unit of product, and a draft email asking the suppliers for quotes. The email goes out only after the responsible manager approves it.

1. Workflow, agent and graph: who chooses the next step

The key distinction is who determines the order of actions. In a workflow, the path is fixed in code in advance: get the list of suppliers, collect the price lists, calculate, format the table. In an agent, the model itself chooses the next action at each step, taking into account the results it has already obtained (LangGraph: workflows and agents).

A graph is not a third competing product but a way of describing a process as a set of steps (nodes) and transitions between them, including conditional ones. A single graph can combine fixed sections with a section where an agent operates. The name LLMChain, found in older tutorials, refers to early LangChain interfaces; it is not a required technology for a modern workflow.

In our example, collecting price lists from known, similarly structured websites can be done as an ordinary workflow. An agent is needed where the path is not clear in advance: one supplier's price is in a PDF, another's is available only through an enquiry form, and a third supplier's page is clearly out of date.

2. ReAct: action, observation, next step

ReAct is a method in which the model alternates between reasoning about the task and taking actions in an external environment, and the result of each action (the observation) is taken into account in the next step (Yao et al., ReAct). For example: "I need supplier B's price" → search the supplier's website → a page is found where the price is shown excluding VAT → before comparing, it must be brought to a common basis.

Two caveats. First, ReAct is a way of organising work, not a guarantee of correctness: the agent may misread a page or decide that it already has enough data. Second, oversight does not require seeing the model's hidden internal reasoning. What is visible is enough: the plan, which tools were called, what they returned, which sources the conclusion rests on, and a brief explanation of the decision.

A modern agent in LangChain is built as a "model — tools" loop with supporting infrastructure: instructions, a set of tools and intermediate handlers (middleware). The model only requests a tool call; the application executes it (LangChain: agents). This means reliability depends not only on the model but also on what the application permits and how it handles errors.

3. Memory: the conversation, long-term information and RAG

The model does not remember previous requests by itself. If a manager first writes "compare packaging suppliers" and then "add delivery time", the second request makes sense only if the application has passed the model the history or a condensed summary of it. A long history has to be shortened, summarised or filtered: the context window is limited, and extra text makes the request more expensive and can worsen the answer (LangChain: short-term memory).

It is useful to distinguish three things:

• Short-term memory is the state of the current conversation or task: messages, intermediate results, tool calls.
• Long-term memory is information that the application has decided to keep across different conversations — for example, that the company always compares prices including VAT. In LangGraph, the state of an individual work thread is held by a checkpointer, while information shared across threads is held in a separate store whose contents are defined by the application itself (LangGraph: persistence).
• RAG is searching sources (documents, databases) and passing the retrieved fragments to the model. This is knowledge retrieval, not memory of the dialogue; for more, see the article on RAG for a company knowledge base.

An instruction in the prompt to "remember everything" does not create any storage.

4. Tools, APIs and data format validation

An API is the way one program accesses another: a search service, a CRM, a price directory. For an agent to use one, it needs credentials, request sending, response parsing and error handling — all of which are done by the application.

The model generates the call parameters and can make mistakes: omit a required field or pass a value of the wrong type. Describing the data with a schema helps here, for example using the Pydantic library for Python. Roughly (this is pseudocode, not a ready-made integration):

PriceRequest:
  supplier  — text, required
  item_code — text, required
  quantity  — whole number greater than zero
  currency  — one of: RUB, USD, CNY

If the application validates parameters before contacting the API, a request that fails schema validation is not sent, and the error is returned for correction. There are limitations, however (Pydantic: models). By default, Pydantic may convert compatible values: it will turn the string "500" into the number 500 unless strict mode is selected. Format validation says nothing about truthfulness: a correctly formatted price may be out of date or refer to a different product. Schema validation does not grant permission to act either — permissions are set separately. Finally, the library itself does not call any API.

5. Clarification, decomposition and independent verification

Clarification. The request "compare suppliers" is incomplete: is delivery included in the price, what is the order quantity, with or without VAT? A good system asks only about what actually changes the result and works out the obvious on its own.

Decomposition. A large task is broken into verifiable steps: list of suppliers → collect terms with links → bring to a common basis (unit, currency, tax) → calculation → table → draft email. Each step can be checked separately, making it possible to see exactly where an error occurred.

Verification. The model's self-critique ("check yourself") can be a useful additional pass, but it is not independent proof: the same model often repeats its own mistake. More reliable options are programmatic checks (recalculating the cost in code, reconciling totals), checking each figure against a saved source and, where it matters, verification by another party — a person or a separate system.

Recommendation: limit the number of retries. If, after one or two revisions, there is still no confirmed price for a supplier, it is more honest to put "no data, source not found" in the table than to run an endless improvement loop or let the model fill the cell with a plausible-looking figure.

6. State, checkpoints and re-execution

State is the shared workspace of the process: which suppliers have already been processed, which prices have been found, which links have been saved. A checkpointer records this state as execution proceeds, tying it to a work-thread identifier. After a failure or a pause, the process can resume from the saved point rather than start over (LangGraph: persistence).

Two details are often overlooked. Saving to working memory (an in-memory saver) is fine for experiments but does not survive the process stopping: real recovery requires durable storage and a stable thread identifier. And a checkpoint by itself does not guarantee that an action is performed exactly once. If a step has already sent an email and the failure happens before the state is saved, the email may go out again on retry.

Recommendation: make external actions idempotent, that is, safe to repeat. If a service supports an idempotency key, use it. For emails, a single "sent" log is not enough: first record the intention to send, then the receipt. If the connection drops and the outcome is unknown, do not blindly resend — recover the send status instead. Otherwise the email may have gone out before the failure even though the success mark was never saved.

7. The human in the process: where a pause is needed

Human-in-the-loop is the ability to pause a process and ask a person for information or a decision. LangGraph provides interrupts for this: the graph stops and, after the person responds, continues via a resume command using the same thread and the same checkpointer (LangGraph: interrupts). An important technical detail: on resumption, the node where the pause occurred is run from the beginning, so code placed before the pause point may be executed again. Sending an email there without protection against repetition is not acceptable.

In our example, a person is needed in two places: when there is not enough data for a material decision ("should a supplier without a confirmed delivery time be included?") and before an external action — sending the request to suppliers. There is no need to ask for approval of every search or recalculation: that turns the manager into an operator and undermines the value of automation. Pauses belong where a decision is material or requires authority: sending something outside the company, money, commitments, changing data in other organisations' systems.

8. Prompt and context

A prompt is the instruction given to the model: the goal, constraints, output format and quality criteria. A weak version: "compare the suppliers and make a good report". A stronger one specifies which suppliers, what unit of comparison, with or without VAT, a link for every figure, missing values to be marked explicitly rather than invented, and the result as a table with specified columns.

But a prompt does not replace architecture. It will not provide internet access if no search tool is connected, and it will not create memory without storage. Besides the instruction, the result is strongly influenced by the context — exactly which documents, history and tool responses are passed to the model at a given moment. Too little context and the model fills in the gaps; too much and the important parts get lost among the irrelevant.

How it all works together

An illustrative sequence for our example:

1. The manager sets the task; the system clarifies only what matters — order quantity, treatment of VAT and delivery.
2. The graph starts collecting terms; where sources are unpredictable, an agent works in an "action — observation" loop.
3. The parameters of each call go through format validation, and the figures found are saved in the state together with their links.
4. The total cost is calculated by code, not by the model's text response; the results are checked against the sources.
5. Gaps are marked as "no data"; the number of revisions is limited.
6. The graph pauses: the manager sees the table, the sources and the draft email.
7. Only after approval is the email sent — with protection against duplicate sending.

Having all the building blocks in place does not by itself make a process reliable. The model generates text and proposes actions, the application executes and checks them, and the person makes decisions at agreed control points. The value of the system lies in the work done and the manual routine removed, not in the number of components. How to choose a task for which such a setup is justified at all is covered in the article on AI agents for business.