A Practical Guide to Agent Quality & Token Optimisation¶
Qin Yu, 21 May 2026, updated 29 May 2026
We are now context engineers.
TL;DR: Agent output quality — and most of your token spend — is determined by the context window and the harness that builds it. The model matters, but the durable gains come from context discipline, model routing, sub-agent isolation, deterministic validation, and ongoing maintenance of your agent configuration.
Quick Start: 8 Things You Can Do Today¶
- Lead with the outcome — state the desired result, constraints, stop condition, and validation steps. Short prompts are good; underspecified prompts are not.
- Choose the good-enough model — route extraction, formatting, and search-heavy work to cheaper models; reserve frontier models for ambiguity, architecture, synthesis, and review.
- Work in phases — Research → Plan → Implement → Verify, with a separate session or sub-agent per phase.
- Treat context as working memory, not storage — keep the hot context small, current, and relevant; put durable knowledge in files, docs, or skills.
- Isolate noisy work in sub-agents — send read-heavy or parallel tasks to separate context windows and pass only summaries back.
- Add deterministic guardrails — tests, linters, type checkers, security scanners, and hooks catch errors before they compound.
- Keep agent configuration lean —
AGENTS.md/CLAUDE.md, skills, prompts, and MCP servers should be short, current, and versioned. - Treat misses as incidents — when an agent fails, update the relevant instruction, skill, hook, eval, or routing rule instead of retrying.
The Mental Model: The Agent Is a Harness¶
An agent is not just a model. It is a harness around a model.
The harness assembles the working context. It decides or mediates:
- which instruction layers are loaded,
- which files are read or retrieved,
- which tool outputs enter the conversation,
- which tools are available,
- which memories are recalled,
- when context is compacted,
- which model is used,
- which actions require approval,
- and which validation steps run after changes.
You shape these decisions by what you attach, select, open, mention, permit, configure, and ask the agent to do. You constrain the search space; the harness turns that into model context.
flowchart LR
U[You and your project] --> H[Agent harness]
H --> I[Instruction layers]
H --> T[Tools and MCP]
H --> M[Memory and session state]
H --> C[Compaction and context management]
H --> V[Validation and approvals]
I --> L[LLM]
T --> L
M --> L
C --> L
V --> L
L --> H
H --> U
GitHub Copilot, OpenAI Codex, and Claude Code expose different interfaces, but they are variations of this same architecture. The model is only one component; quality comes from how the harness assembles context, tools, state, and validation around it.
Useful official references: