1. I'd Rather Be Writing
2. AI
3. Agent skills

Advanced patterns: subagents, loops, and reverse engineering

The patterns in this article are ones I’m still exploring. They push beyond basic skill building into more experimental territory — subagent architectures, recursive loops, and reverse engineering skills from outputs. I include them here because they hint at where skill design is heading, even if I don’t have all the answers yet.

Subagent architectures

One pattern I’m just now exploring is using subagents within skills. When you interact with an agent, you’re talking to a single agent with a single context window. But that agent can spawn subagents — separate agents with their own fresh contexts — to handle specific tasks. When the subagent finishes, it reports back to the main agent, which synthesizes the results and communicates them to you.

The most compelling use case I’ve found so far is fresh-context QA. Here’s the idea: after your main agent finishes a complex task (like writing release notes), you have it spawn a subagent with a completely clean context — no history of the edits, no memory of the reasoning behind the changes — and ask that subagent to perform quality assurance on the output.

Why does this matter? Because an agent that did the work has an inherent bias toward its own output. It made specific choices and has reasons for each one. When you ask that same agent to review its own work, it tends to see fewer issues. A fresh subagent doesn’t carry that bias. It reads the output cold and evaluates it on its merits, which typically produces more rigorous QA.

In a skill, this might look like adding a final step:

Spawn a subagent with no session history. Provide the subagent with the output files and the original requirements. Ask the subagent to evaluate the output for accuracy, completeness, and adherence to the style guide. Report any issues back.

The swarm concept

Taking subagents further, some people are building “swarms” — many agents working together autonomously. I recently saw a demo where a product manager had built agents representing developers, QA engineers, UX designers, and release managers, each trained with role-specific skills. One agent finishes a task and hands it off to the next, executing a complex workflow.

I’m still wrapping my head around whether swarms make sense for documentation workflows, but the concept is worth tracking. As you design skills, keep the subagent architecture in mind for one practical reason: sessions degrade as tokens pile up. When your conversation approaches the token limit, the system compacts earlier history into summaries, meaning the agent has increasingly fuzzy memories of earlier work. For long, multi-step workflows, breaking tasks into subagent calls — each with its own clean context — can keep performance high throughout the process.

Recursive subroutines

Another pattern I find interesting is recursive subroutines. A recursive subroutine executes through a series of steps and only finishes after some condition is fulfilled:

1. Complete steps 1 through 3.
2. Check to see if the condition is fulfilled.
3. If so, continue to step 4.
4. If not, repeat steps 1 through 3.

This pattern works best when the success condition is concrete and measurable. For example:

• Link validation: Check that all links resolve to 200 HTTP response codes. If not, fix the broken links, rebuild the output, and check again.
• Readability targets: Check that a document passes a desired Flesch-Kincaid reading level. If not, simplify the language and re-check.
• Build errors: Run a build, check for errors, fix them, and rebuild until the build succeeds.

The pattern is murkier with subjective evaluation. “Is this document good?” doesn’t have a clean pass/fail condition. But you can approximate it by breaking “good” into measurable proxies — link health, reading level, style guide compliance — and looping on each one individually.

In a skill, you might write this as:

Step 5: Validate links

Run the link checker against the output directory. If any links return non-200 status codes, fix the source content and re-run the link checker. Repeat until all links resolve successfully, up to a maximum of 3 attempts. If links still fail after 3 attempts, log the failures and continue.

Note the escape hatch: “up to a maximum of 3 attempts.” Without a limit, a recursive subroutine can loop indefinitely, burning tokens on a problem it can’t solve. Always include a maximum iteration count.

Reverse engineering a skill

The last pattern I’ve been wondering about is reverse engineering. Instead of writing a skill from your knowledge of the process, what if you worked backward from a known-good output?

1. Examine this output. This is the result I want you to achieve.
2. Now here’s the input. This is all you have to go on.
3. Create a skill that will transform the input into the output.
4. Spawn a subagent to perform the skill. The subagent isn’t allowed to view the desired output — it must rely entirely on the skill instructions.
5. Have a third agent (acting as a judge) compare the subagent’s output to the desired output.
6. If the outputs closely match, the skill is good. Otherwise, refine the skill and repeat.

This is essentially test-driven skill development — you define the expected output first, then iterate on the skill until it produces that output reliably. I haven’t fully tested this approach, but the logic is sound: if a skill can reliably transform input to output without the agent ever seeing the answer, then the skill itself captures the necessary knowledge.

The approach connects back to testing: if you can express your desired output as a set of eval criteria, you have a natural eval suite built into the skill development process itself.

Activity: Capstone — add an advanced pattern to your skill

For the final project activity, extend your Javadoc editing skill with one of the three patterns from this topic. Each option is a single prompt — pick whichever intrigues you most.

Option A: Fresh-context QA subagent. Paste: “Add a final step to the edit-javadoc-comments routing skill: spawn a subagent with a clean context, give it only the edited files and the two reference files, and have it audit the edits for convention violations and overreach. Then run the skill on a fresh copy of CoffeeMaker.java and show me what the subagent’s audit caught.” For comparison, also ask the main session to review its own work — the fresh-context reviewer usually finds more. That’s the self-review bias from this topic, playing out on your own skill.

Option B: Recursive validation loop. Paste: “Add a loop step to the routing skill: after editing, run scripts/verify_code_unchanged.py; if any code changed, restore the file and re-edit; maximum 3 attempts, then log the failure and stop.” If you have a JDK installed, tell the agent to use javadoc -Xdoclint:all as the loop condition instead — doclint catches broken {@link} references and malformed HTML with compiler-grade authority. (Curious about generating Javadoc output? My activity on generating a Javadoc walks through it.)

Option C: Reverse engineering. Paste: “Produce a golden version of CoffeeMaker.java with the comments edited perfectly, and let me approve it. Then spawn a subagent that gets only the original seeded file and the skill — never the golden version — and have a judge compare the subagent’s output to the golden file. Report the differences, refine the skill, and repeat until they converge.” If your skill can reliably reproduce output you approved without the agent ever seeing it, the skill has fully captured your editorial judgment.

Where you’ve ended up

If you’ve done every activity in this course, look at what’s sitting in your project directory: a routing skill composed of three modular sub-skills, hardened against curveballs and traps, verified by a mechanical safety script, forked once for another language, licensed for sharing, and backed by an eval with a measured lift score. That’s not a toy — it’s the full lifecycle of a production-quality skill, and it’s the same lifecycle whether the skill edits Javadoc comments or drives your release docs process.

Now go back to the top-three candidate list you drafted in the when to build a skill activity. Pick the first one and start building — this time on a task that pays you back every week.

---

Continue to the next chapter: Product skills — skills built not for your own authoring tasks, but for the AI agents consuming your documentation.

Comment on LinkedIn