What Do We Really Know About AI Models Today?

2022, year zero: when AI models leave the labs

2022 is not the year large language models were born, but it is the year they stopped being almost exclusively the domain of research papers, laboratories and developer APIs. On November 30, OpenAI releases ChatGPT as a research preview: a conversational interface built on a family of models already trained to follow instructions and refined through human feedback. The real novelty is therefore not a single sudden invention, but the meeting point between already mature capabilities, behavior-oriented post-training and an extremely simple way of using them: write a question and receive an answer.

It is day zero, the birth of conversational engines, no longer based on lists of results, but on direct dialogue with the individual user.

From this moment on, millions of people begin interacting directly with a machine capable not only of completing text, but of maintaining a dialogue, correcting code, summarizing, translating, explaining and adapting to the context of a conversation. This is where the public perception of artificial intelligence changes: from a specialist technology to a general-purpose interlocutor.

It is only 2022: nobody yet knows what conversational engines will really be used for, but within a few years they will begin positioning themselves as potential replacements for traditional search engines.

Before LLMs: backpropagation, Transformers and next-token prediction

To understand what language models actually do, we need to start from a point that is often misunderstood: they are not programmed by manually inserting rules, concepts and answers one by one. During training, they are exposed to enormous quantities of text and continuously try to predict what should come next. When they get it wrong, a mechanism called backpropagation measures the error and propagates it backwards through the network, progressively adjusting the model's parameters. Repeated billions of times, this process gives rise to an increasingly sophisticated network of statistical relationships between words, linguistic structures, facts and concepts.

A network of statistical relationships between words, facts and concepts about which, as we will see later, we know frighteningly little.

The decisive leap comes in 2017 with the Transformer architecture. The Transformer changes everything because its attention mechanism allows the model to evaluate which parts of a sequence are most relevant for interpreting the others, working on relationships between elements of the text far more effectively than previous architectures. Modern Large Language Models are built on this foundation.

At its core, however, the operation remains surprisingly simple: given a context, the model calculates a probability distribution over the possible next tokens fragments of words, words or symbols  and selects one. It then repeats the same operation on the new context.

-- Paris is the capital of --

France       0.94
Germany      0.02
city         0.01
Europe       0.01
...

This is where one of the great paradoxes of LLMs begins: an apparently elementary mechanism can produce behaviors that seem far less elementary. If all they do is predict the next token, how can they translate, program, solve problems, recognize analogies or construct explanations? This is precisely the question that, in the years that follow, will make it increasingly unsatisfactory to describe them simply as machines that 'guess the next word'.

The �stochastic parrot�: an important criticism that is no longer enough

In 2021 Emily Bender, Timnit Gebru and other researchers used the expression stochastic parrots to describe the risk of attributing understanding to systems that generate language by combining patterns learned from enormous quantities of text. The metaphor was effective: a model can produce plausible, even brilliant sentences without necessarily possessing the same understanding of the world that we attribute to a human being.

The point remains valid. An LLM does not automatically verify that what it is saying is true, it has no direct experience of the world and it can produce a perfectly coherent sentence even when it starts from a false premise. Fluency alone does not prove understanding. It is precisely this gap between linguistic plausibility and truth that explains many of the phenomena we have come to call hallucinations.

The problem begins when the metaphor is taken literally and turned into a complete description of how models work. Saying that an LLM simply repeats what it has seen does not adequately explain its ability to apply a rule to new examples, translate between different representations, write code it has never encountered in that exact form, construct analogies or combine information in ways that do not correspond to a simple copy of the training set. Predicting the next token is the objective of training; it does not necessarily mean that the model solves that task through a gigantic collection of memorized sentences.

To predict language well, in fact, it becomes useful to learn something about the structure that generates it. If in billions of texts Rome appears in relation to Italy, city, capital, history, geography, empire, Lazio and thousands of other concepts, the model does not necessarily store a dictionary entry called Rome. During training, it instead builds internal configurations capable of representing those relationships and reusing them in different contexts.

This does not solve the philosophical question of understanding, nor does it make an LLM equivalent to a human mind. But it moves the question into much more interesting territory: what actually forms inside a neural network when it becomes so good at predicting language?

