Engineering with agents

AI Tools in Practice

Using agentic systems in everyday engineering work.

Part I

See it work

Part I — See it work

You probably know AI as a chat window

ChatGPT · GPT

generative pre-trained transformer, the T is Part II · CLI: Codex

Claude

after Claude Shannon, information theory · CLI: Claude Code

Gemini

the twins: Brain and DeepMind, one lab · CLI: Gemini CLI

Part I — See it work

What's a model

A model is a frozen set of numbers. Each message you send starts a turn, and every request in it resends the history.

The model is a frozen set of numbers, fixed when it was trained. No input you've added changes these weights
A request consists of the latest input and all the conversation history so far. This is what shapes the evolution of the answers
There is no notion of natural memory between requests, the "conversation" gets resent every turn

Part I — See it work

Context window

The model sees one context window, and it fills up.

Every message, every file it reads, every answer goes into one context window of a fixed size
When it fills, old detail is squeezed out or summarised, often by a model executing some form of summary instruction. Longer chats get vaguer over time for that reason
A fresh chat is a fresh context window. That is why "start a new conversation" impacts the performance so much

one context window · finite · fresh thread, sharp answer

Part I — See it work

Agents

Agents can use tools.
Give the model tools, and it can act, and then run checks on its own work.

the chat you know, plus tools and a feedback loop

Part I — See it work

The whole agent on one screen

# tools: read_file, run_command (asks before running) while True: reply = model(messages, tools) messages.append(reply) if reply.tool_calls: for call in reply.tool_calls: messages.append(tool_result(call.id, run_tool(call))) continue break # the stop condition

a model predicts text · in a loop with tools and a stop condition, it can run its own checks

LIVE · the one-screen agent runs against any OpenAI-compatible local server · uv run --with requests harness_skeleton.py

Part I — See it work

AI is not just a thing that you stuff into your apps.
AI is a thing that changes how you use a computer.

one button · one app · one feature

Inbox
Sent
Drafts
Archive

Re: flaky CI test · 14 messages
Thread with the platform team about the race in the shared map…
✦ Summarize with AI

you ask · the agent operates the machine

❯ the pricing hero shifts on mobile. find it and fix it
read tests/visual/pricing.spec.ts · read src/hero.css
edit src/hero.css · reserve the image box
run visual tests · 12 passed
run visual tests, 3 viewports · 36 passed
❯ open the PR with the diff and the screenshots

It is not a feature to integrate. It is a tool you operate.

Part I — See it work

One prompt

❯ Create an interactive animation that demonstrates Einstein's spacetime curvature due to gravity or acceleration, for demonstration purposes in a physics lecture, as a single self-contained HTML file.

LIVE · open the result one 51 KB file · zero network requests · and it is yours

Curvature and orbits tab — curvature & orbits

Equivalence principle tab — equivalence principle

Gravitational time tab — gravitational time

Part I — See it work

Same request, different results

Apollo flight-ops deck, Fable 5 build — Fable 5 · click to preview

Apollo deck, GPT-5.6 Sol build — GPT-5.6 Sol · click to preview

# the shared work order, one prompt to both models (excerpt)
Create a slide presentation that explains the Apollo program to a curious
general adult audience. Produce a Marp-flavored markdown deck named deck.md
… 11 to 14 slides … every date, name, and place must be accurate.
… style: the Voyager Golden Record meets For All Mankind, season one.

models have character · later we route work by it

LIVE · ask two models to build it again
one prompt, two sessions · recorded above

Part I — See it work

Also one prompt

A working audio deck.

❯ ok, let's have some fun, let's write winamp

That was the complete prompt. One HTML file contains

the audio processing,
a functional equalizer, the spectrum display,
the playlist, and a generated demo song.

LIVE · open and press play

Part I — See it work

Models excel at redoing what's already been done

Everything we've seen so far has been a recombination of known work. The model did not have to invent anything
A model repeats the patterns in its training data.
Ask for something outside those patterns, and one answer is often not good enough without extra guidance
Iteration is the method: generate, check against known facts, contradict, generate again

Part I — See it work

How do we build what's not out there?

"Life before The Claude™: building was capital-intense, you had to predict the future, experimentation was expensive."

Internal tools are almost always in the gold segment. They are too specific to buy, and nobody builds them
One prototype is now an afternoon with an agent, as you have just seen.
You keep the validation, the reproducibility, and the maintenance

Part I — See it work

How do you harness the power?

A harness is a deterministic envelope around the model: Claude Code, Cursor, opencode etc.

Context: in what way does the model apply rules, open files, search results, and record tool outputs for each task?
Tools: what tools are available, which requests run on your machine, which run remotely, and which wait for a permission check?
State: where do edits, the conversation history, and persistent instructions survive a session and where do they live on disk?

Docs: Claude Code · Cursor · opencode

Part I — See it work

Fan-out

One question, several agents.

LIVE · launch the fan-out recorded: agent teams in tmux · click the recording to enlarge

Recorded: Claude Code with agent teams in tmux split panes, three teammates named sources, numbers and critics research in parallel while the lead waits, the middle as a time-lapse, then one synthesis held at the end

