Deep Read, agents

What An AI Agent Actually Is

A model in a loop with tools, memory, and a goal. Here is what works, what breaks, and how to use one without getting hurt.

The Curio Team · 13 min readWritten with AI from the sources below and checked against them before publishing.

Let's start plainly. An AI agent is not magic, and it is not a colleague. Strip the marketing away and you find one specific machine underneath: a language model running inside a loop, calling tools, holding some memory, and pushing toward a goal you handed it. That is the whole thing. Anthropic draws the line between a fixed workflow and an agent by asking who is in charge of the steps, and in an agent the model itself decides what to do next and which tools to reach for. We like that definition because it is honest. The hype has gotten loud enough that people buy the promise and quietly inherit every failure mode attached to it.¹

The pattern is older than the current wave. Researchers described it in 2022 as reasoning and acting together: the model thinks a little, takes an action, reads what came back, and thinks again. That loop is the beating heart of every agent shipping today, whether the label on the box says copilot, assistant, or autonomous worker. Nothing about it requires you to trust the machine. It requires you to design the loop.⁵

What an agent actually is

Pull an agent apart and you get four parts, no more. There is a model, which is the reasoning engine. There is a loop, which lets the model act more than once instead of answering in a single shot. There are tools, which are the hands: functions the model can call to search, to read a file, to run code, to hit an API. And there is memory plus a goal, the context that tells the model where it has been and where it is trying to end up. Take any one of these away and you have something simpler and often better. A single model call with no loop is just a prompt. That is fine. Most tasks do not need more.

The word most people fumble is memory, so let us be concrete. Memory is not a mystical long-term brain. In practice it is context: the running transcript of what the agent has said and seen, plus whatever notes or retrieved documents you feed back in on each turn. There is short-term memory, which is just the current conversation, and there is longer-term memory, which is usually a database or a file the agent reads from and writes to on purpose. Neither is magic. Both are things you build, and both are things you can inspect, which is a mercy when something goes wrong.

The goal is the last piece, and it is the one people underspecify most. A goal an agent can pursue is not a mood. It is a target concrete enough that the loop knows when to stop. Fix this bug so the test passes is a goal. Make our support better is not. The clearer the finish line, the shorter the loop, and the shorter the loop, the more often the agent actually gets there. Vague goals are the single most common reason a demo that felt alive turns into a machine that wanders. We have watched it happen more than once.

Tools are the piece that turned chatbots into agents, and they are less mysterious than they sound. Both Anthropic and OpenAI expose the same core mechanic: you describe a function to the model in plain terms, the model reads your request and decides to call that function with specific arguments, your code actually runs the function, and the result goes back into the conversation. The model never runs anything itself. It only asks. Your system decides whether to honor the request, which is exactly the seam where safety lives.^{2 3}

Connecting a model to real tools and data used to mean gluing together a different integration for every source. The Model Context Protocol, an open standard introduced by Anthropic in late 2024, tries to fix that by giving tools, data, and models one common way to talk. Think of it as a shared port rather than a pile of custom adapters. The standard matters less for what it does today and more for what it signals: agents are becoming plumbing, and plumbing wants conventions, not heroics.⁴

An agent is a model in a loop with tools, memory, and a goal. Everything else is decoration.

So the honest definition is deflating on purpose. An agent is a model in a loop with tools, memory, and a goal. Everything past that sentence is engineering, and the engineering is where projects live or die. We keep returning to this frame because it makes the next two questions answerable. Once you know what the machine is, you can ask what it does well, and where it falls on its face.

What works today

Agents are genuinely good at a specific shape of work: bounded, well scoped, tool using tasks with a human checking the result. The words matter one at a time. Bounded means the job has clear edges and a clear finish. Well scoped means you can say in one sentence what done looks like. Tool using means the value comes from the model reaching into real systems, not from prose. And the human check means a person reviews the output before it touches anything that matters. Hit all four and agents earn their keep. Miss one and you are usually gambling.