In recent years, interpretability research has begun to give us some clues. What is emerging looks less like an archive of sentences and much more like an enormous space of features, representations and combinations of activations. A kind of internal alphabet that we did not design and that we are only beginning to decipher.

The hidden alphabet of LLMs: neurons, features and conceptual 'chords'

If models do not simply store sentences they have already seen, then where do concepts end up? The most interesting answer today comes from mechanistic interpretability research: in general, there does not appear to be a single neuron for a single concept. Models distribute information across many neurons at once, and the same neurons can contribute to different representations. This is why looking at an isolated neuron often tells us very little. In this illuminating article by Anthropic, the researchers talk about 'abstract features', but in brutally simple terms models are building an internal map of concepts. Who asked them to? Nobody, obviously. Information is finding its own way. Let us see how.

In recent years researchers have begun extracting more readable structures from these activations, called features: recurring patterns of neural activity that can correspond to relatively interpretable entities, properties or concepts. By studying Claude 3 Sonnet, Anthropic identified millions of these features: some associated with places such as the Golden Gate Bridge, others with people, chemical elements, coding errors, secrets, inner conflict and much more abstract concepts. OpenAI has conducted similar research on GPT-4, decomposing its internal representations into millions of often interpretable patterns.

An intuitive way to imagine them is as a kind of internal alphabet. But perhaps the metaphor I like most is musical. A single neuron is like a note: on its own it may mean very little. It is the combination of multiple activations that produces something recognizable. We might call these configurations 'neural chords': sets of activations that, when they recur together, contribute to representing a particular concept.

neurons
  |
activation patterns
  |
features
  |
combinations of features
  |
conceptual representations

The surprising part is that these representations do not appear to be simple linguistic labels. The same feature can activate when presented with the name of an object in different languages, with its description and even with an image representing it. In the case of the Golden Gate Bridge, for example, Anthropic observed a feature sensitive to the concept of the bridge across texts in multiple languages and images. Moreover, conceptually related features tend to be close to one another in the model's internal space: around the Golden Gate, among others, appear Alcatraz, San Francisco, the 1906 earthquake and Vertigo.

Even more importantly, these features do not appear to be merely correlations observed from the outside. Researchers have managed to artificially modify their intensity and produce coherent changes in the model's behavior. By strongly increasing the Golden Gate Bridge feature, Claude began mentioning the bridge practically everywhere, even when it had nothing to do with the question. This suggests that at least some features play a causal role in how the model processes and uses concepts.

We are still very far from having a complete dictionary of an LLM's 'mind'.

Current techniques recover only part of the representations present, they are expensive, and they still do not explain how features combine into the circuits that produce reasoning or an answer. But the picture already emerging is enough to make the stochastic-parrot metaphor far more complicated: the model does not simply store sentences; it builds internal representations that seem to organize meaning into reusable forms.

And this leads to a fundamental consequence: if part of the knowledge is embedded in the model's parameters, that does not mean all useful knowledge has to be. This is where one of the most important architectural transformations of recent years comes in: RAG, the possibility of bringing external knowledge into the model's context precisely when it is needed. RAG is an acronym and another crucial piece which, together with Transformers, has given models a major boost in their ability to absorb and access knowledge. It stands for Retrieval-Augmented Generation. Let us see what that means.

From knowledge in the weights to knowledge outside the model: the arrival of RAG

One of the most obvious limitations of large language models is that a huge part of their knowledge is embedded in their weights, the parameters learned during training. This means that a model may 'know' many things, but it cannot easily update that knowledge every time the world changes. If a piece of information was not present during training, or has since become outdated, the model does not automatically have access to the correct version.

This is where Retrieval-Augmented Generation, or RAG, comes into play. The term was formalized in 2020 by Patrick Lewis and other researchers in a paper proposing the combination of two kinds of memory: a parametric one, contained in the model, and a non-parametric one, made up of external documents retrieved at request time. The idea is simple but extremely powerful: instead of expecting the model to remember everything, we give it the relevant information precisely when it needs to answer.

