From Language Model to AI Agent: How Agentic Systems Actually Work

Meet Ari.

Ari is articulate, fast, and surprisingly capable. Ask for an explanation of a difficult idea and Ari can produce one. Ask for code and Ari can write it. Give Ari a document and Ari can summarize it.

But the first version of Ari has an important limitation: Ari can only respond with generated output. Ari cannot inspect your repository, open a browser, run a test, update a database, or determine whether the proposed solution actually works.

Ari has something like a brain, but no hands, senses, workplace, or practiced routine.

This is the gap between a generative model and an AI agent.

In this article, we will build Ari one layer at a time. We will begin with the model, add prompts and context, connect tools, create an execution loop, introduce memory and state, add reusable workflows, establish persistent guidance, and finally place the complete agent inside a configured and guarded environment.

We will then examine OpenAI Codex as one concrete implementation of these general ideas. Codex is not the definition of an AI agent; it is a useful case study because many of its architectural layers are visible through files such as config.toml, AGENTS.md, and SKILL.md.

Ari is a teaching device, not a claim that software thinks or experiences the world like a person. Underneath the story is a system that processes context, generates outputs, selects actions, receives observations, and continues until it reaches a stopping condition.

A short history: from intelligence to agency

The idea of an intelligent machine is much older than large language models.

In the summer of 1956, researchers gathered for the Dartmouth Summer Research Project on Artificial Intelligence. That workshop helped establish artificial intelligence as a field and popularized its name. Early AI research focused heavily on symbolic reasoning: humans represented facts and rules explicitly, and software manipulated those representations.

From the 1960s through the 1980s, expert systems showed that computers could perform useful domain-specific reasoning when supplied with carefully designed knowledge bases. These systems could be powerful, but their intelligence was narrow and expensive to maintain. Every rule had to be anticipated and encoded.

During the 1990s, research on intelligent agents increasingly described software in terms of perception and action. An agent was not merely a program that calculated an answer. It existed in an environment, observed part of that environment, and took actions in pursuit of goals.

Modern generative agents emerged from a different technical path:

• On June 12, 2017, the paper Attention Is All You Need introduced the Transformer architecture that became foundational to modern large language models.
• On May 28, 2020, Language Models are Few-Shot Learners described GPT-3 and demonstrated that a large model could perform many tasks from natural-language instructions and examples without task-specific retraining.
• On October 6, 2022, the ReAct paper described a method for interleaving reasoning and actions, helping clarify how language models could interact with external environments instead of producing only a final answer.
• On February 9, 2023, Toolformer explored how a language model could learn when and how to call external tools.
• During 2023 and 2024, function calling, agent frameworks, retrieval systems, multimodal models, and tool integrations made agentic applications practical for far more developers.

These milestones did not produce one universally accepted agent architecture. They did, however, converge on an important idea: a capable model becomes more useful when it can work inside a loop, maintain state, and interact with an environment through controlled actions.

Stage 1 - Ari gets a brain (Model)

Architecture keyword: Model - The generative and reasoning engine that interprets context and proposes outputs or actions.

The model is the core generative and reasoning component of an agent.

It receives input as context and predicts an appropriate continuation. Modern models can follow instructions, transform information, plan, classify, explain, and generate code because their training exposes them to rich patterns across language and other data.

That capability can look like general intelligence, but the model has strict boundaries.

By itself, the model usually cannot:

• Know the current contents of a private repository.
• Discover whether a production service is healthy.
• Execute the code it just wrote.
• Access a calendar, database, or CMS.
• Confirm that an external fact is still current.
• Preserve arbitrary information across independent sessions.
• Change the world outside its generated response.

The model is therefore the agent's decision engine, not the complete agent.

A useful first distinction is:

A model generates outputs from context. An agent uses a model as part of a system that can pursue goals through actions.

Stage 2 - Ari receives a task (Prompt and Context)

Architecture keyword: Prompt and Context - The immediate goal and the information currently available to the model.

A brain without a goal has no work to perform. Ari needs a request and enough context to interpret it.

The immediate user prompt might say:

Find the cause of the checkout error, fix it, run the relevant tests, and explain what changed.

That prompt supplies the current objective. Additional context may include conversation history, repository files, system instructions, retrieved documents, screenshots, tool descriptions, or results from earlier actions.

This gives us three different concepts:

• Prompt: the immediate instruction or question.
• Context: the information currently available to the model.
• State: the accumulated condition of the task, including observations, decisions, modified files, and tool results.

People often treat these as interchangeable, but they solve different problems. The prompt tells Ari what is wanted. Context helps Ari understand the situation. State lets Ari connect one step to the next.

Even with a clear prompt, however, Ari can still only describe a possible fix. Ari needs a way to observe and affect the environment.

Stage 3 - Ari gets hands and senses (Tools)

Architecture keyword: Tools - Controlled capabilities that let the agent observe or change systems outside the model.

Tools connect the model to capabilities outside text generation.