Coding is the clearest proof. On SWE-bench, a benchmark built from real GitHub issues in real open source projects, agents are asked to produce a patch that actually makes a repository's tests pass. A few years ago the numbers were near the floor. Today the strongest systems resolve a large share of the tasks, and the frontier keeps moving up. That is a hard, verifiable job with an automatic grader attached, which is not a coincidence. When the finish line is a passing test, the agent has something honest to aim at.⁷

Look at the tasks agents handle well right now and the same shape repeats. Pulling structured data out of a stack of messy documents. Drafting a first pass at code, then running it against tests. Triaging a support inbox by category before a person replies. Researching a narrow question across a handful of sources and citing them. Every one of these has tight edges, a checkable result, and a human standing at the exit. None of them ask the machine to run unsupervised for hours across a dozen fuzzy decisions.

It helps to picture a spectrum rather than a switch. On one end sits a plain workflow, where you wrote the steps and the model just fills in the hard parts. On the other end sits a fully autonomous agent that plans its own path and runs until it decides it is done. Most of the value today lives close to the workflow end. The further right you slide, the more freedom the model gets, and freedom is exactly what makes the failures harder to predict. Reach for autonomy only when the task truly needs it, which is rarer than the demos suggest.¹

There is a quiet lesson in that list. The wins are not the flashiest demos. They are the boring, checkable jobs where a tool call replaces a tedious lookup and a person still signs off. We would rather ship ten of those than one autonomous agent that impresses in a video and cannot be trusted on a Tuesday. Small and reliable beats broad and brittle, every time we have measured it.

One more thing about the wins, because it is easy to miss. The tasks agents are best at share a hidden trait: the world tells you fast whether the agent was right. A test passes or it does not. A field parses or it does not. A category is correct or a human catches it in seconds. That fast feedback is not a nice-to-have. It is the mechanism that keeps a compounding-error machine honest, because a wrong step gets caught before it can poison the next ten. When you cannot get fast feedback, you have to build it, and building it is most of the job.

Where it still breaks

Now the part the demos skip. The single biggest problem with agents is long-horizon reliability, and the reason is arithmetic, not mystery. Suppose a model gets each individual step right ninety-five percent of the time. That sounds excellent. Chain twenty of those steps together, where each one depends on the last, and your odds of a clean run are 0.95 to the twentieth power, which is roughly thirty-six percent. Chain forty steps and you are near thirteen percent. Errors do not stay put. They compound, and a small mistake early becomes a confidently wrong conclusion later, because the model treats its own earlier output as fact.

This is why the best advice in the field is aggressively boring. Anthropic's own guidance tells builders to find the simplest thing that works and add complexity only when it clearly pays for itself, and to prefer plain workflows over open ended agent loops whenever the task allows. We agree, hard. A short chain fails less than a long one. A model that must guess less is wrong less. Most of the reliability you want comes from shrinking the problem, not from a smarter prompt.¹

The second break is evaluation, and it is sneakier because it hides. How do you know an agent is actually good? A single passing run tells you almost nothing, since these systems are stochastic and the same input can produce different behavior twice. Real evaluation means running the agent many times over many cases and measuring how often it succeeds, how it fails, and what the failures cost. That is expensive, it is unglamorous, and it is the work most teams skip. Skipping it is how a demo that dazzled in the room turns into an incident in production.

Benchmarks help but they also mislead if you read them lazily. A score on SWE-bench or any public leaderboard measures one distribution of tasks under one set of conditions. Your work is a different distribution. A number that looks like a grade is really a narrow snapshot, and treating it as a promise about your use case is a classic way to get burned. Use benchmarks to compare, never to conclude. The only evaluation that binds is the one you run on your own tasks, with your own definition of done.⁷