without RAG

question
   |
LLM
   |
knowledge in the parameters
   |
answer

with RAG

question
   |
retrieval
   |
relevant documents
   |
context
   |
LLM
   |
answer

The transformation is more important than it may seem. With RAG we can update a document base without retraining the model, work with private or proprietary information and, at least to some extent, reconstruct where an answer came from. The original paper already highlighted how purely parametric models struggle to update their knowledge and provide verifiable provenance for information, while access to external memory makes the system more modular and inspectable.

This does not mean, however, that RAG automatically eliminates hallucinations. The system can retrieve the wrong document, misinterpret it, overlook an important passage or still generate a conclusion unsupported by the sources. The problem does not disappear: it shifts from having a single model to correctly designing a pipeline made up of retrieval, context selection and generation.

And this is precisely where the way we think about LLMs begins to change. The model gradually stops being regarded as a self-contained repository of knowledge and becomes one component of a wider system. Some information lives in its weights, while other information comes from databases, documents, APIs or search engines. The question is no longer simply:

How much does this model know?

but increasingly:

What information can it access at the moment it needs to reason?

This is one of the first decisive steps from the model as a product to the model as part of an architecture.

Training a capability does not mean deciding a behavior

At this point a fundamental distinction emerges: teaching a model to represent language is not the same thing as deciding how it should behave when someone starts using it.

Pretraining builds the general foundation. The model is exposed to enormous quantities of text and learns linguistic regularities, relationships between concepts, argumentative structures, forms of knowledge and reasoning patterns. But a pretrained model, by itself, is not necessarily a good assistant: it may complete a sentence, imitate a style or continue a dialogue, but it has not yet reliably learned that it should follow an instruction, refuse a dangerous request, acknowledge uncertainty or favor a useful response over one that is merely plausible.

This is where post-training comes into play. Once general capabilities have been built, the model is trained further in order to turn those capabilities into behavior that is more controllable and consistent with its intended use.

In simplified form:

PRETRAINING
learns language, relationships and representations

        |

INSTRUCTION TUNING
learns to follow requests and formats

        |
PREFERENCE TRAINING
learns which responses are considered better

        |
POLICY / SYSTEM INSTRUCTIONS
receives constraints, priorities and operational rules

        |
OBSERVABLE BEHAVIOR

One of the techniques that defined this phase is Reinforcement Learning from Human Feedback, or RLHF. Instead of simply showing the model correct examples, human preferences are collected between alternative responses and that signal is used to steer the model toward behavior considered more useful, relevant or safe. In the following years, variants also emerged that use feedback generated by other models, automated critiques and more structured rubrics.

This distinction matters because it separates two questions that are often confused:

What is the model capable of doing?

and

How do we want it to choose to use those capabilities?

A model may technically be capable of producing code, persuading, classifying, planning or synthesizing information. But we still need to determine when it should do so, within what limits, according to which priorities and how it should behave in ambiguous cases.

The more capable models become, the less realistic it is to describe their behavior through a simple list of prohibitions. If a system has to operate in new situations, use tools, compare conflicting objectives or make intermediate decisions, we cannot anticipate every possible circumstance in advance.

This is why the problem starts to look less like traditional programming:

if A happens ? do B

and increasingly like defining a set of principles:

when A, B and C come into conflict
? evaluate priorities, context and consequences
? choose the most coherent behavior

This is precisely the need behind one of the most interesting experiments in the recent evolution of LLMs: instead of simply telling a model what it must not do, try giving it a kind of constitution, a set of principles that can guide it even when no specific rule exists.

You may be thinking: this is madness. And yet this is exactly what is happening.

Claude's Constitution: what kind of machine do we want to build?

In January 2026 Anthropic published a new version of Claude�s Constitution, a document that de facto explicitly describes the values, priorities and behavior the company wants to incorporate into its models. It is not simply a policy intended for users: Anthropic presents it as an important part of the training process, capable of directly influencing Claude's behavior.

