tl;dr I now learn hard technical topics by pointing tens and sometimes hundreds of AI agents at a topic and running them through a research pipeline with strict rules. The result becomes a document I read and a podcast-style audio version I listen to in the car. I read when I can sit down and focus, and I listen when I can’t. This is how I learn now, and it brought back the deep learning I had lost to having less time.

Why

I’ve been building software for more than twenty years, about twelve of them also protecting mobile applications. For a long time, learning was what I did with my free time. I spent a lot of it reverse engineering iOS applications, which is how I learned how developers commonly build them, and I read other people’s writeups. I started random iOS projects to keep up with frameworks that never stop changing. Then I would write a post for future me, because my memory is not good and the post is how I refresh the steps later.

I have less time now. My learning curve had gone almost flat, because I didn’t have the time to go deep on any new topic. For someone who loves learning, that is a bad place to be.

This setup brought the deep part back. I pick a topic, agents research it under strict rules, and I get a document to read and an audio version to listen to. It feels like a course tailored to me on whatever topic I pick, and like having a dedicated research team for any topic I don’t know yet. It also reignited my love for learning.

The tools

I run the agents with any of these:

• Claude Code, Anthropic’s AI coding agent that runs in the terminal.
• Codex CLI, OpenAI’s lightweight coding agent for the terminal.
• A custom harness I built on the Strands Agents SDK, an open-source SDK for building AI agents, in Python and TypeScript, that covers multi-agent orchestration.

Their job here is the same: fan out tens and sometimes hundreds of agents over a topic and push them through the pipeline below. Each agent gets its own prompt and a narrow job. The pipeline is the same whichever of them runs it. The rest of this post is about the text every agent receives and what each stage does with it.

The three blocks

Every agent in the pipeline gets the same three blocks pasted into its prompt, so I define them once per topic and every drafter, judge, critic and refuter reads the identical text.

• <sources> lists the absolute path of every file the work must obey, one line each, saying what that file is the copy of record for. “Copy of record” means that file wins when files disagree about a fact.
• <rules> holds the hard constraints, the ones whose violation is a high finding later: style bans, confidentiality, which file wins on facts, how external claims get tagged, and what may never be invented.
• <spec> describes the deliverable: the required sections in order, a length ceiling per block, the format, and the output path.

Some terms need a plain explanation. A high finding is a problem serious enough that the document is not done until it is fixed or refuted. A tag on a claim says which source it came from and whether that source reports the fact or only proposes it.

The skeleton looks like this:

<sources>
/absolute/path/notes.md     : copy of record for every fact about <topic>
/absolute/path/tools.md     : copy of record for tool names and links
/absolute/path/examples/    : copy of record for voice and conventions
</sources>

<rules>
- style bans: <banned characters and words>
- confidentiality: <what may never appear>
- which file wins on facts: <file, by kind of fact>
- tagging of external claims: <how a claim carries its source>
- what may never be invented: <numbers, names, quotations, outcomes>
</rules>

<spec>
- sections, in order: <heading>, <heading>, <heading>
- ceiling per block: <words>
- format: <markdown with frontmatter, or whatever the form needs>
- output path: <output path>
</spec>

Everything in angle brackets is filled in per topic. Every later stage measures the document against the rules and the spec. When a critic says a claim is unsupported, it means unsupported by <sources>, and nothing else.

The research pipeline

The whole system has three phases: research, artifacts and consuming. Research is six stages run in order, then a pass I do myself. Drafts get judged, the winner absorbs the best parts of the losers, critics attack the file, refuters attack the critics, and a fixer applies what survived. Several stages give an agent a lens, meaning the point of view it is told to take. The model policy is one model tier throughout, with judges and refuters at higher reasoning effort and the rest at default.

1. Draft

Three agents run in parallel, none writing to disk, none seeing the others. Each writes a complete deliverable on the topic from one lens and returns it as text.

• The audience lens is the person who will consume the result. Every part must be something that reader can use and verify; anything they could not check or would not remember gets cut.
• The fidelity lens is the keeper of the facts in the record. Every claim, number and quotation must trace to a source and carry its tag, and where a source proposes rather than reports, the draft has to say so.
• The craft lens is an expert in the form, such as a speech, a design doc or a lab protocol. It builds the structure so it can be recalled under pressure, makes every budget real, and tests each block against the constraint: time, length or reading level.

When the task is a revision of an existing document, this stage is skipped.

2. Judge

Two agents run in parallel and return structured output, meaning a fixed shape instead of free text. Each scores every draft on five criteria: fit to the constraint, whatever quality matters most to that audience, fidelity to the record, consistency with the existing documents it must agree with, and the rules.

The judges take different stances. One judges as the audience, the other as the auditor of the record. Each returns a winner, a score per draft with its worst problem named, and a graft list: the specific parts of losing drafts that beat the winner’s version of the same part. That list is what gets pulled into the winner in the next stage.