A tool is a defined operation the agent can request. Depending on the system, tools may allow Ari to:

• Read, search, create, or edit files.
• Run terminal commands and tests.
• Query databases and APIs.
• Browse websites and inspect rendered interfaces.
• Search a knowledge base.
• Send messages or create tickets.
• Update a CMS.
• Generate or analyze images.
• Interact with connected services through the Model Context Protocol (MCP).

Tools act like Ari's hands and senses. File search lets Ari see the repository. A terminal lets Ari operate development tools. A browser lets Ari inspect the result. An API connection lets Ari communicate with another system.

But a tool does not decide when it should be used. It only exposes a capability and an interface.

For example, an updatePost tool might accept a document ID and a payload. It does not inherently know that Ari should first check whether the post exists, validate the locale, upload media, preserve authorship, or verify the published result.

This gives us another essential distinction:

Tools define what the agent can do. They do not automatically define how the agent should do it well.

Stage 4 - Ari develops a heartbeat (Agent Loop)

Architecture keyword: Agent Loop - The repeating cycle of understanding, observing, acting, evaluating results, and adapting.

Once Ari can observe and act, the system needs an execution loop.

A simplified agent loop looks like this:

Understand the goal
        | 
Inspect the environment
        |
Choose the next action
        |
Use a tool
        |
Observe the result
        |
Update the working state
        |
Verify progress or adjust the approach
        |
Stop when the goal is satisfied or genuinely blocked

This loop is what turns isolated tool calls into goal-directed work.

Suppose Ari is asked to fix a broken website form. Ari might:

1. Search for the form implementation.
2. Read the validation and submission code.
3. Reproduce the failure in a browser or test.
4. Form a hypothesis.
5. Edit the relevant file.
6. Run focused tests.
7. Observe a new error.
8. Revise the implementation.
9. Run the tests again.
10. Inspect the final behavior and report the result.

The value does not come from any single action. It comes from the feedback between actions.

An agent that cannot observe its own results is closer to a macro generator than a reliable autonomous system.

Stage 5 - Ari gets a notebook (Memory and State)

Architecture keyword: Memory and State - The working and durable information that connects actions and preserves useful continuity.

As tasks become longer, Ari needs continuity.

There are several forms of memory in agentic systems:

Working context

Working context contains the information available during the current model call: the request, relevant instructions, selected files, recent tool results, and conversation history.

Context is limited. Agent systems must decide what to include, summarize, retrieve, or discard.

Task state

Task state records what has happened during the current job. It may include a plan, completed steps, identifiers returned by APIs, changed files, failures, or pending approvals.

State helps the agent avoid repeating work and enables recovery after interruption.

Durable memory

Durable memory persists beyond the current task. It may record stable user preferences, project facts, recurring decisions, or lessons from previous work.

Durable memory is useful, but dangerous when treated as unquestionable truth. It can become stale, conflict with current instructions, or accidentally preserve sensitive data. Good agent systems define what may be remembered, how it is retrieved, and when current evidence overrides it.

The important lesson is that memory is not simply "more context." It is a lifecycle for selecting, preserving, retrieving, and updating information.

Stage 6 - Ari's tools create chaos (Reliability Gap)

Architecture keyword: Reliability Gap - The inconsistency that appears when an agent has capabilities but no dependable procedure.

At this point Ari appears powerful. Ari can reason, use tools, maintain state, and repeat actions.

But power exposes a new problem: inconsistency.

Imagine asking Ari to create a CMS administrator. The system has all the required API tools. Without a reliable procedure, Ari might:

• Use the public-user authentication endpoint instead of the admin endpoint.
• Create a user before validating the password.
• Assign the wrong role.
• Forget to activate the account.
• Fail to verify login.
• Leave an inactive invitation record after an error.
• Print a password or token in the final response.

The model might solve the task correctly once and differently the next time. A long prompt could improve behavior, but repeating the entire procedure in every request is inefficient and fragile.

Ari needs practiced technique.

Stage 7 - Ari receives a playbook (Skills and Workflows)

Architecture keyword: Skills and Workflows - Reusable procedural knowledge for completing recognizable tasks safely and consistently.

A reusable workflow packages the procedure for a recognizable kind of task.

Different agent platforms use different terms: workflow, capability, recipe, procedure, plugin, or skill. The underlying idea is the same. Instead of making the model reinvent a process, we provide structured instructions and supporting resources that explain how to perform it reliably.

A good skill can define:

• The user intent that should activate it.
• Preconditions and validation.
• Which tools to use.
• The order of operations.
• Required safety checks.
• Failure handling and rollback.
• Verification and acceptance criteria.
• The shape of the final response.
• References, templates, or scripts needed by the workflow.

Now Ari does not merely know that an admin API exists. Ari knows how to use it as part of a complete account-creation procedure.

The boundary is important:

A tool supplies an action. A skill supplies procedural knowledge around actions.

A skill also does not necessarily grant access. If Ari has a publishing skill but no authenticated CMS tool, the procedure exists but the capability does not. Conversely, if Ari has powerful CMS tools but no publishing workflow, the capability exists without reliable technique.

