Patterns: agent internals, context and coding agents

TL;DR Fourteen decision shapes for agent internals, context, memory and coding tools, plus security-aware routing (P35), background triage (P36) and self-compiling workflows (P37). Scan Decision, follow Map.

How to read this

One pattern = one narrow judgment. Fit is our verdict against Jev 1.13 jaggedness: known failure modes and System One Models: strong = bounded options, semantic judgment, code owns the rest; workable = real, caveat named; poor = arithmetic, dates, indirection, generation or huge state. Pattern IDs are permanent; the full index is Decision patterns from the community (with fit verdicts). Posted numbers are attributed and unverified.

Diogo's notes = working notes by Diogo Almeida (@CompleteSkeptic, TypeSafe's CEO and Jev's creator), 2026-09-20: speculative, not documentation and not shipped.

Agent internals & orchestration

P01 Decisions wearing a generation costume

• Decision is this loop step a bounded check, not writing?
• State the tool result the LLM was about to reason over
• Ask Noul/Choice — "Did the last step satisfy task.constraint?"
• Code tag every call in a real transcript write-vs-decide; move only the decides
• Fit strong — the System One Models thesis itself
• Map How to build software with System One
• Seen @cyrilXBT (25–40% of calls), @0xCarnagee (938 of 1,284)

P02 Model and effort routing

• Decision which model tier handles this
• State the latest user message plus a line per tier
• Ask Choice over local | cheap | frontier | human, criteria naming each tier's job
• Code threshold the confidence, route, keep probabilities. Compute cache state, context length and expected remaining turns in code — arithmetic is weakness #2 (Jev 1.13 jaggedness: known failure modes); Jev judges difficulty and risk only
• Fit strong for the difficulty judgment; the economics are code
• Map Intent routing
• Seen @sydneyrunkle, @dani_avila7, gargpratyush/jev-router, 0xNatoshi/jev-codex-router (tier and thinking depth in one request; fails open; its −60% is a simulation), kerpopule/hermes-jev-skills (shadow mode first; risk words never take the cheapest tier)

KV-cache caveat (Diogo, proposed). Routing down and back can cost more than staying put: the large model re-processes the context when control returns. His comparison — prices 5/25 in/out large, 3/15 small; X = context Mtok, Y = output Mtok, Z = extra generated Mtok. Pure large = 25Y + 5Z; large → small → large = 3X + 20Y + 8Z, the 5(Y+Z) being the reload. On his assumed mix X = 0.65, Y = 0.12, Z = 0.23, pure large is ~two-thirds the cost. Measure your own.

P03 Tool-risk / irreversible-action gate

• Decision may this tool call execute unattended?
• State the call, its arguments, the task, the blast-radius facts
• Ask parallel Nouls — reversible? touches money? affects someone? — plus severity Score
• Code per-action thresholds: execute, log, review, block. Hard limits in code
• Fit strong, if each hazard is its own literal question
• Map Cookbook: Guardrails for LLMs
• Seen Diogo's notes (proposed) list permission/approval first: should this command run, with programmable queries for what is allowed, even reading a script's contents before it runs. @sydneyrunkle, DevMortimer/pi-warden, sharziki/semdecide (allow/escalate/block in local code; fails closed)

P04 Loop controller: done, stuck, recover

• Decision did the task finish, is it looping, what to do after a failure
• State task, recent actions, tool results, error code, attempt count
• Ask Nouls for finished / missing info / repeated; Choice over retry | wait | escalate
• Code re-read fresh state to confirm; backoff and caps live in code
• Fit strong — but a high score is not proof the file was written
• Map HTTP status codes, rate limits, retry semantics
• Seen @JoshARosen, thruwire/foreman, qkal/Canny (a "done" claim is refused by a ledger fact, never a probability; the Noul can only relax the gate; ~0.05 drift)

P05 Worker routing and branch pruning

• Decision which specialist owns this; which proposed plans survive
• State the work item plus workers available now, or the branches
• Ask Choice over live worker ids; a Score per branch on success, risk, reversibility
• Code rebuild the option list each turn; kill weak branches before a reasoner
• Fit strong — rank wide, read narrow; one dimension per Score
• Map Composite scoring
• Seen @JoshARosen, @Layton_Gott. Diogo's notes (proposed): most subagent cost may be deciding what context to pass in and merge back; per-chunk relevance (P07) would cut it, making many more affordable

P06 Confidence-gated human queue

• Decision which automated decisions a person should see
• State the decision record: answer, confidence, cost, reversibility
• Ask usually none — consumes P02–P05; add a novelty Noul if useful
• Code surface low confidence OR high cost OR irreversible; rest stays automatic
• Fit strong — thresholds come from your own labelled set, never from a post
• Map Confidence-gated routing
• Seen @Layton_Gott, @chddaniel