❯ Do containerized coding agents on developer machines actually reduce security risk compared to OS-level sandboxing, or do they just move the attack surface?

three angles: primary sources, numbers, critics · one synthesis, agreement and dissent marked

Part I — See it work

Computer use

The agent drives a real browser.

Claude for Chrome clicks, types, reads the page and the console. Codex Computer Use does the same from OpenAI on a controlled desktop

LIVE · the agent drives the spacetime app in Chrome
recorded: Claude in Chrome runs this prompt · recorded: it types and formats a letter from Rivendell in Word

❯ Open the spacetime app. Switch to the gravitational time tab, increase the mass, and report how the clock rates change. Say what you did and what you saw.

three outcomes: success, safe failure, fabrication a missed control shows the recovery · the failure is shown on purpose

This slide deck was validated the same way: Claude Code and Codex both drove a browser through the slides at two projector sizes and reported what clipped and what needed work (validate/astra.sh in html-slides, the deck engine).

Part II

How it works

You saw one agentic loop, its tools, and a stop condition.
Now let's look at what lies underneath.

Part II — How it works

The only thing a model does is …

A model turns the context into probabilities for the next token and samples one.
Everything that extends beyond the chat window is extra machinery around that operation
On its own a model only writes text. Every action the model can take is part of how it's harnessed (i.e. integrated)
So it's just probabilities? Yes. And a hallucination is fluent, confident output that is wrong. The cause is structural. The sampler must pick some plausible token, and when the model does not have the fact, plausible is all it has

temperature and the related settings only change the distribution before the choice

Part II — How it works

Tokens

The model doesn't actually work with characters or words.
see OpenAI tokenizer · check this GIF recording here

Each token ID selects one row of the token table: its starting vector, 3,840 numbers
The same token selects the same row. Attention, next, makes the two "the" vectors differ

the token table alone is 262,144 rows × 3,840 numbers: 1.0 billion of the model's 11.9 billion a context window is measured in these tokens, and so is the bill

Part II — How it works

What's model attention?

Each token reads itself and every earlier token.

Each token compares itself with every earlier token, weights them, and takes a weighted sum of their vectors. The result is a new vector with context in it
The cost is the square of the length. 7 tokens make 49 pairs. Attention uses 28 pairs, each token with itself included. 1,000 tokens make 1,000,000. So the context window is finite, and long sessions slow down and get thin

the tokens and IDs in the figure are real · the line strengths are illustrative

Part II — How it works

One request

What the model receives when you press Enter.

The model writes on from the end of the request and returns only what it added, text or a tool call. That is one completion, the word in the endpoint's name, /v1/chat/completions. Then the connection closes
Every turn, the harness rebuilds the whole request. The conversation is a file the harness keeps and resends

# the body harness_skeleton.py sends, trimmed {"model": "google/gemma-4-12b-qat", "messages": [ {"role": "system", "content": "You are an agent…"}, {"role": "user", "content": "read data/…"}], "tools": [ {"function": {"name": "read_file", "parameters": {"type": "object", "properties": {"path": {"type": "string"}}}}}, {"function": {"name": "run_command", "parameters": {"cmd": "string"}}}]}

Source: public/demo/harness_skeleton.py · the chat window sends the same JSON without the tools key

Part II — How it works

From chat to harness

Same loop around the model, more machinery inside.

I · chat: prompt, model, output. A person reads the output and closes the loop by typing again
II · agent: the output becomes the next input. No person types in between: each reply goes straight back in, until a stop condition ends the run
III · harness: code around that loop decides what goes in, what is allowed, and what runs beside it

Stage III, in daily use: Claude Code · Codex · Gemini CLI · opencode · pi · Antigravity · Cursor · Zed

Part II — How it works

Three disciplines

The line keeps moving outward: from the prompt, to the session tooling, to everything around it.

prompt engineering: what you say to one call
agent engineering: the loop, its tools, its stop condition
harness engineering: everything around the loop, which is permissions, context, data, and agents

Part II — How it works

Inside the model

One block of arithmetic, repeated 48 times.
Then one last step turns a vector into a score for every token.

A layer: attention reads the other tokens, then a feed-forward step works on each token. 48 in a row
The head turns the last vector into 262,144 scores, one per vocabulary entry. Softmax makes them probabilities
One frozen file: 11.9 billion numbers, the vocabulary and the settings

this stack is the transformer · the T in GPT

Counts from the header of gemma-4-12B-it-Q4_K_M.gguf.
Papers: Attention Is All You Need (Google, 2017) introduced the design · Improving Language Understanding by Generative Pre-Training (OpenAI, 2018) named it GPT

Part II — How it works

Training

So where do the numbers come from? And how do 11.9 billion of them fit in 7.4 GB?

Pre-training sets the numbers with one task: predict the next token over a corpus of text. The result continues whatever it is given
Post-training nudges the same numbers again, toward instructions and preferred replies. Nothing is appended. The "it" in the name means instruction-tuned
Quantization rounds the numbers to fewer bits. This file: 9.3 billion at about 4 bits, 2.6 billion at about 6. QAT trains with the rounding in place

10.9 B numbers live in the 48 layers · 1.0 B in the token table · 0.8 M in normalisation scales

