Agent-built deterministic tools

A pattern surfaced by 1Password's monolith refactor (see 1password-agentic-refactoring) and visible in several other agent workflows by other names. The idea: the model is good at writing one-shot analyzers — SSA passes, SQL parsers, code-shape extractors. Once those analyzers exist, their output is a stable artifact. Subsequent work — by humans or by agents — argues over the artifact, not over what the model thinks today.

Why it works

LLM output is non-deterministic. That's tolerable when the output gets used and discarded (one chat turn). It's expensive when the output is the input to other decisions, because the variance compounds. The trick is to push the non-determinism into a one-time cost: pay for it when the analyzer is generated and validated, then never pay for it again. After that point, every consumer reads the same numbers.

This is the difference between:

• Agent-as-interpreter. Re-asking the model "is this transaction safe to extract?" 800 times. 800 different chains of reasoning, drift, plausible-but-wrong cases, no audit trail.
• Agent-as-tool-builder. Asking the model once to write an SSA pass that classifies every call site by pattern. The pass runs deterministically. Now there are 800 rows in a table that everyone agrees on.

The second mode also makes review tractable: you read one analyzer carefully instead of 800 explanations.

Worked example

1Password's MustBegin migration — over 3,000 database-transaction call sites in a Go codebase. The team didn't ask agents to "migrate the calls." They:

1. Wrote an SSA-based manifest generator (one tool, reviewed once)
2. Classified the manifest into repeatable patterns (output: a finite set of cases)
3. Defined templates for each pattern (one spec per case)
4. Ran parallel agents in git worktrees, each given a fully-specified subtask

The deterministic step was step 1. Steps 2–4 reasoned over its output. The specs in step 3 closed the remaining variance. Result: hours of execution, near-perfect accuracy.

By contrast, the same team's service-extraction work — where the analyzer outputs were less complete and more judgment was required mid-flight — saw only 20–30% productivity gains and several near-misses (silent data loss from sequencing errors, deployment conflicts from shared-table confusion).

What this is not

Not the same as deterministic output. The agent that builds the analyzer is still non-deterministic. The point is to confine that variance to a one-time, reviewable artifact, not to eliminate it everywhere.

Not the same as RAG. RAG retrieves precomputed text into the agent's context for the next turn. This pattern computes a precomputed fact base that exists outside the agent and can be queried without involving the agent at all.

Not "no agents in the loop." Agents still execute against the manifest. They just execute on bounded, classified work — which is the regime they're good at.

Related patterns

• acceptance-criteria-ids — same shape applied to product specs: stable IDs that agents reference instead of re-interpreting prose
• specsmaxxing — the spec-first agent workflow this pattern is part of
• context-engineering — assembling stable prior state before invoking the model
• ai-assisted-workflow — Barbero's plan-before-code variant
• clean-code-coding-agents — codebase shape as another form of stable artifact
• no-silver-bullet-llms — why this helps with accidental difficulty but not essential difficulty