Start with the basics

From a chatbot to an always-on agent

Modern AI chatbots put language models inside a conversation. Stronger reasoning, retrieval, workflows, tool interfaces, agent loops, and persistent infrastructure expanded what these systems could do—from generating a reply to carrying out work across sessions.

These developments overlapped and still coexist; they were not seven clean historical eras. The levels below explain the architectural changes. For dated milestones, see the timeline.

Level 1 · Direct prompting

Language models become conversational

Language models generate responses from instructions and conversation history. A chat interface makes that capability accessible through ordinary language.

  1. Message + conversation
  2. Language model
  3. Response
Arrows show the flow of information or work.
What changed
A person can ask follow-up questions and refine an answer through conversation. The basic interaction is still a request followed by a response.
What this does not mean
The model alone cannot look up current information or act in another system. Fluent responses can still be wrong.
Add relevant information

A model’s training cannot contain every private document or stay current with every change.

Level 2 · Added context

Answers gain access to external information

Applications bring documents, search results, and stored information into the model’s context: the information available for its current response.

  1. Search or stored information
  2. Context + model
  3. Answer with evidence
Arrows show the flow of information or work.
What changed
Retrieval-augmented generation (RAG) connects search to generation. Answers can use information outside the model’s training and point back to sources.
What this does not mean
Retrieval does not retrain the model. Missing, stale, or misleading source material can still lead to a poor answer.
Organize the work into steps

A single response is useful, but repeatable processes often need several transformations and checks.

Level 3 · Workflows

Model calls become parts of software workflows

Developers connect model calls with ordinary code: fixed steps, branches, validation, and retries. Language generation becomes a component in a larger process.

  1. Input
  2. Code-directed model steps
  3. Checked output
Arrows show the flow of information or work.
What changed
Software can extract information, transform it, check it, and pass it onward. Software defines the allowed paths; model classifications can select among those paths.
What this does not mean
A workflow can be scheduled and complex without being an agent. Its routing rules remain defined by software.
Let the model request actions

Fixed workflows determine the actions in advance. Tool calling lets a model request an action based on the information it receives.

Level 4 · Tool use

Models can request actions through tools

Tool interfaces let a model produce a structured request to search, calculate, run code, or interact with another application. Software executes the request and returns the result.

  1. Model requests a tool
  2. Software executes it
  3. Result returns to model
Arrows show the flow of information or work.
What changed
The connection becomes two-way: the system can obtain new information or change external state, rather than only produce text.
What this does not mean
The model proposes the call; software controls execution, permissions, and approvals. Tool access alone does not create an autonomous loop.
Reasoning connects actions to outcomes

A tool result can reveal another question or another action. Feeding that result back makes an ongoing decision loop possible.

Across the levels · model capability

Reasoning guides the work

Tool access makes an action possible. Reasoning helps a model interpret the goal, decide which action is useful, assess the result, and change approach. That ability is central to useful agentic work.

  1. ToolsEnable actions
  2. ReasoningGuides decisions
  3. Agent loopConnects decisions, actions, and feedback
  4. PersistenceCarries work across sessions

Reasoning models strengthen this capability. They can spend additional computation working through a problem before answering or requesting a tool. This can improve planning and problem solving, with added time and cost; it does not guarantee correct decisions.

Reasoning did not begin with dedicated “thinking” modes. Earlier agents also relied on models’ reasoning abilities. A reasoning model can power a chatbot or an agent: the model’s capability and the system’s autonomy are different dimensions.

Explore reasoning at answer time →
Level 5 · Agent loops

Tool use becomes an agent loop

The system repeatedly gives the model the current goal, context, and action results. Reasoning guides its next decision: choose an action, revise the approach, or signal that the work is finished.

  1. Reason about the next action
  2. Execute through tools
  3. Observe → choose again
Repeat the loop as needed, until finished, blocked, or stopped by a limit.
What changed
Control over the next step shifts from a fully prescribed sequence toward decisions made during the run. The surrounding software still enforces limits and executes tools.
What this does not mean
Agents can repeat mistakes or stop too early. Their reliability depends on the model, available evidence, tools, checks, and stopping rules.
Optional: add specialists

Agent loops can also be coordinated: work and review can be distributed across separate contexts.

Level 6 · Teams of Agents

Agents can coordinate with other agents

Multiple agent loops exchange tasks and findings. A lead agent or coordination framework can divide work among specialists and combine their results.

  1. Coordinator
  2. Specialist agents
  3. Findings return to coordinator
Specialists can work separately and return findings; teams are an optional branch.
What changed
Separate contexts allow specialization, parallel investigation, and independent review. This extends the architecture beyond one agent’s working context.
What this does not mean
Coordination adds cost and new failure modes. Teams are optional; a single agent can also become always-on.
Add continuity across sessions

Both single agents and teams need persistence to continue beyond an individual run.

Level 7 · Always-on agents

Agent systems persist across sessions

Persistent storage, schedules, event triggers, and a continuing runtime let an agent system start or resume work without a new chat message each time.

  1. Schedule or event
  2. Load state → run agent
  3. Save state → wait
A later trigger starts another session. Saved records connect the sessions.
What changed
Saved state connects sessions. Events initiate work, the agent acts within its permissions, and progress is recorded for a later run.
What this does not mean
Always-on does not mean continuously thinking. Software starts runs and preserves records; approval policies, monitoring, and stop controls remain essential.

The evolution is in the whole system

More capable models are part of the story. The other part is the software around them: information access, action interfaces, control loops, coordination, and persistence. Together, these turn conversational output into work that can continue over time.

These capabilities can combine in different ways. Teams are optional: one agent can also keep working over time.