What Are AI Agents

Understanding the mechanical reality of AI agents gives you the mental model to use them effectively — and to know exactly when they will fail you.

What Is an LLM, Really?

A Large Language Model is a function. It takes a sequence of text tokens as input and returns a probability distribution over what token should come next. That is the entirety of what happens at the mathematical level. Everything you experience — coherent reasoning, code generation, step-by-step debugging — emerges from repeating that single next-token prediction millions of times, trained on hundreds of billions of tokens of human-written text and code.

What makes modern LLMs useful for engineering work is not magic; it is pattern recognition at massive scale. The model has seen enough Python, TypeScript, SQL, and prose that it has internalized the statistical relationships between concepts, syntax, and intent. When you describe a bug and ask for a diagnosis, the model is pattern-matching your description against similar patterns in its training data and generating the most probable continuation — which happens to look like a reasoned answer.

Two things follow from this that every engineer should internalize. First, LLMs are not deterministic oracles; they are probabilistic text generators. The same prompt can produce different outputs across runs. Second, LLMs have no persistent memory between conversations by default. Each new session starts with a blank context window. Anything the model needs to know — your codebase, your constraints, your previous decisions — must be explicitly placed into that window.

Learning tip: Think of an LLM the way you think of a very well-read contractor who has just joined your team. They know general patterns and best practices deeply, but they know nothing specific about your project unless you tell them. Your job is to brief them well.

What Does "Tool Use" Mean in Practice?

Raw text generation is powerful but limited. An LLM that can only produce text cannot run your tests, read your files, search your documentation, or call your APIs. Tool use is the mechanism that connects an LLM's reasoning to real-world actions.

Here is how it works mechanically. The model is given a list of available tools — each described as a function with a name, a description, and a parameter schema. When the model determines that answering a request requires external information or action, it does not generate a prose response; instead it generates a structured tool call specifying which function to invoke and with what arguments. The host application intercepts that output, executes the actual function, and feeds the result back into the model's context. The model then continues generating, now with the tool result as additional context.

From your perspective as a developer using Claude Code or Cursor, you see this as "the agent reads your file" or "the agent runs your tests." Under the hood, the agent emitted a read_file tool call, your editor executed it, returned the file contents, and the model continued reasoning with that content now in context. Common tools in development environments include file read/write, shell command execution, web search, code execution sandboxes, and API calls to external services.

The practical implication is that tool use is not unlimited. Every tool call adds latency and consumes context tokens. An agent operating in a large repository that naively reads every file it might need will exhaust its context window or hit rate limits before solving your problem. Understanding this helps you guide agents more efficiently — point them at the right files, limit the scope of searches, and break large tasks into stages.

Learning tip: When an agent's response seems wrong or incomplete, the first place to look is what the agent actually read. Most tools log their calls. Checking which files the agent accessed will often immediately explain why it gave the answer it did.

What Is an Autonomous Loop?

A single exchange — you send a message, the model responds — is called inference. An autonomous loop, or agentic loop, is what happens when that single exchange is extended into a cycle: the model reasons, takes an action via tool use, observes the result, reasons again, takes another action, and continues until it reaches a stopping condition.

The canonical structure looks like this:

1. Receive task — A human (or another system) provides an objective.
2. Plan — The model decomposes the objective into sub-steps.
3. Act — The model emits a tool call to execute the next step.
4. Observe — The tool result is returned to the model's context.
5. Reason — The model evaluates whether the objective is met or what to do next.
6. Repeat steps 3–5 until the stopping condition is reached.
7. Return result — The model surfaces the final output to the caller.

This loop is what separates an "AI chat assistant" from an "AI agent." The agent can pursue multi-step goals without a human in the loop for each individual step. It can write a function, run the tests, read the failure output, fix the function, and re-run the tests — all without you pressing a button between steps.

The failure modes are just as important to understand. Agents can get stuck in loops, confidently making the wrong fix over and over. They can drift from the original objective as context accumulates. They can take destructive actions — deleting files, making API calls — if their tools are not scoped carefully. This is not a reason to avoid agents; it is a reason to understand their mechanics before deploying them on work that matters.

Learning tip: When starting out with autonomous loops, set explicit stopping conditions in your instructions: "Stop and show me the changes before committing anything." This keeps you in control while you learn how the agent behaves in your specific environment.

Why This Changes Day-to-Day Engineering Work

The shift from "AI autocomplete" to "AI agent" is not incremental — it is a qualitative change in how you structure your work. Autocomplete saves seconds. Agents can save hours, but only if you learn to communicate objectives rather than keystrokes.

Consider a concrete example. Without agents, adding a new API endpoint requires you to: find the router file, write the handler, write the validation schema, write the service method, wire up the dependency injection, write unit tests, update the OpenAPI spec, and update the changelog. Each step requires you to navigate, context-switch, and type. With an agent, you describe the endpoint's behavior once — its inputs, outputs, business rules, and error cases — and the agent executes all of those steps as a single delegated task.

