Inside AI Coding Agents: Models, Context, Tools, and the Agent Loop

Introduction: The AI Is Not Producing the Finished Code in One Shot

Ask a coding agent to “add an email uniqueness check to the user registration API and implement tests,” and it may spend several minutes searching files, editing code, running tests, reading a failure, and making another change.

That behavior can make it seem as if the AI understands the entire repository and operates a terminal just like a human developer. The real architecture is more modular.

User request
      ↓
Model chooses the next action
      ↓
Tool or command is executed
      ↓
Result is returned to the model
      ↓
Agent checks whether it is done
   ↙                    ↘
Continue                Stop

An AI coding agent is not a standalone AI model. It is a system that combines a model, instructions, context management, file and command tools, an execution environment, safety controls, and an iterative control loop.

The central idea is straightforward:

An AI coding agent does not generate the correct implementation in one shot. It repeatedly assesses the situation, gathers information, requests tools, observes their results, and chooses the next action.

This article does not attempt to expose a model’s private reasoning or explain Transformer mathematics. It focuses on the externally observable architecture: inputs, tool requests, execution results, and subsequent actions.

1. Chat AI Versus a Coding Agent

A conventional chat interaction mainly accepts text and returns text.

User
  ↓ Question
Model
  ↓ Answer
User

The model may generate code, but a person usually copies it into a file, runs the tests, and pastes any errors back into the conversation. A human connects the model’s answer to the development environment.

In a coding agent, the model can produce requests for operations as well as prose: search for a file, read a source file, apply a patch, or run a test command.

User
  ↓ Request
Agent
  ├─ Searches files
  ├─ Reads relevant code
  ├─ Modifies files
  ├─ Runs tests
  └─ Inspects the result

An agent is therefore better understood as a model equipped with tools and an iterative execution mechanism, not as an entirely different category of intelligence. Codex, for example, is described as a coding agent that can read, modify, and run code; its cloud tasks run in sandboxed environments loaded with the relevant repository. Introducing Codex

The decisive difference is not code generation alone. It is whether the system can turn a model’s decision into a real operation and feed the resulting evidence back into the next decision.

2. The Big Picture: Seven Parts of a Coding Agent

A coding agent can be described through seven conceptual components:

1. User request: the goal, constraints, and acceptance criteria
2. AI model: the decision engine that selects the next action from current information
3. Context: the instructions, code, history, and results currently visible to the model
4. Tool definitions: the operations the model may request, such as search, read, edit, and shell
5. Execution environment: the host, container, or sandbox that performs file operations and starts processes
6. Execution results: file contents, exit codes, test logs, and errors
7. Agent loop: the control logic that repeats decision, execution, observation, and completion checks

┌────────────────────────────┐
│ User request                                                               │
│ “Add a duplicate check”                                               │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Context                                                                       │
│ Rules, history, code, logs                                               │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ AI model                                                                      │
│ Chooses the next action                                               │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Tool call                                                                       │
│ search / read / edit / shell                                            │
└──────────────┬─────────────┘
               ↓
┌────────────────────────────┐
│ Execution result                                                           │
│ File content, test output                                               │
└──────────────┬─────────────┘
               └──── Back to the next decision

The most important distinction is between the model and the agent system. The model proposes or selects an action. The surrounding software checks permissions, starts processes, enforces timeouts, and collects results.

3. The Model: A Decision Engine for the Next Action

Given its current context, the model typically decides:

• What outcome the user expects
• What information is missing
• Which files should be investigated
• Which tool should be requested
• What code change is appropriate
• What to do after receiving a result
• Whether the task is complete

The model does not directly call operating-system file APIs or control a shell. Conceptually, it may return structured output such as:

{
  "tool": "search_files",
  "arguments": {
    "query": "createUser"
  }
}

The agent program parses that output, validates the tool name and arguments, performs the search, and returns the result to the model as another message or tool result.

Model output is probabilistic, so two runs can explore files in a different order or choose different implementation approaches. A model may also form a hypothesis and continue despite incomplete information. Even a highly capable model can generate plausible but incorrect code when it has only seen an obsolete file or has not received an important project constraint.

It is therefore more accurate to view the model as “a decision engine selecting the next operation from the information currently available” than as “a brain that knows the whole repository.”

4. Context: The Agent’s Current Working Set

Context is the information included in the model input at a particular step. It commonly contains:

• System-level rules
• The user request and conversation history
• Repository-specific instruction files
• A plan created by the agent
• Source code that has been read
• File-name and text-search results
• Git history or diffs
• Command output and error output
• Test, build, lint, and type-check results