Stage 8 - Ari joins a workplace (Persistent Guidance)

Architecture keyword: Persistent Guidance - Durable expectations that shape how the agent behaves within a user, team, or repository scope.

Skills explain how to complete particular jobs. Ari still needs to understand the environment in which those jobs occur.

Every workplace has persistent expectations:

• Which package manager should be used?
• What tests are required?
• Where should new files live?
• Which directories are read-only?
• How should secrets be handled?
• What content architecture does the website follow?
• When must a human approve the result?
• Which specialized workflow applies to this repository?

These are not instructions for one immediate task. They are durable rules that should influence many tasks.

This is the role of persistent guidance.

Persistent guidance should usually be scoped. Personal preferences may apply everywhere. Repository rules apply to one project. A subsystem may require more specific instructions than the rest of the repository.

Conceptually, the chain looks like this:

Personal defaults
      |
Organization or machine policy
      |
Repository guidance
      |
Directory or subsystem guidance
      |
The current user request

More local guidance specializes broader guidance, while higher-authority safety and platform rules continue to apply.

The difference between guidance and skills is subtle but useful:

Persistent guidance explains how Ari should behave in this environment. Skills explain how Ari should perform a recognizable workflow.

Stage 9 - Ari encounters locked doors (Guardrails and Permissions)

Architecture keyword: Guardrails and Permissions - Behavioral and enforced boundaries that control access, risk, approvals, and destructive actions.

An agent capable of real work can also cause real damage.

A reliable architecture therefore needs guardrails around actions:

• Authentication: Who is Ari acting as?
• Authorization: What may that identity access or change?
• Sandboxing: Which files, commands, networks, or system resources are isolated?
• Approvals: Which actions require human confirmation?
• Least privilege: Does the agent have only the access required for this task?
• Validation: Are targets resolved before destructive operations?
• Rollback: Can incomplete changes be safely undone?
• Auditability: Can people understand what the agent attempted and changed?

Guardrails should not rely entirely on the model remembering to behave safely. Strong systems enforce boundaries in the runtime, tools, credentials, and external services.

For example, a skill can instruct Ari never to delete a production record without confirmation. A role-scoped CMS token provides a second boundary by preventing unauthorized deletion even if the instruction is misunderstood.

Instructions guide behavior. Enforcement limits capability. Mature agent systems need both.

Stage 10 - Ari gets a control room (Runtime Configuration)

Architecture keyword: Runtime Configuration - The operating setup that selects models, tools, integrations, policies, and execution constraints.

The final layer is the operating environment.

The runtime configuration determines how the pieces are assembled. It may select:

• The model and reasoning settings.
• Available tools and integrations.
• MCP servers.
• Sandbox and approval modes.
• Network access.
• Hooks around commands or lifecycle events.
• Logging and observability.
• Skill availability.
• Project-specific overrides.
• Authentication providers and credential sources.

Configuration is different from guidance.

If a rule says, "Ask before running a destructive database migration," that is behavioral guidance. If the environment technically blocks the command until a human approves it, that is runtime enforcement.

If a skill says, "Use the company issue tracker during incident response," configuration is what connects the issue-tracker tool and supplies the appropriate authentication path.

Configuration prepares the environment. Guidance shapes behavior. Skills provide procedure. Tools provide capability. The agent loop coordinates the work.

The simplest mental model

If you remember only one section, remember this:

Model
  Interprets context and proposes outputs or actions

Prompt and context
  Define the current goal and available information

Tools
  Let the agent observe or change external systems

Agent loop
  Coordinates actions, observations, adaptation, and verification

Memory and state
  Preserve continuity within and across tasks

Skills and workflows
  Provide reliable procedures for repeatable jobs

Persistent guidance
  Defines how the agent should behave in an environment

Configuration and guardrails
  Determine what is connected, allowed, blocked, or approval-gated

Continue with Codex

Codex provides a concrete implementation of several layers in this mental model. Its practical customization deserves a focused treatment rather than an oversized section inside this general introduction.

Continue with How Codex Works: MCP Tools, Skills, and AGENTS.md.

The companion article explains:

• How MCP tools connect Codex to external systems and controlled actions.
• How global and repository-local skills package reusable workflows.
• How global, repository, and nested AGENTS.md files create scoped working guidance.
• How the three layers cooperate during a real task.

Final thought

An AI agent is not simply a chatbot with a few API calls attached.

It is a system in which a model operates inside an environment, receives goals and context, selects controlled actions, observes their results, maintains task state, follows reusable procedures, respects persistent guidance, and continues until the work is complete or safely blocked.

Ari began with only a brain. Tools supplied hands and senses. The agent loop supplied a heartbeat. State and memory supplied continuity. Skills supplied practiced technique. Persistent guidance supplied workplace understanding. Configuration and guardrails supplied a safe operating environment.

That layered architecture is what turns generated answers into reviewable work.