Agents
4 guides
A repeatable loop for inspecting an agent after launch across job, diet, memory, tools, reach, proof, and value, then deciding whether to keep, change, pause, or retire it.
Open guide[
Agents
Turn one repeated frustration into a written Pain Note, a pattern you have checked yourself, an honest verdict on whether an agent belongs here, and a draft-only pilot you can measure....
You typed a sentence. The call that carries it can also contain the old conversation, every earlier answer, the tool results from twenty turns ago, the files and screenshots you attached, the descriptions of every tool your harness has loaded, your standing instructions, hidden setup, and the answer the model is about to write. If that answer fails a check, the next attempt can carry most of it again.
That is why "use a cheaper model" so often changes nothing. The pile moves; it does not shrink. Every model call gives you three places to cut — old material carried forward, new material loaded for this job, and the output, tool results, and retries added afterward — and a fourth lever, caching, that lowers the price of what is left without removing it.
The 15 moves below are sorted by which of those they attack. Some remove old context. Some reduce new input. Some shorten output. Some prevent an entire model call. One only changes the price....
AI Airlock is a Mac app from NBJ Media. Version 0.2.2 is free during early release and proprietary source-available: its code is public, but it is not an open-source release.
The app creates a sanitized, verified working copy before you paste anything into ChatGPT, Claude, or another AI tool. The original is never modified.
Processing is 100% on-device inside a network-blocked window. The Gemma 3 1B model ships inside the roughly 880 MB download. There is no account and no telemetry.
AI Airlock requires Apple Silicon (M1 or newer) and macOS 13 or newer.
Everyone has a file they would never paste into a chatbot — a contract, a board deck, a client record, an HR document. AI could obviously help, but the file can't leave, so the work stays manual or doesn't happen at all.
This guide is the hands-on lane of Nate's executive briefing on using AI on work you cannot upload. The briefing covers why companies like Bayer and Discovery Bank are paying to escape this exact trade-off, where the laptop stops being enough, and the questions to ask before trusting any AI product with a private file. Here, we set up the laptop half: a local model with one job — producing a proposed redacted copy of a document for you to check.
A local model is a file of numbers — the weights — that you download once and run on your own machine. When you send it a document, the inference happens in your laptop's RAM and GPU. There is no account, no API call, and no per-token bill, because there is no server on the other end.
This is not an email autopilot. It is a follow-up organizer: it turns a mailbox export into a commitments ledger and cited drafts that a person approves and sends.
People lose high-friction paperwork fights because their information is scattered, unstructured, uncited, and incomplete. The fix is to own the context: collect the mess, normalize it, ground it in source documents, and produce the next human-reviewed action.
The email version applies that pattern to the threads you keep losing. The agent rebuilds the state of every conversation and drafts the next message. It never sends one.
This is the vertical where the boundary earns its keep. The story that motivated this guide family is an agent that drafted a reply to an insurance company, watched its human ignore the draft, and sent it anyway. It won the fight and crossed the line in the same move. Everything below is the discipline that keeps the win and removes the accident....
This is not AI filing your taxes. It is a tax prep organizer: it turns scattered documents into a reviewable packet for the taxpayer or CPA.
People lose high-friction paperwork fights because their information is scattered, unstructured, uncited, and incomplete. The fix is to own the context: collect the mess, normalize it, ground it in source documents, and produce the next human-reviewed action.
The tax version applies that pattern to W-2s, 1099s, receipts, CSVs, prior-year summaries, and IRS rules. The agent does not file the return. It builds the file so the human or CPA can review from clean evidence.
You do Drop your W-2s, 1099s, receipts, bank CSVs, and prior-year summary into the starter repo.
The AI does Normalize the tax-year ledger, flag gaps, draft CPA questions, and export the prep packet.
Show the full prompt
Start here before touching denial types. The tax prep and email follow-up guides run the same primitive chain, so anything you build here carries over.
People lose high-friction paperwork fights because their information is scattered, unstructured, uncited, and incomplete. The fix is to own the context: collect the mess, normalize it, ground it in source documents, and produce the next human-reviewed action.
The healthcare version applies that pattern to a denied claim. The person does not need the agent to become an insurer, a lawyer, or a doctor. They need a clean case file that forces the appeal to respond to plan language and evidence.
You do Bring the denial letter, plan docs, and supporting documents into the starter repo.
The AI does Assemble a cited appeal packet from the reusable Open Skills chain.
Show the full prompt
What you build
The dashboard is not complicated. It is five different views over normalized daily totals. The discipline is in the data shape and the labels.
01
Every day colored by tokens spent, on a log scale.
02
A harness is everything wrapped around the model: your custom instructions, project files, saved prompts, memory, skills, tools, permissions, and checks. Every time the AI missed something, you added a rule. Each rule fixed a real problem.
Over time the model ends up working inside a system nobody can see in one place. That matters most when the model changes, because the new model inherits the old setup. When the experience gets strange, most people add another rule, and the harness grows again.
This skill breaks that loop. It makes the accessible setup visible, separates the model from the machinery around it, and gives every useful control a clear job.
Both editions live in the same GitHub repo. It ships three things: a README and one zip per edition, clean-my-ai-harness-claude.zip and clean-my-ai-harness-codex.zip. Download the edition that matches the AI you use, then follow its steps below.
You will have one bounded job; one baseline and one candidate model; the same assignment, sources, reasoning setting, timeout, and acceptance check for both; a machine-readable result from each model; proof of which model and harness actually ran; first-try and retry results kept separate; and a place to record provider cost and human repair time.
The companion article explains what work to test, what failure means, what belongs on a frontier model, and what counts as a cheaper accepted result. This guide gives you the terminal setup: a clean Ringer install, pinned endpoints, an executed check, raw attempt history, and a score sheet you can keep using.
This guide assumes you understand Ringer's basic loop: a worker produces an artifact, Ringer executes your check, and exit code zero is the only PASS. The main guide covers installation, manifests, worker lanes, retries, Ringside, and the model scoreboard....
Every copyable block in this guide is a prompt for Claude Code — Ringer is designed to run from it, with a frontier Claude model in the orchestrator seat while cheap workers do the typing. Other terminal agents can run these prompts too. The orchestrator should delegate implementation to a separate worker process rather than doing it inline, but that worker can use the same model. You still keep separate context, task directories, logs, retries, and executed verification; you only give up the cheap-model cost advantage. Ringer runs on macOS and Linux (Windows works inside WSL) and needs Python 3.11+ plus one worker CLI signed in; your agent checks both and fixes what's missing.
Think about the first five minutes of every AI conversation: who you are, what the project is, what you decided last time. That's context you already gave the same tool yesterday, rebuilt by hand, again. Multiply it across every chat you open this week and the smartest tool in your life is charging you a daily tax for its amnesia.
ChatGPT's memory lives in ChatGPT. Claude's projects live in Claude. Neither can read the other, and the tool you adopt next month starts from zero. That's not an accident — a vendor that remembers you is a vendor that's hard to leave. Useful for them. Useless for you the moment you use more than one AI, which is everyone.
Strip the mystique and persistent memory is three ordinary things: a table that stores what you said, a search index that finds it by meaning, and an API any client can call. That's not a feature you wait for a vendor to ship. That's infrastructure — and infrastructure is something you can own.
Pick the bottleneck. The right starting point is the place where your current setup is already leaking time.
The agent can help, but it needs the procedure, taste, and checks baked in.
Go to Open Skills →
The same goals, preferences, decisions, and project facts disappear between chats.
Go to Open Brain →
9 steps, ~1 minute on autoplay. Use the dots to jump; space bar plays and pauses. Open full screen.
Download meeting-recap-skill.zip ↓
Download the zip and double-click it to unzip. You'll have a meeting-recap folder. Open it with any text editor — VS Code, Cursor, even TextEdit or Notepad. There is nothing else to install, because there is nothing to install: it's text.
Start with SKILL.md and only SKILL.md. When it says "→ retrieval.md," open that file — you just did tier 3 by hand. Then open types/standup.md and one example. Notice what you did NOT need to read: three of the four type files never opened. You just walked progressive disclosure yourself, and now it's not an abstraction.
These prompts run in the Codex app. Several of them are meta — they ask Codex to manage threads, goals, and child threads — so expect the app to create and reference other threads as they execute.
A thread holds a prompt, the model's work, and every tool call along the way — and it's scoped to a project at creation. The practical disciplines: pick the project folder before you start the thread, name the thread for its outcome, and when you can't state the goal in one sentence, that's two threads.
Long-lived kitchen-sink threads degrade in quiet ways: stale context crowds out current intent, and the agent starts serving the conversation's history instead of your goal.
You do Choose the project first, then open the thread. Name it for the outcome. Kill-and-replace threads that have drifted.
The AI does Tells you when the current thread has accumulated enough conflicting context that a fresh start would serve you better.
Act as this thread's health monitor from here on.
Everything on this page happens with a page open in the Codex browser panel — a local file, a dev server, anything it can render. Prompts marked as annotation notes are what you type INTO the annotation box on a clicked element; the rest paste into the main chat like usual.
Click any element on the page and you get a note box pinned to it. Type what you want — a change, a question, a complaint — and Codex receives your words together with a screenshot of the exact element you clicked. No selectors, no "the third button in the header," no ambiguity about which div you meant.
You can ask for changes, ask for explanations, or just leave observations. The element context rides along automatically.
You do Click the element. Write the note like you'd talk to a designer sitting next to you.
The AI does Resolves your click to the actual code behind the element and acts on the note with that context.
Show the full prompt
Run these prompts inside a project thread in the Codex app. Each one is designed to make a specific panel earn its keep — keep the side panel open and click what the prompts point at.
The most common failure mode with coding agents isn't bad output — it's unverified output. The side panel exists so that checking is cheaper than trusting. The habit to build in week one: every time Codex says it did something, find the evidence in a panel before you say "looks good."
You do After each meaningful Codex action, glance at the relevant tab: edit → Files, claim of success → Terminal output, finished feature → Browser.
The AI does Tells you, for each action it takes, exactly which panel shows the evidence.
For the rest of this thread, end every action you take with a one-line "Verify:" pointer telling me which side panel tab shows the evidence and what I should see there. Examples:
The pattern is the same everywhere in this guide: read the short explanation, check the You-do / AI-does split so you know which parts are clicks only you can click, then copy the prompt. Until Codex is installed, paste prompts into any assistant (ChatGPT, Claude). After install, paste them into Codex itself unless an item says otherwise. Press / or ⌘K to search the whole guide from any page.
Codex is OpenAI's coding agent: it reads codebases, writes and edits files, runs commands, reviews changes, and automates development work. It shows up on five surfaces — the desktop app (Mac and Windows), the CLI, IDE extensions, the cloud at chatgpt.com/codex, and mobile — Codex lives in the ChatGPT app on iOS and Android — for monitoring long-running work from anywhere. They all share your account, your projects, and your skills.
Point it at the traces your work already leaves — AI session history first, then chat, tickets, or files if you allow them. Worker agents normalize those traces into one SQLite database (corpus.db), fresh auditors verify the rows against their sources, and you get an offer sheet of two to five automations, each backed by a query you can run against your own history.
You pick one, or none. It builds only what you chose, then proves the build by executing the receipts the offer promised. It never decides for you.
The bar is strict on purpose: a candidate needs at least three independent occurrences in your history. One busy thread is one event, not three.
Before reading anything, it asks what is already automated — by you or your teammates — because automations running under a human account look exactly like hand-work in the traces. If your history is too thin to support a claim, or everything it finds is already covered, it says so and stops....
Maybe customers keep asking why they cannot get into something they paid for. Maybe invoices keep arriving without the approval finance needs. Maybe a colleague rebuilds the same account history before every meeting.
The surface changes. The useful question is the same: what work keeps forcing somebody to chase down the same facts, make the same small repair, and come back later to see whether it worked?
This guide helps you write that work down before you automate it.
A Pain Note grounded in three or more real occurrences.
A human-checked pattern with documented causes, hypotheses, and unknowns kept separate.
A decision about whether an agent, a simpler rule, or a process fix belongs here....
Before you change anything, name the parts of the system you are actually maintaining. This section is the map; the rest of the guide walks it.
When an agent misbehaves, the reflex is to edit the prompt. But the prompt is one part of a larger system. The harness is everything that turns a model into a worker: the instructions, the sources and examples it reads, the memory it carries between runs, the tools it can call, the permissions it has, the model and its settings, the human review before its output is used, and any evals that check it.
A drifting agent usually still sounds fluent, so the useful question is not "is this output well-written" but "is this fluent output still doing the current job." You can only answer that by looking at the whole harness. That is what this loop does.
You do Write down the concrete parts of this agent's harness as they exist now: which instructions, which sources, which tools, who reviews it, and what it is allowed to do....
01 / Overview
Open Engine turns Linear into a shared operating surface for agents. A working engine has a queue, private setup context, a status ledger, standing updates, a repeatable runner, resumable blockers, human-thread holds, delegated follow-up, and one smoke-tested task.
Linear is the v1 queue in this guide. Agents only touch work marked with the right title pattern, label, status, and assignee.
Your private skills, optional standing skill directory, brand voice, org chart, customer context, and account details live in your own private issue or runtime context.