┌ System instructions
├ User request
├ Project rules
├ Code already read
├ Search results
├ Command results
├ Test results
└ Recent work history
          ↓
       AI model

The amount of information a model can examine at once—its context window—is finite. Sending every file from a large repository on every step would be impractical. An agent normally narrows the repository through directory inspection or search, then loads the files or sections that appear relevant.

Entire repository
       ↓ Search and filtering
Potentially relevant files
       ↓ Read selected content
Model context

For our registration API task, the agent might find the route or handler first, then follow references to a service, repository, error mapper, and existing tests. It does not begin with a perfect mental model of the codebase. It constructs a local map from search results and the files it chooses to read.

When this exploration fails, the agent may duplicate an existing helper, miss tests in another directory, or ignore a repository-specific naming rule. If a README disagrees with the implementation and the model reads only the README, it may proceed from an obsolete assumption.

This is why model limitations and context limitations should be diagnosed separately. If the correct information never entered the context, even a strong model will struggle to make the correct decision. If all necessary evidence was present but the relationship was misunderstood, the failure is more likely in reasoning or result interpretation.

5. Tool Calling: Connecting Generated Decisions to Real Operations

Tools connect the model’s decisions to operations outside the model. Common categories include:

• Read tools: list files, search text, read files, inspect Git diffs
• Write tools: create files, edit sections, apply patches, delete files
• Execution tools: shell commands, tests, builds, linters, formatters, type checkers
• External tools: GitHub, browsers, databases, internal APIs, and MCP servers

The model is given information about the available tools, including their names, descriptions, and expected inputs.

{
  "name": "read_file",
  "description": "Read the contents of a specified file",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string"
      }
    },
    "required": ["path"]
  }
}

Using these definitions, the model chooses whether to answer the user or request a tool. The key point behind Function Calling or tool use is that the model does not execute the function itself. It returns structured data expressing an intent to call a particular tool with particular arguments.

AI model
“I want read_file called with this path”
        ↓
Agent program
- Validates the input
- Checks permissions
        ↓
Actual tool
        ↓
Result or error
        ↓
AI model

MCP follows a similar separation: tools have names, descriptions, and input schemas, while a client sends a tools/call request and receives a result. MCP Tools specification

MCP is not itself an agent loop. It is a protocol for exposing external information and actions in a common form. The host application still decides which tools to expose, whether calls require approval, and how results are added to the model’s next input.

6. Command Execution: Why It Looks Like the AI Uses a Terminal

Suppose the model returns this tool request:

{
  "tool": "shell",
  "arguments": {
    "command": "npm test"
  }
}

The agent program—not the model—passes that command to an actual shell.

AI model
“I want to run npm test”
        ↓
Agent program
- Validates arguments
- Checks permissions
        ↓
Execution environment
npm test
        ↓
Exit code and logs
        ↓
AI model
“Investigate the failure”

The returned observation can include the command, exit code, standard output, standard error, timeout status, and permission errors. Some products also attach execution duration or information about changed files.

Consider this result:

FAIL src/services/user.test.ts
Expected status: 409
Received status: 500

The model may form a hypothesis that the duplicate-email exception is not being mapped to HTTP 409, then search for the error handler. But that is still an inference from the observation. A database connection failure or conflicting test fixture could be the actual cause, and a short log might lead the model to change unrelated exception code.

Executing a command and interpreting its result correctly are separate achievements. Reliable work may require the full error, exit status, related logs, and a reproducible rerun.

7. The Feedback Loop: What Makes the System Agentic

The defining behavior of a coding agent is iteration rather than one-shot generation.

Decide
  ↓
Act
  ↓
Observe the result
  ↓
Update the situation
  ↓
Choose the next action

From the controller’s perspective, the loop can be sketched as:

while not finished:
    context = collect_current_context()
    action = model.decide(context, available_tools)

    if action is a tool call:
        result = execute_with_policy(action)
        append_result_to_context(result)
    else:
        return action.final_response

For “add an email uniqueness check to the registration API and implement tests,” one possible action sequence is:

1. Inspect the directory structure
2. Search for the registration path
3. Read UserService
4. Read UserRepository
5. Find the existing exception pattern
6. Inspect existing tests
7. Implement the check and error mapping
8. Add tests
9. Run the relevant test suite
10. Read the failure output
11. Correct the suspected cause
12. Run the tests again
13. Run the linter or type checker
14. Inspect the Git diff
15. Report changes and verification results