Counts read from the header of gemma-4-12B-it-Q4_K_M.gguf with the gguf Python reader. 23.8 GB is 11.9 billion numbers at 16 bits.

Part II — How it works

How training works

Guess the next word, compare with the real one, nudge the numbers. Then teach it to answer.

Pre-training is one loop: hide the next word, let the model guess, compare the guess with the real word, nudge every number a little toward it. Repeat over the whole corpus
Post-training is the same nudge with a different target: answers people wrote, then the answer people or a judge model preferred of two
No prompt, file or conversation changes the numbers. The file is frozen, and the context is the only way in

Reading: Post-training methods (Red Hat) · LLM post-training primer (PyTorch)

Part II — How it works

When the loop stops

# the same loop, one more task ❯ fix the failing test in test_period.py tool_call read_file test_period.py tool_call run_command pytest -q # 1 failed tool_call write_file period.py tool_call run_command pytest -q # 1 failed DONE. The test now passes. # no tool call: the loop stops $ pytest -q FAILED test_mean_period # it does not

The loop stops when the model stops calling tools. That stop says little about the result
Success is a check the model did not write: a test you run, a diff you read, a source you open

stop condition ≠ done condition

Part II — How it works

Inside a tool call

The harness checks every tool call.

LIVE · the schemas in the one-screen agent

Each harness names it differently: tool_use in Claude Code, function_call in Codex, one common interface in opencode

The model never touches your shell. It sends a tool call. The harness reads it, validates it, asks your permission, and makes the system call. Most of the walls in this talk stand on that boundary.

Part II — How it works

Artifacts

The files on your disk.

# the user level · every project ~/.claude/ # instructions, every session CLAUDE.md rules/Deslop.md … # capabilities, loaded on demand skills/BuildSkill/ RTK/ … # your code between the steps hooks/gate-large-edits.sh # bundles of the above, installable plugins/ # permissions, sandbox, hooks settings.json # the workspace · one project ~/code/ai-tools-in-practice/ # the project's instructions CLAUDE.md AGENTS.md # a specialist, own prompt and tools .claude/agents/reviewer.md # the project's permissions .claude/settings.json # an artifact, it leaves the project public/slides/talk.html

harness vs app: the harness runs the loop. An app is what the loop produces
agent vs subagent: the agent is the loop you talk to. A subagent is a new loop that the agent starts, and it returns only its result
harness vs surface: Claude Code is the harness. The terminal, Zed, or VS Code window around it is only the surface

Instructions are files. Capabilities are files. You can review them, put them in version control, and own them. The real ~/.claude listing

Part II — How it works

Key concepts

You probably heard these terms at one point, see the example below: five live inside the request, three in the harness around it.

Every term links to its page · glossary · settings

Part II — How it works

Claude Code

The same loop, as a mature product. Every feature is one line of the loop you typed.

A hook is one if before the tool runs. A skill is a file added to messages when needed. Docs: system prompt · tool catalog · permissions · context management · hooks · skills · subagents · the loop, read from the product: Claude Code, reverse-engineered

Part II — How it works

Compaction

The context window fills up. A summary replaces the history, and the detail goes with it.

Every turn adds to the transcript. As the context window fills, attention spreads thinner and late answers lose precision
At the limit, the transcript becomes one summary block. The model writes what it thinks mattered. New turns take the freed space
The detail does not return. A later question about a lost detail has nothing to read. A new thread for a new subject

context windows: Fable 5.1 · 1M, Opus 5.5 · 1M, GPT-6.1 Sol · 1.05M tokens every extra round of tool calls costs tokens and latency

Sources: Claude models · GPT-6.1 Sol · fetched 2026-10-20

Part II — How it works

Models lie confidently

Three ways to be wrong, and the sampler cannot tell them apart.

factuality

wrong about the world

faithfulness

wrong about the source it read

sycophancy

agrees with you, trained to

LIVE · local gemma4 fabricates three papers recorded · click to enlarge

❯ Cite three peer-reviewed papers on decoherence in double-slit interferometry by Czech authors. Give full DOIs.

real papers, or confident fiction · the DOIs decide

Recorded: a local gemma-4 answers the prompt with three papers, authors, journal, year and DOI each, in seconds; doi.org then answers 404 for all three

never trust and always verify · use tests, limit cases, and sources the model cannot invent

Part II — How it works

The boundaries stack

LIVE · dummy .env and blocked egress RECORDED · the rule, then the cage

web content is untrusted input → beware of prompt injection each layer answers a different question · one layer alone is not enough

Part II — How it works

Permissions

Allow, ask, deny.

LIVE · deny a dummy .env read

{ "permissions": { "allow": ["Bash(git status)", "Bash(npm test:*)"], "ask": ["Bash(git push:*)"], "deny": ["Read(~/.ssh/**)", "Read(**/.env)", "Bash(curl:*)"] } }

matchers

one rule for each tool and pattern · match one git subcommand instead of every Bash command

A denial is not a failure. A good agent moves to permitted sources. It returns its work in the reply, and it reports the checks it could not run.

Part II — How it works

The sandbox

Walls the OS enforces.

"sandbox": { "enabled": true, "filesystem": { "denyRead": ["./.env", "~/.ssh", "~/.aws", "~/.gnupg"], "allowWrite": [".", "$TMPDIR"], "denyWrite": ["./settings.json", "~/.claude/settings.json"] }, "excludedCommands": ["trash"] }

A denied write means the system is working.

Part II — How it works

The egress cage

Where bytes may go.

LIVE · blocked curl, one allowlist line, rerun

"network": { "allowedDomains": ["github.com", "registry.npmjs.org", "pypi.org"], "strictAllowlist": true } # the receipts, live: $ curl -I https://example.com # → DENIED, not listed $ curl -I https://pypi.org # → 200, allowlisted

Prompt injection path

Injected text → the agent reads it → it uploads code to a listed host. github.com and pypi.org accept uploads. The allowlist does not read content.

Protections

A short allowlist · a read-only token · writes wait for a person · personal data redacted

Part II — How it works

Hooks

Your code between the steps.

# settings.json · your command, wired at a seam "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "~/.claude/hooks/guard.sh" }] }] # the contract · JSON in on stdin, decision out on stdout {"tool_name":"Bash","tool_input":{"command":"rm -rf build"}} # in {"hookSpecificOutput":{"hookEventName":"PreToolUse", "permissionDecision":"deny","permissionDecisionReason":"destructive command"}} # out

Thirty-three hook events in the docs as of October 2026, from SessionStart to SessionEnd. Start with one guard. Add the next one after a failure shows the need.

Part II — How it works

The same hooks in multiple harnesses

One loop, so one set of moments. Each harness names them differently.

	Claude Code	Codex CLI	OpenCode	pi
session starts	SessionStart	SessionStart	session.created	session_start
prompt submitted	UserPromptSubmit	UserPromptSubmit	none	input · before_agent_start
permission decided	PermissionRequest	PermissionRequest	permission.asked · permission.replied	tool_call · block: true
before a tool runs	PreToolUse	PreToolUse	tool.execute.before · throw	tool_call
after a tool runs	PostToolUse · PostToolUseFailure	PostToolUse	tool.execute.after	tool_result
compaction	PreCompact · PostCompact	PreCompact · PostCompact	experimental.session.compacting · session.compacted	session_before_compact · session_compact
the agent stops	Stop	Stop · Interrupt	session.idle	agent_settled
session ends	SessionEnd	SessionEnd	none	session_shutdown

a cyan name can stop the action · the rest can only watch Claude Code and Codex share names and stdin JSON · OpenCode: a plugin · pi: an extension

Read from each tool's own reference on 19 October 2026: Claude Code hooks · Codex 0.163 hooks source · OpenCode plugins · pi extensions. none: no event in the docs.

Part II — How it works

Guarding against dangerous commands

LIVE · ask for rm -rf in a throwaway clone

dcg

the destructive command guard runs under hooks.PreToolUse with the Bash matcher · it matches rm -rf, force-push, and reset, and blocks them before execution

layer order

prose gives direction · hooks and deny rules enforce · never weaken a lower layer for a higher one

one prompt under two policies behaves as two different systems this stack is one afternoon of work

Part II — How it works

OpenCode

The same controls on a different harness. Line for line.

Claude Code

// settings.json "permissions": { "allow": ["Bash(git status)"], "deny": ["Read(~/.ssh/**)"] }, "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{ "type": "command", "command": "guard.sh" }] }] }, "sandbox": { "network": { "allowedDomains": ["github.com"] } }

permissionshookssandbox

OpenCode

// opencode.json "permission": { "*": "ask", "read": { "~/.ssh/**": "deny" } }, // guard.ts · a plugin export const Guard = async () => ({ "tool.execute.before": async (i, o) => { if (isDestructive(o.args)) throw new Error() } }) // no sandbox block // the container is the wall

the one difference: OpenCode applies the last matching rule · Claude Code lets deny beat allow

Any OpenAI-compatible endpoint is one provider entry, which is how a local LM Studio or Ollama server plugs in. Instructions live in AGENTS.md. Docs: opencode.ai/docs · providers · permissions · plugins

Part II — How it works

Using all the guard rails

telemetry

it records every session, logs every command, shows dashboards, and permits an undo

review bot

a second model reads every change before a human does

the theater test

a limit is real only if the model cannot argue with it. Kernel walls, deny lists, and guards are real. Prose that repeats them is decoration, and decoration is what drifts.

Telemetry records what happened. The walls above it do the stopping. To audit a cage, name what enforces each limit: the kernel, a hook, a deny rule, or only a sentence.

Part III

Make it work

You can now define seven terms: harness, tool call, permission, sandbox, egress, hook, and compaction. Now we use them.

Part III — Make it work

Instruction files advise, hooks enforce

AGENTS.md is the canonical file. The harnesses listed at agents.md read it. CLAUDE.md and the matching files contain one line: @AGENTS.md
Keep them short and local, and review them as code. Write one file at the repository root. Add a file for a package only if its behavior differs. Keep each file below two hundred lines
An old instruction file is the failure mode. In the figure, someone trims the file in month 2, the scan sentence goes, and nobody notices. In month 6 the scan becomes a prek hook, so it runs on every commit. Every documented command must run: build, test, lint, typecheck, and codegen