The idea comes from Constitutional AI, a research direction Anthropic has pursued since at least 2022-2023: instead of relying solely on human feedback across thousands of individual responses, the model is given general principles written in natural language and is also trained to critique and revise its own answers in light of those principles. In other words, part of the alignment process is shifted from a long collection of specific examples toward a more general normative framework.

The new constitution is particularly interesting because of how it is written. Anthropic explicitly says that its primary audience is Claude itself. The document therefore speaks directly to the model, using concepts we would normally reserve for people: virtue, wisdom, honesty, judgment, values. The stated goal is not to create an infinite list of instructions of the form 'if X happens, do Y', but to provide a framework general enough to allow the model to orient itself even in situations developers did not anticipate in advance.

In extremely simplified terms, the constitution establishes a hierarchy of priorities: Claude should be safe, ethical, respect Anthropic's specific guidelines and, within those constraints, be genuinely useful to the people interacting with it. But the most interesting point is not the list of values. It is the attempt to teach the model how to resolve conflicts between those values.

traditional rule

IF request = X
> response = Y

constitutional approach

principles
   |
context
   |
possible conflict between values
   |
evaluation
   |
behavior

It is a subtle but important change. The more capable a model becomes of working in open environments, using tools and making intermediate decisions, the less we can hope to anticipate every future situation with a specific rule. Its reliability will also depend on its ability to generalize principles to new circumstances.

Naturally, calling it a 'Constitution' does not mean Claude possesses an autonomous morality or that the document works like a political constitution. Anthropic itself makes clear that it does not intend the term as a rigid set of rules to be mechanically applied, but as a foundational structure intended to guide the character and behavior of the system. It is also explicitly an incomplete project: the fact that a principle is written into the constitution does not guarantee that the model will always apply it correctly.

And yet the document clearly shows how far we have come. In just a few years we have moved from asking how to make a neural network correctly complete a sentence to asking which principles that same network should use when it has to act in situations we did not anticipate.

And this is a question destined to become even more important, because in the meantime models have not simply become larger: the things we are able to ask them to do have also changed profoundly.

What has actually improved in AI models since 2022

If we look only at model rankings, the last four years look like a succession of names, versions and benchmarks. GPT, Claude, Gemini, Llama, DeepSeek and dozens of other models have rapidly alternated at the top. But this chronology risks hiding the most important transformation: it is not one single capability that has improved. The boundaries of what a model can do inside a software system have changed.

In 2022 the typical experience was still essentially this:

text
  |
model
  |
text

Today a model can receive text, images, audio and documents, maintain much larger contexts, produce structured data, use external tools, query databases and APIs, write and execute code and tackle problems made up of multiple steps. Reasoning models  here is an OpenAI page explaining how they work  in particular introduce additional computation before producing a response, allowing them to plan, compare alternatives, use tools and tackle more difficult multi-step tasks.

The main transformations can be grouped into several directions.

• More context. Context windows have grown enormously compared with the first chatbots. This makes it possible to work on repositories, document collections, long conversations and quantities of information that once required manual fragmentation. Having more space, of course, does not automatically mean knowing how to use it well: selecting and organizing context remains a design problem.

• Multimodality. The boundary between language models and other kinds of models has become increasingly blurred. Text, images, audio and video can enter the same processing flow. Retrieval is also becoming multimodal: we are no longer retrieving only passages of text, but can search for information inside images and complex documents (here, for anyone who wants to explore further, Google presents multimodal RAG).

• Longer reasoning. One of the most significant developments has been allocating more computation at inference time. Instead of immediately generating a response, some models can spend additional resources analyzing the problem, planning and checking alternative paths. This has particularly improved mathematics, coding, science and tasks made up of many steps, as mentioned earlier.

• Tool use. The model no longer needs to contain or calculate everything internally. It can decide to call a function, query a database, perform a search or invoke an external service. This is a fundamental transformation: the LLM moves from being an output generator to becoming a potential orchestrator of external capabilities.

• Structured outputs. In early LLM-based systems it was normal to ask the model to reply in JSON and hope that it respected the format. Today APIs can constrain output to precise schemas. This apparently technical detail makes models far easier to integrate into traditional software: a response is no longer only text to be read, but can become a reliable object that another function can use.