Each observation can change the next action. If findByEmail already exists, the agent may reuse it. If the project has a standard conflict exception, it may avoid creating another one. If the test returns 500 instead of 409, the error-mapping layer becomes another investigation target.

A loop, however, does not guarantee verification. If the model decides that editing the file is sufficient, it may stop without running tests. Its behavior depends on system instructions, available tools, time or step limits, and the acceptance criteria provided by the user.

Completion conditions may include a successful implementation, passing tests, and an inspected diff. They can also include permission failure, missing dependencies, a decision that requires the user, a timeout, or a maximum-step limit. A useful agent needs the ability to keep making progress, verify its work, finish, and stop safely when it cannot continue.

8. Why Coding Agents Go Wrong

Instead of reducing every failure to “the AI is not smart enough,” locate the failure within the loop.

The request or completion condition was ambiguous

“Fix this API” does not specify the expected behavior or scope. The agent must invent a provisional goal, which may not match the user’s intent.

The agent did not discover the required files

Weak search terms or a narrow exploration path can hide shared helpers, repository rules, or integration tests. This is an exploration failure that happens before code generation.

Important information dropped out of context

During a long task, older code and logs may be summarized or omitted, while early constraints become less prominent. The agent may then make a change that was originally prohibited.

The agent misinterpreted a tool result

The location where a test fails is not always the root cause. Acting on the first stack trace can lead to an unrelated modification.

Verification was skipped

Plausible-looking code is not evidence of completion. Without a test, build, type check, or diff review, the loop has not observed whether the change works.

The environment or permissions were insufficient

The agent may lack network access, environment variables, a running database, installed dependencies, or write permissions. A report must distinguish “not verified” from “verified successfully.”

9. Safety: The Risk of Letting an Agent Run Commands

The ability to edit files and execute commands is both the agent’s strength and its risk. A mistaken decision or hostile input could delete files, read secrets, leak credentials into logs, make unintended network calls, add dependencies, or touch production resources.

Safety should not depend solely on the model exercising good judgment. The surrounding system should enforce controls such as:

• Sandboxed or read-only execution
• Restricted writable directories
• Disabled or allowlisted network access
• Approval before sensitive actions
• A minimal set of tools and credentials
• Timeouts and execution limits
• Git diffs, logs, and audit records
• Separation of production credentials from development environments

OpenAI’s material on operating Codex describes the same division of responsibility: the sandbox defines boundaries such as writable paths and network access, while approval policy determines when an action crossing those boundaries must stop for review. Running Codex safely at OpenAI

The principle is not to trust a capable model unconditionally. It is to design permissions so that the impact of a failure remains limited. The MCP tool specification likewise recommends clear indications of tool invocation and a human-in-the-loop mechanism that can deny calls. MCP Tools specification

10. What Users Should Provide and Verify

A useful instruction is not necessarily long. It contains the information required for exploration and completion: the goal, scope, constraints, design expectations, acceptance criteria, and required checks.

A weak request looks like this:

Fix this API.

A stronger request makes the expected behavior and verification steps explicit:

Add an email uniqueness check to the user registration API.

Reuse the existing Repository and exception-handling patterns.
Return HTTP 409 when the email is already registered.

Add the relevant unit tests, then run the tests and linter.
Do not change the database schema.

Finally, report the files changed, the checks performed,
and any remaining unverified items with their reasons.

Large tasks are easier to supervise when separated into investigation, implementation, and verification. For a sensitive change, you can ask the agent to report its proposed approach and target files before authorizing edits.

When the agent finishes, inspect at least the diff, executed commands, passing tests, and omitted checks. “Tests were added” does not mean “tests passed,” and even “tests passed” does not always mean “the requirement was satisfied.” Human review still needs to examine boundaries the agent may not have observed, including security, data migration, operational impact, and the correspondence between the requirement and the final diff.

11. Conclusion: A Coding Agent Is an Iterative Development System

In an AI coding agent, the model selects the next action from the user’s intent and the current context. The agent program executes a tool or command and returns the result. The model then uses that observation to decide whether to search, edit, verify, or finish.

This decide–act–observe loop enables multi-step development work. Reliability depends not only on model capability, but also on whether the right code entered the context, whether suitable tools were available, whether results were interpreted correctly, and whether completion criteria were explicit.

As operational capability increases, sandboxing, least privilege, approvals, and diff review become more important.

To use an AI coding agent well, treat it not as magical automation, but as a development system in which models, context, tools, and execution results continuously feed into one another.