# Scaling Your Pokémon Team: When Your AI System Outgrows Its Original Design > Source: > Published: 2026-07-20 19:53:51+00:00 In [Part 1](https://dev.to/knmeiss/gotta-automate-em-all-pokemon-help-me-do-my-work-hal), I built a personal AI orchestration system: one orchestrator (Metagross) routes tasks to specialized agents. In [Part 2](https://dev.to/knmeiss/training-your-pokemon-my-ai-orchestration-system-k7p), I improved it by adding a circuit breaker, a shared journal, constructive tension between agents, and a harness to verify routing. Since then I've continued to make even more improvements. The rapid growth exposed problems I didn't anticipate, requiring infrastructure changes. My original agents covered my core workflow, but gaps kept showing up. Edge cases exposed tasks that didn't quite fit under any agent. I needed to add some new Pokémon: **Genesect** is a coding agent who writes code, debugs, explains stack traces, and does code review. **Scizor** is an adversarial code reviewer who does audits and checks for correctness. **Jigglypuff** helps with conference talks and CFPs, specifically talk structure, slide outlines, speaker notes, and Q&A prep. But now that I had even more agents, I found that Metagross, the orchestrator, couldn't reliably know what each agent could do from memory alone. Routing decisions were getting fuzzy, especially with edge cases. It couldn't always tell if, for example, the ask was a coding task or a research task. The fix was a capability registry, which is a `registry.json` file that Metagross reads at session start. Each agent has an entry with their capabilities and task types: ``` { "name": "genesect", "description": "Coding agent", "capabilities": ["write_code", "debug", "explain_code", "refactor", "code_review", "stack_trace_analysis"], "taskTypes": ["coding"] } ``` Now when a task is ambiguous, Metagross consults the registry instead of guessing. The routing logic is still in the prompt, but the registry is the source of truth for what each agent actually handles. Adding a new agent means updating one JSON file, not rewriting the orchestrator prompt. I also needed to extend the constructive tension pattern from Part 2 so that after Genesect writes code, Metagross automatically routes to Scizor for review before returning the result. The shared journal I added in part 2 was one of the best additions to the system. Agents write context when they finish, read it before they start, so handoffs don't lose information. The problem: it kept growing. By the time I noticed, `agent-journal.md` was over 240KB of prose. Every agent read the full file at the start of every session, resulting in my context window being half full before I even started. I made two fixes: ** query-journal.sh**: instead of reading the full journal, agents query it. They pass keywords, a date range, or a task type, and get back only the relevant entries: ``` bash query-journal.sh --keywords "react native sdk" --limit 10 ``` The journal protocol in every agent's prompt now says: *do NOT read the full journal file. Use query-journal.sh.* That one change cut context load significantly. ** archive-journal.sh**: a script that moves entries older than 7 days into monthly archive files ( `agent-journal-archive-2026-04.md` ). It runs automatically when the active journal exceeds 30 entries, and there's a monthly cron job as a backup. The active journal stays lean. Old context is preserved but out of the way.The archival script also prunes low-value entries from the archive. Research, analysis, review, writing, and planning entries are always kept. Purely procedural entries like environment setup, config tweaks, or build commands get dropped if they contain no learnings. For coding tasks, the script looks for value signals like bugs, root causes, design decisions, workarounds, gaps, limitations, and if none are present, the entry goes. I also added two supporting structures: ** state.json**: a shared key-value store for facts that multiple agents need to know and that don't belong in the journal. Current SDK version, active projects, known bugs. Agents read it instead of re-deriving the same facts from journal entries. It's a small file that stays current: ``` { "current_sdk_version": { "value": "0.23.6941", "source": "agent-journal.md — 2026-04-23T09:50-mew", "last_updated": "2026-04-23T09:50-05:00", "updated_by": "mew" } } ``` ** artifacts/**: a directory for outputs that agents produce and other agents might need later. Instead of re-generating the same research or draft, an agent can check artifacts first. The journal entry points to the artifact path. The journal is still the coordination layer, but now it's a lean coordination layer instead of a growing monolith. Some agents need specialized knowledge to do their job well. Genesect and Scizor both often work with React Native code. They need to know current best practices, common migration patterns, upgrade paths. I could put that knowledge directly in their system prompts, but prompts are already doing a lot of work: defining role, behavior, tools, journal protocol, self-improvement loop. Stuffing domain knowledge in there makes them harder to maintain and harder to update when the knowledge changes. The solution was a `skills/` directory. Each skill is a focused markdown file: ``` skills/ react-native-best-practices.md react-native-brownfield-migration.md upgrading-react-native.md github.md github-actions.md ``` Agents load the skills relevant to their work as resources, separate from their core prompt. When React Native releases a new version and the migration guidance changes, I update one file. Every agent that uses that skill gets the update automatically. Skills are also composable. Genesect loads the coding skills. Scizor loads the same ones plus the review-specific context. Alakazam can load a skill when researching a topic it needs background on. The knowledge lives in one place and gets shared across agents that need it. This is the same principle as scoped tool access from Part 1, agents only get what they need, but applied to knowledge instead of tools. In Part 2, I built a test harness with 11 routing tests. The question it answered was: *does Metagross send the right task to the right agent?* That's necessary but not sufficient. Routing correctly to Alakazam doesn't mean Alakazam produced good research. Routing correctly to Mew doesn't mean the blog draft followed the style guide. The harness now has two layers: Layer 1: Routing and structure tests (the original PromptFoo harness). There are 17 tests now, which catch regressions in delegation logic and output structure. Layer 2: Quality evals is a separate `evals/` directory with LLM-as-judge rubrics that test whether agent outputs are actually good. There are five evals: | Eval | What it tests | |---|---| `01-constructive-tension` | Slowking fires after Alakazam and actually validates | `02-alakazam-includes-sources` | Research output cites primary sources, not vague "studies show" | `03-slowking-validates-not-echoes` | Slowking catches wrong claims, doesn't just agree | `04-research-output-quality` | LLM-as-judge rubric: factual grounding, source quality, completeness, actionability | `05-writing-style-compliance` | LLM-as-judge rubric: direct, no filler, no em dashes, no corporate jargon | Each eval has a `task.md` (what to test and why) and a `grader.sh` (runs the agent, then runs the judge). The judge scores on a 1–5 rubric across four dimensions. Pass threshold: average ≥ 3.5. The routing tests run fast and catch structural regressions. The quality evals run on-demand and catch output degradation when an agent starts producing technically correct but actually bad output. The original system required me to manage it, but now it manages more on its own. **Delegation depth limit.** Metagross tracks how deep the delegation chain is. If `delegationDepth >= 3` , it stops delegating and surfaces a blocker instead of spiraling. This catches runaway chains before they waste tokens and time. **Backpressure warning.** Metagross tracks delegations vs. completions within a session. If tasks delegated is more than 2x tasks completed, it surfaces a warning. Something is stuck or looping, and I should know about it. **Parallel execution.** When a task has independent subtasks, like research and a calendar check, Metagross delegates them in parallel instead of sequentially. The prompt explicitly identifies when parallelization applies and when it doesn't. **Monthly archival via cron.** The journal archives itself once a week and moves old entries out of the active journal. **Post-delegation suggestions.** After each agent completes, Metagross suggests a natural next step. After Alakazam: "Want me to validate these findings?" After Genesect: "Want me to review this code, or create a task to track it?" The system nudges toward the constructive tension pattern without requiring me to remember to ask. None of these are individually complex, together can catch its own failure modes instead of waiting for me to notice them. I started this by naming agents after Pokémon because it was fun, but the metaphor still holds: you don't just catch Pokémon and hope for the best. You train them, give them the right moves, put them in the right matchups, and build a team with complementary strengths and intentional tension. Stay tuned for the next update!