one rule to include: finish the whole task, and say what was left out if nobody reviews the instruction file, nobody agreed to the policy

Part III — Make it work

Start small

Explore, then plan, then make a small diff. The agent reads the code first, proposes a route, and edits last
Check the change with tests you trust: the project's existing tests, or a test you write yourself. A test the model wrote for its own change is not an independent check
The agent makes the change, and you review the diff. The permission prompts show you each action that needs your approval
When the model makes an error, correct it in the open, in the thread or the review. Then write a reusable lesson into the instruction file. The model stays frozen, but later sessions that load the file start with the lesson

One small verified change is better than one large impressive change. Every pattern on this slide works the same way for everyone here.

Part III — Make it work

Vibecoding, honestly

Vibecoding means you accept generated code verbatim and smear slop everywhere, offloading cognitive load to other people. That is not what we want.
Use the honest funnel: generate freely, then read what matters and verify what you merge

regenerate until it looks right: a slot machine. Unpredictable rewards make it hard to stop generation without a test is only sampling · verification stops the gambling

Part III — Make it work

Where agents move people on the map

Agents can expand the prodigy corner. A new engineer delivers work like an experienced one, because the harness runs the checks they would not know to run yet.
Another direction also exists: experienced people who refuse to understand the tools. The tools make them worse. Seniority in software engineering can be greatly leveraged with AI, don't waste the opportunity.

Part III — Make it work

How much care does this code deserve?

The verification effort follows the stakes. Put each piece of code on this line first. Then decide how much of the funnel it gets.

Part III — Make it work

Authenticity theater

The rituals are familiar. People remove the em dashes and reword "AI-sounding" prose. They commit agent work under a human name, and they make each artifact look hand-made
Removing the signs does not change the artifact. It removes only the evidence
Every hour spent making AI work look human is an hour not spent verifying it

honest attribution lives in the log: the agent is the named author, a human commits put the human signature where it has meaning · the review, the seal, and the merge this is the mirror of security theater · both decorate and neither enforces

Part III — Make it work

The new division of labor

The model produces the work. You are accountable for the behavior, the claims, and everything released under your name
Accountability means you write the tests, checks, and probes that could prove the model wrong
An engineer who only prompts and approves has stopped doing the work. The work moved to producing the verification
Developers also write insecure code. The review standard is the security boundary, not the author

A failure mode to audit for: an always-loaded instruction names a scanner that does not exist. The model follows it in every session and has no reason to report it. Only a human audit of the file finds it. A live review thread, agent-run: runedeck/skeleton#1.

Part III — Make it work

Find the bugs in my PR

Each finding is a proposal until a person checks it.

LIVE · the review prompt

Review before you authorRead-only · no writes

Illustrative. No recorded run stands behind this figure: the defects are planted, and the checks are plain Python a person runs.
Run the same read-only review on your next PR: codex exec --sandbox read-only

Part III — Make it work

Disagreement

Models tend to be agreeable. They might need a push to become adversarial.

# paste into a fresh session, with the plan or the diff, and nothing about what you think of it
Take the opposing angle. Assume this plan fails in production. Give the three strongest reasons, each with the evidence that would prove it, and say which one you would check first. Do not soften any of them.

Do not lead with your answer. A request that includes your opinion gets your opinion back, better phrased
Give it the opposing role, in a separate session. The session that wrote the plan has a stake in it. A fresh one, told to attack, does not
Ask for evidence per objection, then check it yourself. An objection without a check is one more plausible sentence

the same move, as a skill: three hostile angles in parallel, every hit bound to a quoted line

Part III — Make it work

One claim, one source, one verdict

every other claim in the deck: unchecked until someone compares it with its source a reviewer's output is a claim too · it gets the same check

The smallest unit of verification. Apply this check to each finding and to the fan-out results next. Source: NASA, July 20, 1969: One Giant Leap For Mankind

Part III — Make it work

Fan-out

The results are in, from the run we launched on the first Fan-out slide.

LIVE · back to the fan-out session

The agents answered the question from the Fan-out slide while the talk went on.
Agreement between independent agents can be considered evidence. It is not proof, we still check it.
The disagreement is the valuable part. Put your attention where the agents disagree

Apply the claim, source, and verdict check to the synthesis. Separate sessions can catch different errors. Agreement still needs a check against a source.

Part III — Make it work

Secrets hygiene and CI parity

The harness denies credential reads. Prose does not discourage them. Hard deny rules protect ~/.ssh, .env, and token files
Add a pre-commit secret scan that finds what passes the deny rules. Use gitleaks for credentials and semgrep for code patterns, and run both with prek. Keep session transcripts in .gitignore, because they hold everything the agent saw
AI-authored changes use the same CI as human changes. The checks and the standard are the same. It has no separate path and no exception

the allowlist names every host that gets bytes, the model provider included a difference between the local checks and CI removes trust first

Part III — Make it work

Where your code goes

Every request sends your context to whoever runs the model.