P35 Security-aware routing

• Decision what class of data will this task touch, so which provider or executor may see it
• State the task, the paths and tools it will reach, one line per class
• Ask Choice over classes (public | internal | customer-pii | credentials | safety-sensitive); Noul for "must a person approve?"
• Code a policy table maps class → allowed providers or a local executor; deny by default, high risk to a human
• Fit workable — the class judgment is bounded and semantic (strong alone), but it is a security control over attacker-influenced text, and adversarial content is weakness #6 (Jev 1.13 jaggedness: known failure modes): pair it with code-side allowlists, never the only control
• Map Cookbook: Guardrails for LLMs, Confidence-gated routing
• Seen Diogo's notes (proposed): reasons to route beyond difficulty and cost — very cheap providers may retain what passes through them, and some work should not reach a vendor's models at all. Also @0xCodila (restates the doc; scores are the poster's own)

P36 Background read-only task triage

• Decision which background findings are relevant enough to block or surface
• State the shared explicit state of the change, plus one finding
• Ask Noul "does this block?"; Choice over block | surface | file | drop; Score for severity
• Code fan read-only jobs out in parallel off one state; blocking rule and thresholds in code
• Fit strong — bounded judgment over state you already built; read-only jobs cannot corrupt anything, so the cost is compute and noise
• Map Speculative fan-out
• Seen Diogo's notes, Appendix 2 (proposed): cross-model review, security checks, background evals and ELI5 explainers are read-only functions of current state, so the costly "find the context" step is shared — which makes running many affordable

Context & memory management

P07 Compaction: what to drop, and when

• Decision is this tool call still needed; is the session at a safe boundary
• State one tool call plus the task; or recent turns plus window headroom
• Ask Noul per entry ("still needed for task?"); Noul for "work completed or recorded?"
• Code drop or truncate below threshold, survivors verbatim; precision early, recall late
• Fit strong — but chunk it; a 1M-token session exceeds the 64k request limit (State: what you send Jev)
• Map Cookbook: Classifying RAG passages
• Seen @mvanhorn (1M→86K in ~1s), @kunchenguid, tamaratran/fast-jev-compaction, kerpopule/hermes-jev-skills (71 turns in ~0.95 s, beat recency 11:4; but its handoff eval found a Jev digest recalled less than the plain transcript, so it ships the transcript), GhalebDweikat/winnow (25-line blocks judged before they enter context; its "strict" wording was overconfident, 23% of the bottom bin was needed)

"Meta-attention" (Diogo, proposed). Compaction assumes every future turn wants one shared summary. Drop that and re-decide context per query: a Noul on every chunk (tool-call inputs, outputs, reasoning, even user turns) — "does this query need it?"; later a Score per chunk, don't show / short summary / longer summary / whole thing. Query-aware selection is far easier than query-blind compression. Code still owns chunking and the cache arithmetic.

P08 Skill, rule and context selection per turn

• Decision which skills, rules or context slices this turn needs
• State the user turn plus one line describing each candidate
• Ask Choice to rank, plus a separate Noul for "does this turn need one at all?"
• Code load only the winners; the existence Noul stops a forced pick
• Fit strong — this is the shipped skill-suggestion recipe
• Map Cookbook: Skill suggestion, Cookbook: Hierarchical classification, Cookbook: Function calling
• Seen @swill1ams, @k2sbhai (the problem appears at 50 skills, not 5; abstaining beats a forced match), kitze/skillbox, EliaAlberti/jev-rules, kerpopule/hermes-jev-skills (377 skills picked in ~2.8 s, or none)

Two extensions (Diogo's notes, proposed):

• Conditional AGENTS.md. Load only what the turn needs: front-end task → the style guide; this subdirectory → its gotchas file. Unlike skills ("do this now") these are "keep in memory" rules he wants immune to compaction — mark them non-droppable in your P07 pass.
• Hierarchical tool routing. Tools are declared up front, eat context, and models are weak at high-cardinality off-policy calls. Instead: snippets of what exists, Choice on category, Choice on tool, then that tool's full schema — Cookbook: Hierarchical classification over a catalogue. Claim, unverified: hundreds of tools then cost almost nothing.

P09 Memory write/update/delete policy

• Decision what to do with an observation: write, update, delete, link, compact, none
• State the observation plus the matching existing records
• Ask Choice over the six operations; code supplies the target record ids
• Code validate and apply — never let a model emit DB commands
• Fit workable — @Av1dlive's rules baseline hit 23/24 vs a trained policy's 24/24; ship rules first
• Map Testing and evaluating a Jev workflow
• Seen @Av1dlive, codejunkie99/continual-memory-policy-model

Coding agents & dev tools

P10 Staged diff review and semantic lint

• Decision does this hunk carry a correctness, security or house-rule risk
• State one diff hunk, its context, and the rule text verbatim
• Ask Noul per risk class and per rule, plus severity Score, one request per hunk
• Code aggregate with max, not a mean; follow strong signals into a second pass
• Fit workable — literal reading means every rule needs its own precise question
• Map Writing instructions and criteria that Jev reads correctly
• Seen @devagrawal09, devagrawal09/jev-review, jkudish/jev-mcp (MCP tools: a four-rubric Score composited in code, plus an evidence gate on "tests pass" claims)

P11 Test-output interpretation

• Decision did tests pass, and is the failure related to this change
• State raw test output plus the diff
• Ask Noul (passed?) plus Choice over unrelated_flake | related | environment
• Code parse exit codes and counts in code; only attribution is a question
• Fit workable — counting is a documented weakness, so never ask "how many failed"
• Map Jev 1.13 jaggedness: known failure modes
• Seen @cyrilXBT (~13s overhead down to ~0.83s)

Self-compiling workflows

P37 Self-compiling workflow: let the agent do the job, then fire itself from it

• Decision per case, can the learned workflow handle this or does it go back to the full agent — plus every typed question inside it
• State the case record; inside the workflow, one item plus the criteria written from the procedure (Jev never sees the 508-line SOP)
• Ask four shapes — Route (Choice over branches plus an unsure branch), Classify (output schema → questions: enum → Choice, boolean → Noul), Sift (one Noul over every list item in one request), Pick (Choice of one item or none) — plus a verify clause checking an agent's submission field by field against the evidence it cited, and confidence predicates gating retries and escalations
• Code "Jev decides what a thing is; code decides what follows": ages, dates, tallies, two-strikes rules, and the share of cases routed to the workflow
• Fit strong — the decision/action seam, credited to 12-Factor Agents: an agent only where something must be found or done in the world, a typed question where something must be decided, code where mechanical. Compiling is a frontier agent's job, not Jev's
• Map Intent routing, Testing and evaluating a Jev workflow, Confidence vs probability
• Seen @MiguelriosEN (Grep.ai's AgentRun article), announcement @_aj

What to copy. Share growth, scheduled in advance: of 1,000 AML alerts the first 100 ran the full agent for traces and notes; then 50% of the next 200 could try the workflow, 75%, 90%, all of the last 300 — ending 98 in 100, hand-backs ~1 in 20 early, ~1 in 70 late. Validation: a candidate ships only after beating the live version on a dev set, plus a reserved set the author never sees — he matched every dev label yet scored the same reserved. Asymmetry survives compilation: clearing a true match is the regulatory failure, so thresholds stay lopsided, not a rubric average. Governance: each decision names its node, model, inputs, questions and probabilities, answers kept — a verdict-rules rewrite replayed 868 hits in two minutes for a few cents, no model call. Open problems: the by-the-book agent took 826 tool calls and 51 minutes (two runs hit the hour unfinished); splitting too finely leaves a judge with half the policy; crash recovery skips model nodes and nested workflows.

Their numbers, Grep.ai-reported and unverified: $3/alert for a frontier agent ($2.89 production → $0.25 over 100 alerts); 50–95% savings; 100,000 alerts >$290K on Opus 5 versus <$26K with the harness; their compliance judge scored 90% (first 100, full agent) to 95% (last 300). Jev claims verified as consistent with official pages, not independently measured: ~150 ms sits inside the 70–500 ms claim, and "a few hundred-thousandths of a dollar" per answer matches $0.042/Mtok input, output free (700 tokens, Models, aliases, pricing, rate limits, context).

Related

• Decision patterns from the community (with fit verdicts) — index, routing, anti-patterns
• Patterns: browser, computer use, voice and product UI — browser, computer use, voice, UI (P12-P14, P34)
• Patterns: judging, search, documents, real-time and markets — judging, search, documents, markets (P15-P18, P24-P27)
• Patterns: marketing, sales, GTM, content, support and ops — marketing, sales, support, ops (P19-P23, P28-P33)
• Consult guide: could Jev help this project? — the "could Jev help this project?" conversation
• Field reports: independent evaluations, critiques, open replicas — measurements behind these numbers
• Community repos: what people built and how they use Jev — the repos in Seen

Sources

Links are inline in each Seen line; the files behind them are in the frontmatter.