Latent vs. Deterministic
The single load-bearing line in agent design: every step is either judgment work (latent space, model) or trust work (deterministic, tools) — never both, and confusing them is the #1 failure mode.
Last updated: 2026-04-12
Overview
Garry Tan’s thin harness, fat skills thesis names a distinction that Sebastian Raschka’s six-component harness framing only implies: every step an agent takes lives on one side of a line. Latent-space work is judgment, synthesis, and pattern recognition — things the model does well and deterministic code cannot do at all. Deterministic work is arithmetic, SQL, compilation, file I/O — things where the same input must produce the same output, with zero tolerance for hallucination.
The most common failure mode in agent design is blurring this line: letting the model do arithmetic in its head, letting a tool make judgment calls about relevance, or pushing context-curation policy into harness plumbing. The best agents are ruthless about which side of the line each step belongs on, and they treat the harness as the seam between the two worlds — the place where one layer hands off cleanly to the other.
This page captures the operating rules that fall out of treating the line as sacred, and the three-layer ownership model that emerges when you draw the line cleanly through each component of an agent harness.
The Line
| Latent space | Deterministic | |
|---|---|---|
| Lives here | Judgment, synthesis, pattern matching, reading-between-the-lines | Trust — same input, same output, every time |
| Examples | Deciding which file matters for a bug; summarizing a transcript; classifying intent | Arithmetic, SQL, compilation, string matching, file I/O |
| Who does it | The model (from weights) | A tool (from code) |
| Failure mode | Hallucination when forced to be deterministic | Brittleness when forced to be flexible |
Raschka’s observation — “most of what feels like model quality is really context quality” — lands on the latent side. Tan’s observation — “push execution down into deterministic tooling” — lands on the other side. Together they say: make latent work as good as possible by curating context, and make deterministic work impossible to get wrong by pushing it into code.
The Artifact-Dependency Rule
The hard cases aren’t “is arithmetic latent or deterministic?” (answer: deterministic). The hard cases are trivial-looking operations where the model is reliable enough to cheat. The operating rule:
If an artifact or downstream decision depends on this value being exactly right, it crosses into deterministic territory — use a tool. If it’s scratch reasoning or conversational, latent is fine.
Worked example: 2 + 2
| Context | Correct layer | Why |
|---|---|---|
| User asks conversationally | Latent (answer from weights) | No artifact depends on it |
| Explaining a loop bound in chat | Latent | Scratch reasoning |
Writing const TOTAL = 2 + 2 into a file | Deterministic | An artifact depends on it — better yet, write the expression and let the compiler compute it |
| Reconciling counts, financial totals, byte sizes | Deterministic, always | Stakes + composition = hallucination surface |
Multi-step arithmetic (1024 * 0.73) | Deterministic | ”Trivial” does not generalize |
Two corollaries:
- Write the expression, not the result.
const MINUTES_PER_DAY = 60 * 24is better thanconst MINUTES_PER_DAY = 1440because it pushes the arithmetic down to the compiler — the deterministic layer closest to where the value is used. - PR-citation heuristic. If you’d cite the number in a PR description, it came from a tool. If you wouldn’t, latent is fine.
Where the Line Runs: Three-Column Ownership
Drawing the line cleanly through Raschka’s six harness components produces a three-layer ownership model. Each component has all three columns filled; if any column is empty, a responsibility has been smuggled into the wrong layer.
| Raschka component | Harness owns (mechanics) | Skill/resolver owns (policy) | Model owns (judgment) |
|---|---|---|---|
| 1. Live repo context | Gathering git status, branch, workspace facts | Which docs to pull (resolver pointers in CLAUDE.md) | — |
| 2. Prompt shape / cache | Prefix/suffix split, cache keys, token accounting | What goes in the prefix for this project | — |
| 3. Tool access | Dispatching calls, validating args, permissions | Which tools exist for this project | When to call which tool |
| 4. Context reduction | Clipping, dedup, summarization mechanics | Summarization strategy for this task type | What’s worth remembering |
| 5. Session memory | Append-only transcript, working-memory storage | How working memory is structured | What it should say |
| 6. Subagents | Spawning, isolation, bounds | Which skill a subagent runs | When to delegate |
Symptoms of getting ownership wrong:
- Fat harness (policy leaked down): hardcoded domain rules in the loop, tool-specific clipping heuristics, a 2,000-line harness that breaks when you switch projects.
- Slow skills (mechanics leaked up): no prompt caching, repeated file reads, runaway context because nothing enforces budgets.
- Model doing plumbing (mechanics leaked into latent): the model asked to decide cache keys or enforce budgets instead of just using curated context the harness handed it.
The Seam
The harness is literally the seam between latent and deterministic. Every tool call crosses the line: the model (latent) emits a structured request, the harness validates and executes it, a deterministic tool runs, and the bounded result returns to the model’s context. A good harness makes that crossing cheap and obvious — if using a tool costs 50ms and 50 tokens, the model will use it for 2 + 2; if it costs 3 seconds and 500 tokens, the model will cheat and answer from weights.
Designing the seam well is most of the work. Two headline principles:
- Make the tool path cheap enough that the model prefers it. Fast CLIs beat slow MCP round-trips by two orders of magnitude; this isn’t a micro-optimization, it’s the difference between an agent that uses tools and one that hallucinates around them.
- Never let the harness decide which side a step belongs on. That’s skill-file policy. A harness that auto-routes arithmetic to a calculator is doing domain judgment in plumbing — the fat-harness anti-pattern.
Key Points
- Every agent step is either latent-space (judgment) or deterministic (trust) — never both
- Confusing the two is the #1 failure mode in agent design
- The artifact-dependency rule: if a downstream artifact or decision depends on the value, use a tool
- Write expressions, not results — push arithmetic down to the compiler
- Context quality has three owners: harness (mechanics), skills (policy), model (judgment)
- The harness is the seam; its job is to make the crossing cheap, not to make judgment calls
- Raschka’s “context quality” and Tan’s “fat skills” are the same insight from two angles
Connections
- coding-agent — Raschka’s six components; this page draws the line through each of them
- thin-harness-fat-skills — Tan’s original latent-vs-deterministic framing; this page extends it with the artifact-dependency rule and the three-column ownership model
- sebastian-raschka — the mechanics half of the synthesis
- garry-tan — the policy half of the synthesis
Sources
- Synthesis distilled from a QUERY session — 2026-04-12
- Builds on coding-agent and thin-harness-fat-skills