There is a third failure that gets less press and deserves more: agents are bad at knowing when to stop. A person who is stuck asks for help. An agent that is stuck often keeps going, taking action after action with total confidence, sometimes making the situation worse than if it had done nothing. Tool access raises the stakes here, because a model that can send an email or delete a file can turn a reasoning error into a real one. The loop that makes agents powerful is the same loop that lets a small mistake run.

Security is the failure that scares us most, because it is adversarial. An agent reads text from the world, and text can carry instructions. A malicious web page, a poisoned document, or a booby-trapped email can tell the model to ignore its real job and do something else, and the model, being obedient, sometimes complies. This is called prompt injection, and there is no clean fix for it yet. The defense is architecture, not cleverness: limit what the agent can reach, treat every external input as untrusted, and never let a model with broad permissions act on content it just read from a stranger. An agent that can both read your inbox and send mail on your behalf is a bigger target than most people realize.⁸

Cost and speed deserve one honest paragraph too. Every loop step is another model call, and calls take time and money. A workflow you could have written in a morning sometimes gets replaced by an agent that is slower, pricier, and less predictable, all to avoid writing a few rules. We are not against agents. We are against paying agent prices for workflow problems. Before you reach for a loop, ask whether a short, fixed sequence would do the same job cheaper and with fewer ways to fail. Often it would.

How to use agents responsibly now

None of this argues for waiting. It argues for a posture. The most useful public frame we have found is the NIST AI Risk Management Framework, which organizes the work into four plain functions: govern, map, measure, and manage. In agent terms that means deciding who is accountable, understanding where the system can cause harm, actually measuring how often it fails, and keeping controls in place while it runs. You do not need a compliance department to borrow the shape. You need to answer those four questions before you point an agent at anything that matters.⁶

OpenAI, Anthropic, and outside researchers have converged on a similar set of practical safeguards for agentic systems, and the overlap is telling. Keep a human in the loop for consequential actions. Constrain what an agent can touch, so its permissions match its job and nothing more. Make actions reversible where you can, and require confirmation where you cannot. Log everything the agent does so a person can reconstruct what happened. None of these are exotic. They are the same instincts we would apply to a new employee with system access and no track record yet.⁸

Here is the practical sequence we would follow to put an agent to work without getting hurt.

1. Scope it to one checkable job. Write, in a single sentence, what done looks like and how a human will verify it. If you cannot write that sentence, the task is not ready for an agent, and no model will save you from a fuzzy goal.
2. Give it the fewest tools and the narrowest permissions that let it finish. A read-only agent is far safer than one that can write, and most first versions should be able to look but not touch. Add power only after the read-only version has earned it.
3. Put a person at the exit. Every consequential action gets human review before it lands, especially anything that sends, spends, deletes, or publishes. The check is not a lack of trust in the model. It is respect for the arithmetic of compounding error.
4. Measure before you scale. Run the agent across a real batch of your own cases, count the failures, and read them. A system that works eight times in ten may still be unfit for a job where the two failures are expensive, and only your own numbers can tell you which world you are in.
5. Log, review, and tighten. Keep a record of every action, revisit the failures on a schedule, and adjust scope, tools, and prompts from what you learn. Agents are not set and forget. They are supervised systems that improve because you are watching.

Notice what that sequence is really doing. It shrinks the loop, narrows the blast radius, and puts a human where the arithmetic is most dangerous. Every step trades a little autonomy for a lot of reliability, and that is the trade worth making almost every time. The teams getting real value from agents right now are not the ones with the boldest demos. They are the ones who scoped hard, measured honestly, and gave the machine less rope than it could technically handle. Boring wins. It keeps winning.

Put simply, the responsible move today is to treat agents as capable, fast, and unreliable in the exact way a talented intern is unreliable: fine on bounded work, dangerous when trusted blindly, worth the supervision when the task fits. We think that framing beats both the hype and the backlash. Agents are neither the end of work nor a parlor trick. They are a real tool with a real shape, and using them well starts with refusing to pretend that shape is anything other than what it is: a model, in a loop, with tools, memory, and a goal.