• Coding. The ability to understand, modify and produce software has grown rapidly, to the point where models can work on repositories, diagnose problems and carry out tasks involving multiple files and multiple steps. Benchmarks show very strong progress in this area, although those same benchmarks become increasingly difficult to interpret as they reach saturation.

The result is that even the meaning of the word better has become less obvious. Frontier models tend to move closer to one another across many evaluations, while factors such as cost, latency, reliability, ability to use tools and performance on the specific problem being solved become increasingly important. The Stanford AI Index 2026 reports precisely this growing convergence in the performance of leading models and, at the same time, increasing difficulty for traditional benchmarks in measuring progress that evolves so quickly.

This does not mean the fundamental problems have disappeared. Hallucinations still exist, robustness can vary enormously from one task to another, and a model that performs extremely well on a benchmark can fail surprisingly when the conditions change slightly. Even in 2026, reliability evaluations show important differences between models and tasks (this Stanford study helps explain the phenomenon).

But precisely for this reason, the most interesting progress is not simply that the model can do more things. It is that we have learned to distribute the work: memory outside the model, data retrieved at the right moment, rules expressed in code, external tools used to act, structured outputs used to communicate with other applications, and models employed mainly where interpretation, generation or reasoning are actually needed.

This is where the old problem of the perfect prompt starts to feel too small. If behavior depends on which information enters the context, which tools are available, what the system remembers and what it retrieves at the right moment, then the emerging discipline is no longer simply about writing a prompt well.

It is about designing the context in which the model will have to think and act.

From Prompt Engineering to Context Engineering

In the early years of generative AI, there was an enormous amount of discussion around prompt engineering: finding the right wording, giving precise instructions, adding examples, imposing a format, explaining to the model which role it should take on. It was an almost inevitable discipline when the typical interaction consisted of a single request followed by a single response.

But when a model becomes part of longer processes, the prompt alone is no longer enough. An agent working for minutes or hours accumulates tool results, documents, conversations, state, intermediate errors, decisions made earlier and new information retrieved during execution. The question therefore becomes much broader:

what information should the model have in front of it, at this exact moment, in order to make the best possible next decision?

This is where the concept of Context Engineering comes from. Anthropic describes it here as a natural evolution of prompt engineering (and, incidentally, credit where it is due: Anthropic/Claude documentation is outstanding, light-years more effective at transferring knowledge than Google's and OpenAI's documentation, which still tends to be too verbose and takes twice as long to work through). It is no longer simply about writing instructions well, but about designing and maintaining the entire set of information entering the context window during inference  system instructions, memory, tool results, external data, conversation history and application state.

The difference can be summarized like this:

PROMPT ENGINEERING

"How should I phrase
this instruction?"

CONTEXT ENGINEERING

"What does the model need to know right now?
What does it need to remember?
What does it need to retrieve?
Which tools should it see?
And what is better left out?"

This last point matters. More context does not necessarily mean more intelligence. Filling the model's window with everything we have available can increase cost and latency, introduce contradictory information and even reduce the quality of responses. In long-running agentic systems, people now talk about context rot: as history, files and tool outputs accumulate, the useful signal risks being buried under noise.