Where the model runs	Trains on it	Keeps it	Where it runs
Anthropic API, Claude for Work	no, by default	deleted within 30 days · zero retention by agreement	global, or US only
Claude Free, Pro, Max, with Claude Code	only if you allow it	consumer terms · no zero retention	global
OpenAI API and business plans	no, by default	up to 30 days for abuse checks · zero retention on request	EU processing for eligible customers
A local model	no	your disk	your machine

Web tools run on the provider's side too. WebSearch and the API web fetch run on Anthropic's servers, Codex web search is hosted by OpenAI, and Claude Code's WebFetch sends each page through a model call. None of them reads your sandbox allowlist.

Open-source code can probably go to any row.
Internal code goes only to commercial terms or a local model.
Secrets and user data never go into a prompt, and sandboxing needs to keep them out of reach.

Sources, read 21 Oct 2026: Anthropic training · Anthropic retention · Anthropic regions · Claude consumer plans · OpenAI enterprise privacy · OpenAI data controls · Claude Code web tools · API web fetch · Codex web search

Part III — Make it work

Tools worthy of your attention

ccusage daily report for Claude Code, 15 to 18 October 2026, the last frame of the recording — **ccusage** · know what you burn · Claude Code only, 15 to 18 Oct 2026, recorded · project

rtk gain report — **rtk** · burn less · 43.3M tokens saved on the author's machine · project

**cliproxy** · choose what burns · project

**codex** · the second opinion · project

**opencode** · many models, one TUI · project

**dcg** · the last wall, rm -rf blocked · project

Measure, reduce, route, cross-check, and guard. The project link is below each card. Each one installs in minutes.

Part III — Make it work

Where agents live, AI ecosystems

Claude Code in the terminal — **terminal** · the native habitat · everything in this talk ran here

Zed agent panel — **Zed** · agent panel, external agents over ACP · zed.dev

VS Code agent mode — **VS Code** · same loop, familiar chrome · docs

The editor is a matter of comfort. The harness below it is the same machinery.

Part III — Make it work

An environment that works

Essentials

a terminal you like
a ten-line tmux configuration: the mouse on, a good prefix, deep scrollback
a notification hook, so you do not watch the agent to know it finished

Optional

git worktrees or jujutsu (jj) for parallel work
dotfiles under version control, so the setup reproduces

Advanced setups exist. Add them after the minimal setup works

One documented minimal setup that works is better than ten clever setups that might work. A tmux configuration that fails, and we repair it here.

Part III — Make it work

Parallel agents need parallel working copies

git worktrees: one branch, one directory, and one agent · no agent interferes with another
jujutsu (jj): a colocated interface over git. It snapshots the working copy at the start of every jj command, and its operation log can undo any operation, and its workspaces are parallel copies
The pattern: one agent per working copy, human merges at the boundary
agent teams (experimental): sessions share one task list and message each other · one session leads · one teammate per working copy

docs · agent teams · experimental · flag CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

The project folder for this deck runs colocated jj over git. The parallel agents that built this deck worked in that way.

Part III — Make it work

How jj handles agent work

A conflict is data: jj records it in the commit, and the rebase succeeds. No --continue
jj workspace add: one working copy per agent, so agents can edit the same line independently
Colocated: .jj/ sits next to .git/, so tools that expect a Git repo still find one · make changes with jj

Both sides replayed from real runs, git 2.54.0 and jj 0.46.0 · docs: conflicts · git command table · git compatibility

Part III — Make it work

GitHub ceremonies

One real PR, replayed from GitHub. The track and ledger follow the same events.

Source: the real PR, GitHub timeline, reviews and comments, July 26 to August 1, 2026. Names are generic. This PR merged without an owner seal.

Part III — Make it work

Subagents help divide the work and the context

A subagent starts fresh: its own prompt, the task, CLAUDE.md. A fork copies this conversation
Either way, only the result returns
Use subagents for investigation and review. Keep sequential edits in one thread
Each one spends its own tokens: a fresh subagent warms its own cache, a fork reads yours

Fork mode is on by default: Claude can fork on its own · docs: subagents and forks · subagents and the cache

Part III — Make it work

Skills, and where they come from

LIVE · custom agent vs bare fetch, same question

A skill is a teachable capability kept out of context until needed
The tooling stages, deploys, and verifies each skill, and writes a provenance record for each deployed file
When an instruction causes a fault, you can find its origin
An agent definition adds a fixed format, source verification, and a way to refuse. The same model without the definition only copies text

--- name: pr-summary description: Summarize changes in a pull request context: fork agent: Explore allowed-tools: Bash(gh *) --- ## Pull request context - PR diff: !`gh pr diff` - PR comments: !`gh pr view --comments` - Changed files: !`gh pr diff --name-only` ## Your task Summarize this pull request...

One markdown file is the complete skill. The frontmatter declares the agent and the tools it may run without asking. Each gold !`…` runs a shell command before the skill reaches the model, and the command's output takes its place: docs · inject dynamic context.

Part III — Make it work

The frontier, priced

Every published row of CursorBench 4.0. The gold Pareto frontier marks the best score at each price.

Jev · typed decisions, no code · no CursorBench score · $0.042 / M input tokens