This shifts the engineer's role from executor to specifier and reviewer. The most valuable skill becomes writing clear, precise, verifiable objectives — not typing code quickly. Engineers who understand what agents can and cannot do will write better objectives, catch agent errors faster, and know when to take back the wheel.

The engineers who struggle with agentic tools are usually those who either trust agents too blindly (shipping code they have not read) or use them too narrowly (accepting only single-line completions). The productive middle ground is understanding the loop well enough to direct it.

Learning tip: Track which tasks you hand to agents and which you keep for yourself. Over the first two weeks of using agentic tools, you will develop an intuition for the boundary. Write it down — it becomes the basis for teaching others on your team.

Hands-On: Exploring the Agentic Loop in Your Own Environment

This exercise walks you through observing the agentic loop in action using Claude Code (or any agent-capable IDE). You are not building a feature — you are watching the mechanics so you can reason about them later.

Prerequisites: Claude Code installed and authenticated, or Cursor / Windsurf with an agent-capable model configured. A local code repository of any kind.

Step 1: Start a session and give the agent a multi-step investigation task.

Open a new Claude Code session in your repository. Give it a task that requires reading multiple files — not writing any code yet.

Look at this repository and tell me:
1. What is the main entry point of the application?
2. What are the top 3 most-imported internal modules?
3. Are there any circular dependencies between them?

Do not write or change any files. Just investigate and report.

Expected result: The agent emits multiple file read tool calls. You will see it navigate the directory structure, read package.json or equivalent, follow imports, and synthesize a report. Watch the tool calls — this is the loop in action.

Step 2: Observe how the agent uses tools to gather context.

After the agent responds, ask it to explain its reasoning process.

Walk me through the tool calls you just made, in order. For each one, tell me: what you were trying to find out, what tool you used, and what the result told you.

Expected result: The agent produces a step-by-step account of its own reasoning. This makes the invisible loop visible. Pay attention to which files it chose to read and which it skipped — this reveals how it prioritizes context.

Step 3: Introduce a tool boundary — constrain what the agent can access.

Now deliberately limit the agent's context to test how it handles incomplete information.

Without reading any additional files, and relying only on what you already know from this session: what is the database layer of this application using, and how confident are you?

Expected result: The agent should express uncertainty if it has not read the database configuration files. If it confidently gives a wrong answer, that is a valuable observation — the model is pattern-matching from partial evidence. This is a direct demonstration of why tool access and context scope matter.

Step 4: Give the agent a write task and observe the loop with side effects.

Now give it a small, reversible write task so you can watch the full loop including file modification.

Create a new file called `AGENTS.md` in the root of this repository. It should contain:
- A one-paragraph summary of what this codebase does, based only on what you have already read in this session.
- A section called "Good tasks for AI agents" with 3 bullet points listing tasks in this specific codebase that would be well-suited for agent delegation.
- A section called "Tasks requiring human judgment" with 3 bullet points for tasks that should stay human-led.

After creating the file, show me its contents.

Expected result: The agent emits a file write tool call, then a file read tool call to verify the output, then returns the content. You now have a complete observe-act-verify loop on record.

Step 5: Introduce an error and watch the agent recover.

Edit AGENTS.md to introduce a deliberate formatting error (e.g., remove a required section heading), then ask the agent to validate it.

Read the AGENTS.md file I have and verify that it matches this structure:
- One-paragraph summary section
- "Good tasks for AI agents" section with at least 3 bullets
- "Tasks requiring human judgment" section with at least 3 bullets

If anything is missing or malformed, fix it.

Expected result: The agent reads the file, identifies the discrepancy, and issues a write tool call with the corrected content. This is the error-recovery pattern that makes autonomous loops powerful — and also the pattern that can go wrong when the agent misdiagnoses the problem.

Step 6: Clean up and reflect.

Delete AGENTS.md and end the session. Before you close it, ask the agent one last question.

In this session, how many total tool calls did you make, and what types were they? What would have happened if your file-write tool had been disabled?

Expected result: A summary of tool usage and a concrete description of how the agent's behavior would degrade without write access. This cements the mental model: agents are reasoning engines plus tool access. Remove the tools and you are back to autocomplete.

Key Takeaways

• An LLM is a next-token predictor trained at scale — its "reasoning" is sophisticated pattern matching, not symbolic logic. Knowing this tells you when to trust it and when to verify.
• Tool use is the bridge between language model outputs and real-world actions. Every file read, shell command, and API call in an agentic session is a discrete tool call that the model requested.
• An autonomous loop is an act-observe-reason cycle. The agent pursues a goal across multiple steps without requiring human input at each step — but it does require a clear stopping condition and scoped tool access to behave safely.
• The engineer's job shifts from executor to specifier. Writing a precise, verifiable objective is more valuable than typing fast. Agents amplify the quality of your instructions, not the quantity.
• Understanding the failure modes — context drift, overconfident pattern matching, destructive tool calls — is not optional. It is the foundation of using agents safely in a production engineering environment.