This is why a good system must continuously select, compress, isolate and update its context. Some information can remain in the current conversation, some can become persistent memory, some can be retrieved only when needed through RAG or APIs, while other information can be delegated to a sub-agent and returned to the main model only as a summary. LangChain summarizes these strategies through operations such as write, select, compress, isolate: deciding what to preserve, what to bring into context and what to leave out (here is LangChain's documentation on Context Engineering).

We can imagine the context of a modern model like this:

                 ||system instructions
                 || user request
                 || memory
                 || retrieved documents
                 || API results
                 || available tools
CONTEXT WINDOW |||| process state
                 || relevant examples
                 || useful history
                        |
                       LLM

The model is still the component that generates the response or makes the next decision, but what it is capable of doing increasingly depends on the quality of the context the system manages to build around it.

And this is where the journey of this article starts to become concrete: two applications can use exactly the same model and produce radically different results. One may simply send it a prompt. The other may provide updated data, memory, business rules, tools, examples, state and verification mechanisms.

The model is the same, the context is not.

The model is no longer the application

For a while, we talked about AI models almost as if they were the product itself. Use GPT, use Claude, use Gemini: the name of the model seemed sufficient to explain what an application did.

Today that equivalence works less and less.

An AI-based system can use exactly the same model as another one and behave completely differently, because what matters is not only the central engine, but how it is embedded in the overall architecture.

A modern application can include:

                     || data
                     || memory
                     || RAG
                     || business rules
user | system ||||||||| LLM
                     || APIs and tools
                     || validation
                     || guardrails
                     || evals
                     || observability

The model can interpret a request, classify an ambiguous case, generate an explanation or decide which tool to use. But many other parts of the process work better when delegated to traditional software.

What does that mean? Let us look at some concrete examples:

If the price of a product is 39.90, there is no reason to ask an LLM to remember it: we retrieve it from the database.

If a customer with status unsubscribed must not enter a campaign, that is a deterministic rule, not a decision that should be left to probability.

If we need to know whether a room is available, we query the PMS. If we need to understand the tone of a message or summarize twenty reviews, on the other hand, a language model may be the most appropriate tool.

CERTAIN DATA               | database / API

BUSINESS RULE              | code

CALCULATION                | function

UPDATED INFORMATION        | retrieval

INTERPRETATION             | LLM

SYNTHESIS                  | LLM

AMBIGUITY                  | LLM

ACTION                     | tool / API

This separation is one of the most important lessons of recent years: not everything that can be done by a model should be done by a model.

In fact, a good AI system often uses probabilistic intelligence only at the points where it is genuinely useful, surrounding it with deterministic components that make the overall behavior more stable and verifiable.

This is also why concepts such as evals, tracing and observability are becoming central.

If an application no longer produces only a response, but performs a sequence of retrieval operations, decisions, tool calls and intermediate transformations, checking only the final output is not enough. We need to be able to observe the path it followed, identify where it made a mistake and measure whether a change to the prompt, model or context actually improved the system.

Agent platforms now explicitly reflect this architecture. An agent is defined not only by a model, but by the combination of instructions, tools, guardrails, structured outputs, state and the ability to delegate to other agents. In multi-agent systems, we can also decide whether a specialized component should temporarily take control or remain behind the scenes as a capability invoked by a main agent.

This is an enormous conceptual difference.

In the original paradigm:

model - product

In the emerging paradigm:

model > cognitive component of a system

At this point, the question which is the best model? begins to lose some of its meaning. A more useful question becomes:

which model is best suited to this task, inside this architecture, with these data, these tools and these constraints?

This is where it becomes clear why, paradoxically, the more powerful models become, the less sense it makes to build everything around the name of the model.

The next step is almost inevitable. If the model can receive state, choose tools, observe the result of its own actions and decide what to do next, then we are no longer describing only a chatbot.

We are beginning to describe an agent.

From chatbots to agents: when the model enters the process

The next step is the one we are living through right now. For years we mainly used models as interlocutors: we asked a question, received an answer, perhaps adjusted the prompt and started again.

An agent introduces something different: the model no longer simply produces the final output, but can participate in the sequence of operations required to achieve a goal.

CHATBOT

user
  |
prompt
  |
LLM
  |
response

With an agent, the loop looks more like this:

AGENT

goal
   |
observe context
   |
decide next step
   |
use a tool
   |
read the result
   |
update state
   |
decide again
   |
...
   |
result

The difference is substantial. If we ask a chatbot:

What is the cheapest flight to London?

it can explain how to look for one or, if it has access to up-to-date information, suggest some possibilities.

An agent, by contrast, can receive the goal, query external services, compare options, apply constraints, ask for clarification when information is missing and continue until the task is complete or requires a human decision. The model therefore becomes a kind of local decision engine inside a workflow. This does not necessarily mean it is autonomous in a strong sense. A good agentic system can support many different levels of autonomy:

model suggests
        |
software verifies
        |
human approves
        |
system executes

or:

model decides
        |
tool executes
        |
model verifies the result
        |
continues automatically

The amount of freedom granted depends on the risk of the task. Generating a draft email does not require the same controls as a system that modifies a database, makes a payment or grants access to infrastructure.

This is why simply talking about AI agents can be misleading. Behind a reliable agent there is still traditional software, permissions, rules, validations, logs, limits and human approval points. The model may choose a direction, but the architecture determines which actions are actually available.

The role of memory also changes. A conversation can afford to forget almost everything once it ends. An agent expected to follow a process for hours, days or weeks instead needs to know what has already happened, which decisions have been made, which results have been obtained and what remains to be done.

State therefore becomes an essential part of the system:

GOAL

| initial state

ACTION 1
|
OBSERVATION

| new state

ACTION 2
|
OBSERVATION

| new state

ACTION 3
|
...

In some cases this architecture is divided even further. A main agent can delegate specific activities to specialized components: one researches information, another analyzes data, another writes code, another verifies the result. Not because we need to imitate a company populated by little digital workers, but because separating responsibilities and contexts can make a complex system easier to manage.

And here we find perhaps the most important transformation compared with 2022.

Back then, the value of a model was perceived mainly through the quality of its answer. Today we are starting to evaluate it also through its ability to:

understand a state, choose an action, use a tool, observe what happened and decide the next step.

The model is no longer necessarily the place where a process ends. It can become one of the participants that move it forward.

And it is precisely this shift  from response generator to operational participant  that brings us toward the next phase: systems made up not of a single artificial intelligence, but of models, software, data, tools and people collaborating within the same process.

Where we are heading: from the LLM to an organization of intelligences

At this point, the next step appears almost natural. If a model can use tools, maintain state, retrieve information, delegate tasks and work together with other models, then the near future of AI no longer looks like a single central intelligence that knows how to do everything.

It looks much more like a composite system.

human
   |
orchestrator
   |
|||||||||||||||||||||||||||||||||||||||||||
| data agent  | code agent  | web agent   |
|||||||||||||||||||||||||||||||||||||||||||
       |             |             |
      API         database        tools
       \             |             /
        ||||||| shared state |||||||
                    |
                  result

Agent platforms are already moving in this direction. Modern frameworks support not only tool calling, but also handoffs between agents, specialists with separate contexts, persistent state, guardrails, human review and multi-step orchestration. OpenAI, for example, explicitly distinguishes between agents that hand control to a specialist and manager agents that retain final responsibility while using other agents as tools.

This does not mean that building more agents is automatically better. On the contrary, complexity grows quickly. Every new agent introduces another context to manage, another possible source of error and another point that needs to be observed and evaluated. Documentation for multi-agent systems itself recommends separating tasks only when genuinely independent responsibilities exist or when contexts benefit from being isolated.

The crucial point is something else: we are learning to distribute intelligence.

Part of it can live in the model.
Part of it in software rules.
Part of it in the data.
Part of it in external tools.
Part of it in other specialized models.
And part of it, inevitably, in the people who define objectives, approve decisions and intervene when the system encounters a case it should not handle on its own.

We can therefore imagine the evolution of the last few years as a sequence:

LLM
|
assistant
|
assistant + retrieval
|
assistant + tools
|
agent
|
multi-agent workflow
|
human + software + AI hybrid system

This is probably where the discussion around models risks becoming misleading. We will certainly continue to compare GPT, Claude, Gemini, Llama, DeepSeek and whatever comes next. Differences between models will continue to matter. But for many real-world applications they will be only one variable in the equation.

Increasingly, the advantage will not come from having the model with the highest benchmark score, but from being better at designing:

the context it receives, the data it can access, the tools it can use, the rules that constrain it, the other components it collaborates with, and the way its behavior is observed and evaluated.

This may be the deepest change that began in 2022. We started with a window in which we wrote a sentence and waited for a machine to complete it.

We are moving toward systems in which language models, software and people share pieces of the same process.

And this is why, paradoxically, as models become increasingly important, the name of the model may matter less and less.

What will really matter is what we are able to build around it.