Sources: cursor.com/cursorbench, CursorBench 4.0, fetched 2026-10-20 · cost per task applies each model's published token prices to the tokens it used · Jev: TypeSafe launch post, Sep 15, 2026

Compare: Slopalytics plots cost per task against an intelligence index, with a Pareto line. Data: Artificial Analysis.

Part III — Make it work

Choosing the right model

A /model switch mid-session busts the prompt cache. The next turn pays full price for the whole history.

Pick by task, once, at the start: the large model plans and reviews, the fast model edits
Route without a switch: a subagent runs its own model and leaves your cache intact
opusplan is a switch too: each plan-mode toggle changes the model and starts a fresh cache

A cache write costs 1.25x the base input price (5-minute cache) or 2x (1-hour). A hit costs 0.1x on most models, 0.05x on Opus 5.5 and Sonnet 5.5, and 0.025x on Fable 5.1. Sources: prompt caching, API · prompt caching, Claude Code

Part III — Make it work

Models and harnesses route independently

One task, and both models are correct, but their characters differ. One explains and teaches. One is short and defensive
Route the work by character
A review across vendors reduces correlated errors. You must still check the agreement

Part III — Make it work

Trust nothing, measure

24 particle-physics questions, 10 runs each: 240 answers per model. A script checks every answer. No model grades another.

source: local benchmark dashboard, suite tier1-physics, run m1, 28 July 2026, run locally · method: the test plan · the dashboard shows /480 because its data lists every answer twice. The rates are the same.

Part III — Make it work

One artifact, two review depths

quick passone council, 12 minutes

“unusually accurate”

the full timeline verified

adversarial roundsthree rounds, 15 minutes more

11findings survived

nine established, two likely

~~4 weak accusations~~ removed

Examples since corrected: propellant 85% vs 92% · moonwalk photo called a splashdown party · “as transmitted” over [a] · planned 195 h 19 m vs 195:17.

Review decay, another review: R1 found faulty loop code. R2 added five fixes. R3 found no new defects.

Unpublished sources: Apollo council record, 29 July 2026, four specialists, three rounds. Ten of the eleven are fixed. The coast label now says 1.8 rev. The council found about 1.73. Review decay: a review of an earlier draft of this talk, 28 July 2026. Make each reviewer pay for a wrong accusation.

Part III — Make it work

Security review: a pipeline, stage by stage

One pinned commit, one primary review, a panel whose members cannot see each other, and a reconciler that checks every verdict against the source.

Schematic. Reviewer outcomes are illustrative. No report is linked. The report format is the OASIS SARIF 2.1.0 standard, read 21 Oct 2026.

Part III — Make it work

Operating habits

Start with the standard setup. Add an instruction only after you see a failure, because each prompt is a debt
Fresh threads: one concern per session
Plan mode: approve the route before the edits
Esc and rewind are normal operations. Use them as often as necessary
Examples: one good example is better than a longer instruction
Know the mode of your model. Reasoning on and reasoning off are two different tools with one name. The latency differs, and the character differs

auto-accept removes permission prompts for speed. Hard deny rules and the sandbox still apply

Part III — Make it work

The four objections, and where they landed

“our code leaves the machine”

Name the boundary

Code can reach the model provider. The allowlist limits destinations. Listed destinations receive the data the agent sends.

Egress ↗Provider terms ↗

“AI code
is slop”

Verify the change

Read the diff. Verify it with trusted tests. Apply the same CI checks to every change.

Review funnel ↗Trusted tests ↗The same CI ↗

“it deskills
engineers”

Practice verification

You remain accountable. Write tests and probes that could prove the model wrong.

Verification ↗Skill map ↗

“it's hype”

Inspect the evidence

The early demos combine known work. The CursorBench chart compares scores with average cost per task.

Cost and score ↗Known work ↗

The linked deck sections supply the evidence for each answer.

Part III — Make it work

Managed AI environments

Agents in contained sessions.

Public reference · anthropics/claude-code dev container

# one container, one egress firewall $ git clone \ https://github.com/anthropics/claude-code # VS Code: Reopen in Container $ claude # inside the container

A practice task

A tiny tip-split utility has a rounding bug.
Make the per-person charges sum to the bill.
Add a check.

Other harnesses can run in the same container.
The firewall does not change.

Reference shape, not a recording. Sources, read 21 Oct 2026: the reference dev container with its egress firewall · bubblewrap in the Claude Code sandbox on Linux · the bubblewrap README.

Part III — Make it work

The broker

Keys stay out of the cage.

Who holds what	The cage	The broker
GitHub token	No GitHub token	The broker keeps it here
Scoped key	The session holds this key	The key allows only the reads the policy lists
Write policy	The scoped key cannot change it	A write needs human approval

Without a scoped key, the session cannot call the broker.

Pattern, not a recording. The table shows who holds which credential.

Part III — Make it work

Prove it

Test each wall alone. A check you did not run is not evidence.

Write these checks for your own cage. Each one must fail when its wall is removed. Sources, read 21 Oct 2026: the non-root user, the managed settings file and the firewall in the dev container docs · the bubblewrap README.

Part III — Make it work

