In one sentence: make agents read less, recompute less, and take fewer risky actions
This PDF is not a coding-agent product you can install. It is a harness design brief. The proposal turns “what should the next turn see, which model should handle it, and may this command run?” into runtime decisions that can be recorded, measured, and controlled.
Do not carry every file, tool description, and old message into every turn. Identify the question first, then hide, summarize, or fully show only what helps answer it.
Switching models is not automatically cheaper. Reprocessing a large context during a handoff can erase the savings from using a smaller model.
Let the agent recommend an action, then have the runtime inspect the script, permissions, and sensitivity before it chooses allow, ask, or deny.
You do not need to understand every term before starting. Use the paper as a checklist: is your agent rereading the same material, exposing too many tools at once, or sending high-risk and low-risk work through the same model path?
Ten steps from the Jev harness blueprint
Meet Jev: separate decisions from code generation
The LLM writes, the harness executes, and Jev decides what each turn sees, where the request routes, and whether it should run. Each decision can then have an input and an outcome you can trace.
Ask the question that breaks the default design: what if there were no KV cache?
If every turn had to reprocess its context, the agent would need a different architecture. The question forces you to inspect context size, handoffs, and cache assumptions.
Stop routing blind: a handoff can cost more
The PDF uses Opus → Sonnet → Opus versus pure Opus, 6.19 versus 4.15, as an example. Reprocessing the context during a handoff can erase the cheaper model’s advantage. Treat it as a cost model to test.
Follow the tokens
The document cites reading and search as 56.2% of tool turns and 46.5% of tokens, with code writing below 10%. Optimizing “find and read” may pay back before optimizing “write.” The related measurement is from the FastContext paper ↗.
Score every content chunk for the current question
The same chunk does not need to be fully injected every time. Hide it, show a short summary, show a long summary, or show the full content. Compress after the question is known, not before.
Disclose tools in tiers
Start with one-line descriptions for hundreds of tools, load a schema when needed, and load full documentation only for a one-off query. Tool “batteries” should not become a context charge on every turn.
Load instructions by condition, and keep them durable
When editing *.tsx, load the frontend style guide. When entering billing/, load that directory’s gotchas file. Conversation compaction should not erase these conditions.
Route by trust, not only by difficulty
Keep secrets, infrastructure, and high-privilege actions on a first-party frontier model. Public documentation and low-risk organization can go to a cheaper model.
Share one retrieval pass
One read-only retrieval result can serve cross-model review, eval generation, ELI5 explanations, and live progress pages. Background tasks should not search the same material again.
Gate every command with programmable policy
Do not inspect only the command name. Read the script and target first, then apply allow / ask / deny. Jev can provide a judgment; the runtime still owns authorization.
A version you can try now
You do not need to rewrite an agent all at once. Pick one decision that happens every day and has a measurable outcome:
Start with tool selection, code-chunk ranking, whether to escalate to a stronger model, or whether a human review is needed.
Save the input, candidates, final decision, outcome, latency, input and output tokens, and total workflow cost.
Load conditional instructions for common directories and add an allow / ask / deny check for commands. Compare the same task set before expanding the design.
If you use Codex or Claude Code, start with TypeSafe’s Agent Skill ↗ or inspect the community MCP implementation ↗. They provide integration entry points; per-turn context assembly, caching, and permission policy still belong in a harness you control.
How to read the numbers in the post
This is a social-post summary, not an end-to-end coding-agent benchmark after implementing the full 12-page blueprint. Re-test it against your own task set and baseline; TypeSafe’s workflow evaluations ↗ cover a separate evaluation scope.
This is an example under specific token, model, and price assumptions. Context size, caching, output length, and current prices can all change the result.
The first two figures come from FastContext trajectory analysis; the last is a working estimate in the PDF. They point to what to measure, rather than fixed ratios for every agent.
Original files and related sources
Read the ten-step guide first if you want the main idea. Open the original files when you want to verify details. The links below include the PDF, accessible text, official documentation, research paper, and community material.
Common questions
Is this an official TypeSafe white paper?
This page is an internet-sourced reading guide. Use each linked original for its own authorship and status; this page translates the design into a practical explanation.
Can I install all ten steps into Codex or Claude Code?
There is no single installer for the proposed harness. You can test tool disclosure, conditional instructions, retrieval reuse, and command gates. Per-turn context assembly and permission policy require control of the host runtime.
Which step should I try first?
Measure the real cost of reading, searching, and tool calls first. Then run a small experiment around one repeated decision so you can see whether the bottleneck is the model, the context, or the routing.
Use it as an engineering checklist
The useful idea in this PDF is making an agent’s “what to see, where to route, and whether to execute” decisions observable. Validate one workflow first, then expand the harness.
Browse more sourced Jev resources →