Part 1 of 5

From Model to Agent Harness

The first page starts from the tempting shortcut, breaks it, then names the surrounding system that actually does the work.

Tempting model: "the agent is the model." The external harness writeups make the cleaner claim instead: the model supplies text-generation ability, while the agent harness supplies context, tools, feedback loops, and constraints around it. This repo then owns one narrower slice of that story: local serving plus the Pi-facing provider configuration. langchain.com/blog/the-anatomy-of-an-agent-harness databricks.com/blog/ai-harness README.org:13 src/coding_agent/agent_config.clj:26-77

Broken intuition

If the agent were just the model, the model would have to inspect files, remember prior work, run commands, scan logs, and keep a local server plus provider config stable by itself. That is not what a raw model does. A raw model turns current input into more tokens; everything around that loop is added by software outside the weights. langchain.com/blog/the-anatomy-of-an-agent-harness databricks.com/blog/ai-harness

Experiment

Walk outward from the raw model and inspect which surrounding capability makes the system usable.

ReasonModel predicts the next useful text from the current context.
ActHarness turns that text into a tool call or command.
ObserveHarness captures files, logs, or test output.
RepeatThe next model call sees the new evidence.

This is a conceptual reason-act-observe loop, not a literal token trace from this repo.

Select a capability to see which layer owns it.

Conceptual token example

A model can continue a prompt like "Open README, then...". The harness is what actually opens the file, runs the command, and returns the observation.

Revealed constraint

Both external harness writeups land on the same constraint: the model alone does not maintain durable context, execute tools, or verify work. Those are harness responsibilities, which is why the same model can perform differently when the surrounding harness is better or worse. langchain.com/blog/the-anatomy-of-an-agent-harness databricks.com/blog/ai-harness

Named concept

The name for that surrounding execution layer is the agent harness: the code, configuration, and control logic that turns model output into usable work. The model is still inside the system, but the harness decides what context is assembled, what tools exist, how actions are run, and how the result gets checked. langchain.com/blog/the-anatomy-of-an-agent-harness databricks.com/blog/ai-harness

  • Model: predicts text from the context window it is given.
  • Agent harness: supplies the context, actions, observations, and constraints.
  • Local stack: serves the chosen local model and gives Pi a provider entry through models.json.

Repo implementation

This repo does not implement the whole agent harness. It implements the serving and configuration slice: bb up uses the locked profile, fetches and verifies the local model assets, starts the local OpenAI-compatible server on 127.0.0.1, and merges this provider into Pi's models.json. That makes the repo easy to place in the bigger stack: not the model, not the frontend, but the local stack that serves the model and writes the harness configuration the frontend needs. README.org:13 src/coding_agent/profile.clj:44-68 src/coding_agent/agent_config.clj:26-77

Recognition

Classify each term before moving to the later pages.

Select a term to reveal its layer.

Sources

langchain.com/blog/the-anatomy-of-an-agent-harness databricks.com/blog/ai-harness README.org:3-13 src/coding_agent/profile.clj:44-68 src/coding_agent/agent_config.clj:26-77

Why start this way?
The page begins with the simple model, breaks it, then names the concept.