8 Models and agent harnesses
Four parts help explain why apparently similar agents behave differently. The model generates text and proposes actions. The provider runs the model service and handles the request under its account terms. The harness supplies the interface, instructions, tools, and permission checks. A tool performs one operation, such as reading a file or running an R script.
OpenCode is the workshop harness; you select a model through a provider route. Changing that route can change cost, availability, and data handling without changing the project files. Changing the harness can change which tools or instructions reach the same model. A model name alone therefore does not describe your complete working setup.
The model works from context: the instructions, conversation, and selected tool results supplied for the current response. It does not automatically see every file in your repository. The harness may add a system prompt, meaning instructions about the agent’s role and behaviour, alongside project guidance and your request. There need not be one universal stack of visible prompts: products assemble and prioritise these inputs differently.
An agent cannot reliably reveal hidden provider instructions. If it says “my system prompt requires this,” ask whether that is an observed instruction, a documented product rule, or an inference. Check evidence at the appropriate layer:
| Layer | Typical owner | Good evidence |
|---|---|---|
| Model/provider | provider | published policy and model documentation |
| Harness | agent software | version, help, and configuration docs |
| Project instructions | repository | the actual AGENTS.md, CLAUDE.md, or rules |
| User task | researcher | the prompt and accepted scope |
| Tools/results | environment | command output, diffs, and tests |
Suppose two agents are asked to repair a synthetic panel table. One runs the supplied checker; another writes its own test and reports success. The difference could reflect the model’s choice, missing project guidance, or tool access. Compare the loaded instructions and actual calls before attributing the result to model quality.
Some interfaces show reasoning traces, text describing intermediate reasoning. These can be useful signals for spotting a mistaken assumption, but they are not faithful audit logs of why an answer was produced. The studies below explain why a persuasive narrated explanation is insufficient evidence. Keep the tool output, changed files, and independent checks as reviewable records.
In Lab 1, separate what you observed from what the agent inferred about its setup. Record the harness and selected model/provider too, so a later comparison has a clear starting point.
8.1 Further reading
- Building effective agents — A practical vocabulary for separating the model, tools, workflow, and agent loop.
- Measuring Faithfulness in Chain-of-Thought Reasoning — This research preprint reports intervention experiments showing that reliance on a narrated chain varies sharply by model and task.
- Chain of Thought Monitorability: A New and Fragile Opportunity for AI Safety — This position paper makes a qualified case for treating visible reasoning as an extra oversight signal, not a faithful internal transcript.