How an agent works#

Read this if the way an agent works is not already familiar. Nothing here has to be taken on trust: it all follows from its mechanics, and those mechanics are simple.

What the tools already keep#

An agent does not start entirely from zero once the tool is involved. Most tools keep notes, reread at every start an instructions file you put there for them, and let you attach a piece of work to a folder, to documents and to standing instructions. All of that is real, and on a single subject it is often enough.

But where does that continuity come from, and where does it stop? The answer is in the mechanics that follow.

A bare model, then a conversation#

At its rawest, a language model is a service you send text to and that sends text back. It has no access: not to your files, not to what you told it yesterday. Everything it knows about your situation is in what you have just sent.

A conversation adds one thing only: the earlier exchanges are sent again with every new message. What looks like memory is therefore text being resent. Nothing is stored anywhere else, and it all stops when the session stops.

The loop: the model and its harness#

Around that model comes a program able to act: open a file, write one, run a command, search a folder. That program has a name: the harness. It does everything the model cannot. The model touches nothing itself: it asks — “read this file” — the harness carries out the request within the perimeter it was given, puts the result back into the conversation, and the model continues from there. Then the loop starts again.

An agent is a model and its harness: that loop, plus the permissions that bound it. Four properties follow from that:

it sees only what it has been given. The set of reachable folders is finite, however your tool expresses it;
it reads on demand, never everything. It still has to decide to open a file, so it needs a reason to;
what it reads takes up counted room. Everything that enters the conversation — its context — weighs on it to the end; what is read without serving is taken from what would have served;
the conversation starts empty. A new session is a new conversation, and what it knows of the last one is whatever is handed to it to read again.

These four properties are not defects to work around. They are the terms of the problem.

When information is missing#

Those properties have one important consequence. When information is missing, a model does not stop: it fills the gap with what looks plausible. What it produces stays coherent, argued, and delivered with the same assurance as the rest. This is not a defect; it is how it works. Neither the model nor the harness settles that on its own: their job is not to give the agent the means to know exactly where it stands.

The practical consequence is simple. A start that fails outright is repaired in one sentence. A start from a reconstructed state surfaces later, in whatever it produced in the meantime. That is exactly Workshop’s ground.

What the harness brings#

The loop is a principle; the harness that implements it is a piece of software in its own right, and it brings a good deal more than those mechanics:

the ability to act — read and write files, search a tree, run commands, and depending on the harness browse the web or hand a task to a second agent;
a perimeter and permissions — which folders are reachable, what runs straight away and what asks for your agreement;
facts the model has no way of knowing, supplied at the start: today’s date, the system, the state of the current git repository;
a memory of its own — the notebook mentioned at the top of this page, which it rereads at every start;
extension points — connectors to other services, scripts fired by an event, skills loaded on the day their case arises.

What the tools already keep comes from there. But that is also where the limit appears: the harness gives access to the files; it never says which of them carry authority. That last layer is Workshop’s exact place, and the front page says what it adds.