Meta-Agent Orchestration and the UX of Removing Features
Nine specialist agents. One meta-agent to rule them.
The oss-agent-lab has been building toward this since Epoch 1. Nine focused agents — each handling a single concern like license scanning, dependency auditing, or README generation — working independently. Useful, but limited. A user had to know which agent to invoke, in what order, with what parameters.
The meta-agent eliminates that problem. It reads the capability manifests of all nine specialists, interprets what the user actually wants, and orchestrates multi-step workflows across them.
How the Meta-Agent Works
The architecture is deliberate. The meta-agent doesn’t contain domain logic. It doesn’t know how to scan licenses or audit dependencies. It knows how to read capability declarations and compose them into plans.
Each specialist publishes a manifest describing what it does, what inputs it needs, and what it produces:
class AgentManifest:
name: str
capabilities: list[Capability]
input_schema: dict
output_schema: dict
dependencies: list[str] # other agents whose output this one consumes
The meta-agent reads all nine manifests at startup. When a user request arrives — say, “audit this repo and generate a contribution guide” — it decomposes the request into steps, maps each step to a specialist, resolves dependencies between them, and executes the plan.
class MetaAgent:
def orchestrate(self, user_request: str) -> WorkflowResult:
# Parse intent from natural language
intent = self.intent_parser.parse(user_request)
# Build execution plan from available specialists
plan = self.planner.create_plan(
intent=intent,
available_agents=self.registry.all_manifests(),
)
# Execute steps, passing outputs forward
results = {}
for step in plan.topological_order():
agent = self.registry.get(step.agent_name)
inputs = step.resolve_inputs(results)
results[step.id] = agent.execute(inputs)
return self.output_generator.compile(results, plan)
The topological ordering matters. If the contribution guide generator depends on the license scanner’s output, the planner ensures the license scan runs first. No hardcoded sequencing. The dependency graph is derived from the manifests.
The Six-Epoch Build
This meta-agent is the capstone of a six-epoch architecture:
- E1–E3: Individual specialist agents with isolated responsibilities
- E4: Shared protocols and inter-agent communication contracts
- E5: CI hardening, test coverage, ruff formatting across all packages
- E6: Meta-agent, output generator, enhanced CI, launch README
PR #6 delivered the meta-agent, output generator, and CI enhancements. PR #7 followed immediately with a full test audit — hardened assertions, parametrized test cases, added source-level tests. Coverage thresholds were set at 60%, deliberately lower than the typical 80% target because async network code in agent orchestration produces diminishing returns on coverage metrics past that point.
The v1.0.0 release prep landed the same day. Six epochs, nine agents, one orchestration layer.
The project went from concept to shipping in a structured, incremental build where each epoch’s output became the next epoch’s foundation. No big-bang integration. No “we’ll wire it all together at the end.” Each epoch shipped working software that the next epoch consumed.
Meanwhile: The Marketplace Learned a Lesson
On the same day, claude-code-plugins v4.18.0 shipped with a different kind of improvement. The explore page got cleaned up — and “cleaned up” meant removing things.
A few days earlier, the Verified Plugins Program introduced verification badges to the marketplace. Shiny visual indicators showing which plugins had passed quality checks. Good idea in theory.
In practice, the badges added visual noise. Every card on the explore page now had an extra element competing for attention. The verification status wasn’t adding signal — it was adding clutter. When most plugins aren’t verified yet, a badge system mostly tells you what isn’t verified, which users already assumed.
Worse, the “Verified Only” toggle. Turn it on, and you’d see maybe a dozen plugins out of 900+. An empty-feeling page that makes your marketplace look anemic instead of curated. The toggle was technically correct and experientially wrong.
So we removed all of it. Same day we noticed the problem.
Subtraction as Progress
The instinct is always to add. More badges. More filters. More visual indicators. Product work feels like progress when you’re shipping features. Removing features feels like admitting a mistake.
But the explore page is better now. Cards are cleaner. The layout doesn’t fight for your attention. The verification infrastructure still exists — it’s running in CI, scoring plugins, tracking quality trends. The display of that data just isn’t ready for the card grid yet.
The badges will come back when the verified pool is large enough that filtering by verification status is genuinely useful. Until then, the data accrues silently and the UI stays clean.
Other v4.18.0 changes were straightforward: the navigating-github plugin joined the marketplace and cowork downloads, content-consistency-validator got skill improvements, and skill-review CI tightened up. Incremental quality work that doesn’t need a hero section.
The Pattern
Two projects. Two different lessons on the same day.
The meta-agent is about composition. Nine simple agents become more powerful when orchestrated by a tenth that understands intent. You don’t build a monolith that does everything. You build specialists with clean contracts and a coordinator that assembles them.
The marketplace cleanup is about restraint. The best version of a UI isn’t the one with the most features. It’s the one where every element earns its space. Sometimes shipping means removing the thing you shipped yesterday.
Both are architecture decisions. One adds a layer. The other subtracts one. Both made their respective systems better.