3. Synthesize

One agent, and it is the only stage so far that writes to disk. It starts from the winning draft, grafts in every part the judges listed, and fixes every worst problem they named. Then it re-reads the whole thing against the rules and the spec, recounts every measured block, greps for the banned characters, and writes the file to the output path. It returns a five-line report: the path, the size, the largest block with its measure, which draft won, and what it grafted.

For a revision task there are no drafts to merge, so this becomes a Write phase: one agent writes the revised document directly from the sources and the spec.

4. Critique

Three agents run in parallel, each reading the written file and returning structured output. A finding carries a severity, a location (the section plus the first six words of the offending line), a claim, evidence, and a fix. They are told to report only real problems.

• The facts lens checks every claim against the sources, every quotation verbatim, every number against the allowed numbers, every confidentiality rule, and anything invented. A wrong fact or a missing tag is high.
• The audience lens reads as the audience, measures every block itself, tests each block for the elements the audience needs, and checks that nothing contradicts the existing documents. A block over budget or a contradiction is high.
• The conventions lens checks banned characters, date and voice rules, structure against the spec, consistency with sibling documents, and any place the draft reintroduces something a revision removed. Any banned character is high.

5. Refute

Every high finding gets two agents, in parallel, with structured output, whose job is to prove the critic wrong. Each reads the file and the sources itself and checks the exact location before deciding. Refuted means the problem is not in the file, or the sources show the critic is wrong about the rule or the fact. A finding survives unless both refute it.

There is a cap on how many findings get verified, and anything past the cap is logged as overflow so nothing is silently dropped.

6. Fix

One agent edits the file in place. It resolves every confirmed high and every medium whose fix is clearly right. It may skip a medium only if applying it would violate the rules or the spec, and it has to say which. Refuted findings are ignored, and it never fills a placeholder with invented content. Then it recounts every block, greps for banned characters again, confirms the structure, and reports what it applied, what it skipped and why, and the final measures.

Adding up the stage counts, a run through the six stages uses ten agents, plus two for every high finding.

The operator’s pass

This one is me, not an agent. I sweep the file for banned characters, recount the blocks, spot-check a handful of claims directly against the record, and read the whole thing once as the audience. The reason is a class of error the agents cannot see: a rewrite that satisfies every rule and still changes what a sentence implies. Every stage above checks the text against the rules. None of them knows what I meant.

Artifacts

The research result goes to the orchestrator, the agent that ran the pipeline. It writes the final document, the one I actually read. More importantly, it also writes a podcast-style script.

The script goes to Gemini Notebook, an AI research and note tool, where I generate an Audio Overview from it. Depending on the topic and how deep I want it to go, I pick the Default or the Long length. I aim for Default scripts at around 30 minutes and Long scripts at around 60 minutes. If a topic is too complex for that, I split it into multiple episodes.

The script does not skip the checks. Rewriting a document as a podcast is a chance to lose an important detail or add an inaccurate one, so the script goes through a compressed version of the research pipeline before I generate any audio. The point is that no important detail is lost and nothing inaccurate is added.

Consuming

The last phase is the point of all of it. The written document is for the moments I can sit down and properly focus. The audio version is for the car, for walks, and for exercise time. The same research reaches me in whichever form the moment allows, which is the whole trick for learning with less time than I’d like.

What is not perfect

It’s not a perfect system. There are no deterministic tools in it, only agents, even for the greps and the recounts, and there is potential for hallucinations throughout. Every stage is a model reading text and writing text, so every stage can be wrong, including the ones whose job is to catch the others being wrong.

I do the operator’s pass myself, and I’m not a deterministic tool either (ask anyone that knows me haha). I hope this process just keeps improving. Until then, I read every document knowing an agent wrote it, and I still check it myself.

This post

This post went through the same research pipeline described above: the six stages and then my own pass. The sources were my hand-written posts on this site, for voice; my notes describing the workflow, for facts; a rules file with the hard constraints; and a spec file with the sections, ceilings and format. The real numbers from the run follow.

Ten agents ran: three drafters, two judges, one synthesizer, three critics and one fixer. The two judges disagreed on the winner, one picking the audience draft and the other the fidelity draft, with all three drafts within two points of each other on the combined score. The tie-break sided with the audience judge, and the synthesizer grafted twelve parts from the two losing drafts into that one. The critics raised eleven findings: zero high, five medium and six low, so the refute stage had nothing to verify. The fixer applied every medium and skipped none. The run took about 38 minutes, 243 tool calls and about 1.5 million tokens. In my own pass the sweep for banned characters came back clean, every block was under its ceiling, and I changed three sentences and wrote this paragraph.

That’s it. If something here is wrong, or you have a better setup for learning with less time, let me know on twitter @ivMobAppSec.