The assistant, and everything it can do

How a request runs

Eight things happen, in this order. The architecture page walks the same eight and names the file behind each; this is what they mean from your side of the chat.

1. 01

   It reads the last turn first

   Every turn writes a record: the plan, what each step did, what evidence it had, what it asked, what was still waiting. The next message in the same conversation reads that record before anything is planned, so “the first one” means the first of the list that arrived and a step still waiting is not started twice.

2. 02

   It plans, or it asks

   A reasoning model is told what the system can do — the eighteen kinds below — and turns the request into steps that name what they need from one another. When two things could be meant it answers with one question instead of a guess, and that question is the whole reply. A request with one step takes the ordinary loop.

3. 03

   Memory answers what it already knows

   Before a step runs, what memory holds is checked against it: a fact of the right kind, recent enough for that kind, from a memory or from a step answered in an earlier run. A step answered that way is done, with the memory named as its evidence. Never a step that acts, never a question about now, never silently.

4. 04

   Workers run in waves

   Steps whose needs are met run at the same time; the next wave starts when they settle. Each worker is a bounded model loop with only its own kind's tools — a find worker cannot send mail — and it answers in one shape: done with evidence, pending, failed with a reason, or a question. Every path, id and address it passes must come from you or from a tool result.

5. 05

   Anything that leaves the building waits for you

   Sending mail, mailing a file off your computer, putting a file onto it, running a command, sharing a Space: each is proposed, not done. The exact act is put in front of you in the chat — the file, its full path, the machine, who it is going to — and it runs when you type the single-use code into that same conversation. A surface that cannot show you that is not offered the tool.

6. 06

   It waits for what answers later

   A laptop that is asleep answers when it wakes; a video takes minutes to fetch and transcribe. The step reports pending, the steps after it wait, and the reply says so rather than calling it a failure. When the answer lands, the turn is resumed with the steps already done given, so nothing runs twice and only what was waiting runs.

7. 07

   A second model refutes the draft

   The reply is drafted from the record; then a reasoning model is handed your message, the record and the draft as data and asked only for what the draft claims that the record does not support. Its problems feed one rewrite. Then rules with no model in them check the result: no path or address nobody reported, no “sent” without evidence of a send, no caveat dropped.

8. 08

   The reply says what did not happen

   What was found, what is still waiting and where it will arrive, what failed and why in the tool's own words. A run that ended in a question puts the question as the reply, with nothing else pretending to be progress.

Everything a step can be

Eighteen kinds, in the order the planner is told them. 9 of them change something outside the conversation, and those are the ones memory never answers for and the ones that wait for you when they leave the building. A kind whose tools this deployment lacks — no Drive connected, no agent running, no video token — is not offered to the planner at all, so it plans nothing that nobody can run.

What answers later, and where it lands

Two kinds of step do not answer inside the request. A step that asks your computer for something is answered when the agent on that machine next polls — at once if it is awake, when it wakes if it is not. A video is fetched, transcribed and, if you asked, watched by a worker that takes minutes. Both report pending, and the reply tells you so in as many words.

Where the answer lands depends on where you asked. A chat has somewhere to push to, so on Telegram the file, the listing or the transcript arrives in the same conversation and the steps that were waiting on it run then, without you typing anything. A request from the website or the command line has already returned by the time a machine replies, so the answer is recorded on the conversation and the next thing you ask picks it up.

What it refuses, and what it asks instead

• A value nobody gave

  A path, a Drive id, an address or a machine name has to come from your words or from a tool's result in the conversation. A plan with one missing asks; a worker with one missing asks. Nothing is completed from what seems likely.

• Drive is not your computer

  A path that starts with / or ~ is your computer, by path. A file id — letters and digits — is Drive. A worker that sends one to the other's tool is turned back before anything runs, and told why in one sentence.

• Mail to somebody it found

  An address found in your contacts is still an address you did not type, so the send waits for your code. An address in your own message, in a private chat bound to your account, is you deciding.

• Commands that reach out or interpret

  curl, ssh, python, bash and their kind are refused on the machine whatever anybody approved, for the reason the machine documentation gives at length: private data, untrusted content and a way out are the three things that together make exfiltration.

• Done with nothing done

  A worker that reports a step done without having used a tool has made a claim, not done a thing; the engine records it as a failure in the worker's own words. Prose after a real tool result is read as what the tools said.

It learns from its runs

What a run finds feeds memory back through the same machinery the extractor uses — importance and evidence, nothing separate. A step that agreed with a memory supports it; a step that contradicted one expires it and records the contradiction. A correction in your next message — “no, the other one” — contradicts the step it corrects at once, so the answer is not offered from memory again.

A turn that ends in failure asks you one question: what would have helped. Your next plain message is kept as the answer, and the next time a request like it arrives the planner is handed it — as advice in your words, labelled as such, never as a value it may use. The shape of a run that worked is remembered too, so the third time you ask for the spreadsheet the plan is the one that found it, not a fresh guess.

Tuning it

The pieces of a turn are configuration with defaults, not constants. A deployment sets them in its environment; a person's own settings override them for that person, where a surface offers them. A field left out keeps its default.

# per deployment
HARNESS_AGENTS=off          # every worker a fixed function; no model loop, no mid-run question
HARNESS_AGENT_ROUNDS=3      # how many tool rounds a worker that thinks may take
HARNESS_REVIEWER=off        # the rules decide alone; no second model reads the draft
HARNESS_RECALL_TURNS=25     # how many recent runs memory looks back over for a step

# per person
PATCH /v1/agent/preferences
{ "harness": { "agents": { "rounds": 5 }, "reviewer": true, "recallTurns": 50 } }

Which model does which job is one map, not a setting: text and tool rounds lead on Groq with NVIDIA, Cloudflare and OpenRouter rotated beside it, planning and review ask for reasoning, and OpenAI is held back as the paid last resort. No call site names a vendor, and a vendor being unavailable is a slower answer rather than an outage.