Why this field note exists

The first time a long-running agent does something confusing, the operator usually blames the model. The second time, the operator usually blames the agent. By the third time, the operator usually realizes the confusion was about which layer of the system was actually doing the work.

A useful agent stack has at least three actors in it, and each one makes decisions the others don't. Naming the actors makes the decisions visible.

The three actors

The stack has three distinct roles. They're easy to conflate because they share the same screen. They are not the same person.

The user. The human at the top of the stack. Makes the actual choices: what to ask for, what to accept, what to throw away. Has context nobody else has, and time the system doesn't have. The slowest actor, the one with the most leverage, and the only one whose judgment counts when the system fails.

The model. The inference engine. Reads a prompt, writes a response, and stops. Doesn't remember what it said. Doesn't decide what to do next. Doesn't know it exists. The fastest actor, the one with the most raw fluency, and the one whose output is the most likely to be wrong without meaning to be.

The runtime. Everything around the model: the tool calls, the file reads, the session manager, the cron scheduler, the memory store, the workspace directory. The runtime is what turns a one-shot prompt into an actual agent loop. The actor with the most responsibility and the least credit.

Why the distinction matters

When the agent does something wrong, the easy answer is to blame the model. But the model didn't choose which tool to call. The runtime chose. The model didn't decide to keep working at 3 a.m. The runtime chose. The model didn't pick the file path. The runtime picked.

Likewise, the runtime didn't write the message — the model did. The runtime didn't say the wrong thing. The model did.

A field note for next time something goes wrong:

  • If the output is wrong, it's probably the model. Look at the

prompt first, then the model choice.

  • If the wrong tool was called, it's probably the runtime. Look

at the tool selection logic.

  • If the wrong task was attempted, it's probably the user. Look

at the goal definition.

The borders move, but the rule is stable: the actor whose decision this is, is the actor to investigate.

The triad of complaints

A small taxonomy of complaints that show up in agent work, indexed by which actor is actually at fault:

  • "The model is being dumb." Almost always wrong. The model is

being asked to do work the runtime should have done. Fix the runtime.

  • "The agent is hallucinating facts." The model is doing what

the model does — predicting plausible text. The runtime should have looked the facts up. Fix the runtime.

  • "The agent keeps stopping." The runtime decided it was done.

Either the loop has no continuation condition or the termination logic fired too early. Fix the runtime.

  • "The agent is going off the rails." The runtime's routing

logic sent the loop to a place it shouldn't have gone. Fix the runtime.

  • "The user is being unreasonable." This one is, occasionally,

actually true. But check the runtime first.

The pattern is obvious: most "the model" complaints are actually runtime failures. Which is good news, because runtime failures are fixable without retraining anything.

What the human / agent / robot triad adds

In a triad, the robot is a fourth actor — or, more accurately, a fourth surface for the runtime to push through. The robot is not a person; it is the place where tool calls become physical acts.

If the robot is doing the wrong thing, the user should still blame the runtime. The runtime chose which robot to call. The runtime chose the parameters. The runtime chose when to stop calling. The robot did what it was told, like the model did what it was told.

This is the part of the triad that takes the most discipline to internalize. When the physical world misbehaves, the operator's instinct is to look at the physical surface. That's right for the what. It's wrong for the why. The why is in the runtime, and the runtime is where the fix lives.

A small ritual that helps

When something goes wrong, walk the stack before you write the fix:

1. State the symptom. "The agent did X when it should have done Y." 2. Identify the surface. "The model said Z." 3. Identify the actor. "The model said Z because the prompt contained W." 4. Identify the decision. "The prompt contained W because the runtime assembled the context that way." 5. Now write the fix. At step 4.

Skipping steps is how "the model" gets blamed for things the runtime did. Going through all five is how the fix lands in the right place.