Adopt in layers

Choose a layer. Keep its check.

Each layer stands alone.Adopt any subset.

Layer	What to add	Done when
SettingsNo container	deny rules and a sandbox allowlist in `settings.json`	The `.env` read is denied. The off-list `curl` is blocked.
HooksEvery call, every commit	`dcg` as a PreToolUse hook `gitleaks` in prek	`rm -rf` is blocked before the shell. A planted fake key fails the commit.
The cageDev container	the reference dev container with its egress firewall	From inside, an off-list host fails and a listed host answers.
The brokerOutside the cage	tokens live in a broker outside the container	`env` inside shows no code-host token. A write waits for a human.

Install: a real terminal, and Docker for the cage.

Broker: you bring your own tokens.

Sources: Claude Code docs, settings and dev containers · dcg · gitleaks

Part III — Make it work

claim → artifact → check → contradiction → iterate

You saw the loop: the one-screen agent, the invented citations, the denied reads, the reviewed diff. That loop is the complete method. Use it on your next PR.

Part III — Make it work

Next steps

Deny and allowlist today · add the deny rules and a sandbox allowlist, then rerun the two denials
Move one rule from prose to a hook · the scan that matters runs on every commit
Review before you author · run a read-only review on your next PR and check each finding
Measure one claim · a script checks the answers, and no model grades another

start with one layer and its check

Each step links to the slide that shows it.

Part III — Make it work

References

Claude Code docs · settings, hooks, permissions, best practices, large codebases
agents.md · the portable instruction-file standard · zed .rules as an example
claude-code-reverse · the loop, reverse-engineered
GHSL, preventing pwn requests · CISA on CVE-2025-30066
ccusage · rtk · CLIProxyAPI · dcg
jujutsu · git worktrees · agent teams

MIT Missing Semester · the agentic-coding lecture
GitHub · developers own the merge button
AI Coding Dictionary · a glossary to compare with ours (AI Hero)
rune · the ontology our glossary maps to, github.com/runedeck/deck
codex · opencode · Zed · VS Code

Benchmark numbers quoted from CursorBench 4.0, fetched 2026-10-20. All materials and prompts: this repo.

Part III — Make it work

Glossary

The words the day leaned on, in the words the slides used.

modela frozen set of trained numbers that predicts the next token

tokenone piece of text with an ID that selects a row of the token table

context windoweverything the model can read for one request, of a fixed size

attentioneach token weighs itself and every earlier token

hallucinationconfident output that is false, or drifts from its source

agenta model in a loop that can use tools and check its own work

harnessthe code and system prompt around the model: context, tools, permissions, state

system promptinstructions the harness puts at the start of every request

tool callstructured model output that asks the harness to run a tool

compactionthe history replaced by a model-written summary to free space

permissiona rule that allows, asks about, or denies a tool call

sandboxan isolated environment for what runs and where: OS boundary, container, or VM

hookyour code at a seam of the loop, before or after a step

skilla capability kept out of context until the agent needs it

subagentan agent started in its own context that can start its own, only its result returns

MCPa protocol that connects a harness to external tool servers

The full glossary, every term with the slides that use it: glossary.html, generated from the deck's own ontology, talk.ttl. Click a term to open its entry. Compare the terms with the AI Coding Dictionary. Some definitions may differ. Terms that rune also defines link to the rune ontology.

❯ Hey, Fable, find mistakes in my PhD thesis

AI Tools in Practice

See it work

You probably know AI as a chat window

What's a model

Context window

Agents

The whole agent on one screen

AI is not just a thing that you stuff into your apps. AI is a thing that changes how you use a computer.

One prompt

Same request, different results

Also one prompt

Models excel at redoing what's already been done

How do we build what's not out there?

How do you harness the power?

Fan-out

Computer use

How it works

The only thing a model does is …

Tokens

What's model attention?

One request

From chat to harness

Three disciplines

Inside the model

Training

How training works

When the loop stops

Inside a tool call

Artifacts

Key concepts

Claude Code

Compaction

Models lie confidently

The boundaries stack

Permissions

The sandbox

The egress cage

Hooks

The same hooks in multiple harnesses

Guarding against dangerous commands

OpenCode

Using all the guard rails

Make it work

Instruction files advise, hooks enforce

Start small

Vibecoding, honestly

Where agents move people on the map

How much care does this code deserve?

Authenticity theater

The new division of labor

Find the bugs in my PR

Disagreement

One claim, one source, one verdict

Fan-out

Secrets hygiene and CI parity

Where your code goes

Tools worthy of your attention

Where agents live, AI ecosystems

An environment that works

Parallel agents need parallel working copies

How jj handles agent work

GitHub ceremonies

Subagents help divide the work and the context

Skills, and where they come from

The frontier, priced

Choosing the right model

Models and harnesses route independently

Trust nothing, measure

One artifact, two review depths

Security review: a pipeline, stage by stage

Operating habits

The four objections, and where they landed

Name the boundary

Verify the change

Practice verification

Inspect the evidence

Managed AI environments

A practice task

The broker

Prove it

AI is not just a thing that you stuff into your apps.
AI is a thing that changes how you use a computer.