Back to news

Code

Sub-Agents That Build Themselves: Advanced Patterns.

Sub-Agents That Build Themselves: Advanced Patterns: Self-building sub-agents grade their own work and spawn better versions of themselves.

AI Kick Start editorial image for Sub-Agents That Build Themselves: Advanced Patterns.
Decision

Start narrow

Use the article to decide the smallest useful workflow worth testing before expanding the system.

Risk to watch

Hype drift

Avoid turning a practical adoption step into a broad transformation promise nobody can verify.

Proof to collect

Business signal

Write down the owner, data boundary, review point, and measurable outcome before the first build.

TL;DR

TL;DR: Agents can now grade their own output and propose better versions of themselves, with a human signing off. Here is what actually ships in Claude Code, Hermes and OpenClaw, and where the marketing runs ahead of the facts.

Key takeaways

  • Briefing: Briefing Here is the strange new shape of automated software work: a tool that does not just write your code, but writes the assistant that writes your code, then quietly fires that assistant and hires a better one.
  • The Self-Improvement Loop: The Self-Improvement Loop A self-building sub-agent runs a meta-loop that sits one level above ordinary task execution: **Execute**: Perform the assigned task **Evaluate**: Measure output quality against defined criteria **Diagnose**: Identify specific weaknesses in the approach **Generate**: Create an improved sub-agent configuration that addresses those weaknesses **Validate**: Test the new configuration on held-out examples **Deploy**: Replace the current configuration if validation passes The loop needs three things to work: evaluation metrics you can compute automatically, a configuration space you can search, and a validation step that stops the agent from shipping a regression.
  • Pattern 1: Prompt Evolution (Claude Code): Pattern 1: Prompt Evolution (Claude Code) Claude Code's dynamic workflows are real, and they fan work out across parallel sub-agents that a parent agent plans and coordinates.
  • Pattern 2: Skill Signature Evolution (Hermes): Pattern 2: Skill Signature Evolution (Hermes) Hermes handles self-improvement through its skills system, working within the agentskills.io open standard, the same SKILL.md format used by Claude Code, Codex CLI, OpenClaw and others.
  • Pattern 3: Sub-Agent Configuration Search (OpenClaw): Pattern 3: Sub-Agent Configuration Search (OpenClaw) OpenClaw does not ship automatic self-improvement, but you can build it from parts it already has: sub-agents plus a cron-scheduled task system.
  • Pattern 4: Recursive Self-Building: Pattern 4: Recursive Self-Building The most advanced pattern is recursive: a meta-agent that improves not only the task-specific sub-agents but also its own evaluation and generation strategies.
Table of contents

Briefing

Here is the strange new shape of automated software work: a tool that does not just write your code, but writes the assistant that writes your code, then quietly fires that assistant and hires a better one.

It sounds like a stunt. It is closer to plumbing. Three real products now ship the pieces you would need to build it: Claude Code's dynamic workflows (opens in a new tab), which Anthropic released on 28 May 2026 to orchestrate sub-agents at scale; Hermes (opens in a new tab), an agent from Nous Research that keeps notes on its own work and gets better as it runs; and OpenClaw (opens in a new tab), whose scheduled-task system can be wired up to grade and tune other agents overnight.

For an Australian business team, the practical question is not whether your software can become sentient. It cannot. The question is whether an agent can measure its own output, spot where it falls short, and propose a better version of itself while you sleep, with a human signing off before anything touches production. Some of that is here. Some of it is people stitching together features that were not designed for the job. And one version of it is still a research idea with a hopeful press release attached.

Below is what is actually running, what is a sensible pattern you could build, and where the marketing gets ahead of the facts.

The Self-Improvement Loop

A self-building sub-agent runs a meta-loop that sits one level above ordinary task execution:

  1. Execute: Perform the assigned task
  2. Evaluate: Measure output quality against defined criteria
  3. Diagnose: Identify specific weaknesses in the approach
  4. Generate: Create an improved sub-agent configuration that addresses those weaknesses
  5. Validate: Test the new configuration on held-out examples
  6. Deploy: Replace the current configuration if validation passes

The loop needs three things to work: evaluation metrics you can compute automatically, a configuration space you can search, and a validation step that stops the agent from shipping a regression.

Pattern 1: Prompt Evolution (Claude Code)

Claude Code's dynamic workflows are real, and they fan work out across parallel sub-agents that a parent agent plans and coordinates. On top of that primitive, you can build what amounts to prompt evolution: the coordinator keeps a population of prompt variants for each specialist role, checks which variant produced the best output after each task, and breeds new variants by combining the patterns that worked. Worth being clear here: this genetic "prompt evolution" mechanism is not a documented Anthropic feature. It is a pattern layered on the real dynamic-workflows capability rather than something the platform ships by name.

# Sub-agent prompt evolution configuration
evolution:
 population_size: 10
 specialist: test_generator
 evaluation:
 - metric: coverage_increase
 weight: 0.4
 - metric: test_quality_score
 weight: 0.4
 - metric: execution_time
 weight: 0.2
 mutation:
 strategies:
 - add_context_section
 - strengthen_constraints
 - add_examples
 - reorder_instructions

The metrics carry the whole thing. "Coverage increase" is objective and measurable. "Test quality score" needs a model-based evaluator, which adds some subjectivity but tends to track human judgement well. The system throws out any variant that regresses on a metric. Note that the weights above (0.4, 0.4, 0.2) are illustrative numbers, not figures pulled from a benchmark.

Pattern 2: Skill Signature Evolution (Hermes)

Hermes handles self-improvement through its skills system, working within the agentskills.io open standard (opens in a new tab), the same SKILL.md format used by Claude Code, Codex CLI, OpenClaw and others. As it solves problems, Hermes pauses roughly every 15 tool calls to reflect on what worked and what failed, then writes or rewrites a reusable skill document, while a curator periodically prunes the library. The article frames this as generating a "skill signature": a compact record of the problem, the approach, and the outcome, with successful records kept and failed ones analysed for patterns. That "skill signature" wording is the article's own; the official docs describe SKILL.md generation and a roughly 15-tool-call reflection cadence rather than a named signature object, and the Python API shown below is illustrative rather than a confirmed surface.

# Hermes skill evolution
signature = hermes.skills.create(
 problem_type="database_migration_with_rollback",
 approach=["create_new_table", "dual_write", "backfill", "switch_read", "drop_old"],
 tools_used=["sql_runner", "schema_diff", "data_validator"],
 outcome="success",
 duration_minutes=45
)

# Evolve: combine with related successful signatures
hermes.skills.evolve(
 base_signature=signature,
 combine_with=hermes.skills.search("migration"),
 objective="reduce_duration"
)

The learning loop keeps refining these skills over time. A skill that first took 45 minutes to run might drop to 30 through better tool selection, then to 20 through parallelisation, with the gains stacking across sessions. Those duration figures (45, then 30, then 20 minutes) are example numbers to show the shape of the improvement, not measured benchmarks.

Pattern 3: Sub-Agent Configuration Search (OpenClaw)

OpenClaw does not ship automatic self-improvement, but you can build it from parts it already has: sub-agents plus a cron-scheduled task system. A meta-agent runs on a schedule, reviews how the sub-agents performed, and adjusts their configurations.

{
 "subAgents": [
 {
 "name": "meta-optimiser",
 "schedule": "0 2 * * *",
 "skill": "subagent-evaluator",
 "workflow": [
 "read performance logs from past 24h",
 "identify sub-agents with >10% failure rate",
 "analyse failure patterns for each",
 "generate config variants with adjusted prompts/tools/models",
 "A/B test variants on synthetic tasks",
 "deploy winning variant if improvement >5%"
 ]
 }
 ]
}

This takes more hand-assembly than Claude Code or Hermes, but it runs. The point worth keeping is that self-improvement does not need native platform support. It needs structured evaluation and a configuration space you can search. The failure-rate threshold (>10%) and improvement threshold (>5%) above are example values, not numbers from any source.

Pattern 4: Recursive Self-Building

The most advanced pattern is recursive: a meta-agent that improves not only the task-specific sub-agents but also its own evaluation and generation strategies. This one is, by the author's own admission, theoretical for production use. Experiments with Claude Code's Opus 4.8 (opens in a new tab) (a real model, released 28 May 2026) are reported to show promising results, though that result is unconfirmed and not backed by a public source.

In recursive self-building, the meta-agent holds a model of its own reasoning. When it notices its evaluation criteria are poorly calibrated (say, optimising for test coverage while missing bug detection), it updates them. When it notices its generation strategies are too cautious (searching too small a configuration space), it widens them.

The obvious danger is runaway optimisation. Without solid guardrails, an agent that improves itself recursively could chase metrics that are easy to measure while quietly losing the quality those metrics were meant to stand in for. Human oversight stays essential.

Guardrails for Self-Building Agents

Any self-building agent system needs these guardrails:

  1. Regression tests: New configurations must not break tasks that previously passed
  2. Diversity requirements: The configuration space has to stay diverse so it does not converge too early
  3. Human review gate: Deployments touching production require human approval
  4. Kill switches: The ability to revert to a known-good configuration on the spot
  5. Metric sanity checks: Confirm that the optimised metrics still correlate with human judgement

The Current State

Self-building agents are not autonomous yet. They are assistive. They search the configuration space faster than a person can, surface patterns a person might miss, and suggest improvements a person then reviews and approves. The line between "suggests improvements" and "deploys them without asking" is where human judgement currently sits. That line is moving.

Sub-Agents That Build Themselves: answer-first summary

Sub-Agents That Build Themselves matters because it can change how Australian business teams plan, build, or govern an agent workflow. Self-building sub-agents grade their own work and spawn better versions of themselves.

The direct answer is this: do not treat the topic as a standalone trend. Treat it as a decision about inputs, outputs, review ownership, data exposure, and whether the workflow produces a result that is faster, safer, or more useful than the current process.

Sub-Agents That Build Themselves: implementation checklist

  • Define the user, job to be done, and success metric for the agent workflow.
  • Collect real examples, policies, source files, customer questions, or search queries before writing prompts or choosing tools.
  • Separate low-risk drafts from decisions that need approval, privacy checks, or senior review.
  • Document what the AI is allowed to access, what it must not access, and who signs off before production use.
  • Review successful task completion, review time, fallback rate, operator corrections after a small pilot rather than judging the idea from a demo.

This keeps the work practical. It also gives search engines and AI answer engines a clean factual structure: what the topic is, who it helps, what to do next, and which risks matter before implementation.

Decision criteria for Sub-Agents That Build Themselves

Decision areaWhat to checkProduction signal
IntentDoes Sub-Agents That Build Themselves solve a real workflow problem?The use case has a named owner and measurable outcome.
DataCan the required data be used safely?Sensitive data is classified and access is controlled.
QualityCan a reviewer judge the output consistently?Examples, rubrics, or acceptance criteria exist.
ScaleCan the workflow be repeated without hero effort?The process is documented and can be handed to another team member.

Practical example for Sub-Agents That Build Themselves

A small business could use this article to choose one practical test. For example, a manager might take one customer-facing process, one internal document workflow, or one recurring content task and redesign only that step with AI support. The goal is not to automate the whole business at once; it is to learn where Code creates reliable leverage.

The useful deliverable is a short operating note: the trigger, the source material, the prompt or tool, the review checklist, the escalation rule, and the metric. That note becomes the handover asset for staff training, SEO/GEO content, service delivery, or future agent work.

Risks and controls for Sub-Agents That Build Themselves

The common failure pattern is moving too quickly from a promising idea into an unmanaged workflow. For Sub-Agents That Build Themselves, the risk is not only bad output. It can also be unclear data permission, staff confusion, duplicate content, unreviewed customer advice, or a tool that quietly changes cost or capability.

  • Control unclear tool permissions with a named owner, a review step, and written acceptance criteria.
  • Control silent failures with a named owner, a review step, and written acceptance criteria.
  • Control prompt drift with a named owner, a review step, and written acceptance criteria.
  • Control weak audit trails with a named owner, a review step, and written acceptance criteria.

Measurement plan for Sub-Agents That Build Themselves

A useful AI or SEO initiative should leave evidence. Track successful task completion, review time, fallback rate, operator corrections and compare the pilot against the current process. If the measure does not improve, keep the learning but avoid scaling the workflow.

For GEO readiness, the page should also answer the core question directly, define the entities involved, include implementation steps, explain tradeoffs, and link readers to the next relevant AI Kick Start service, guide, tool, or article.

Definitions and entities for Sub-Agents That Build Themselves

For search, GEO, and staff handover, define the core entities in plain language. In this article the important entities are the workflow owner, the AI tool or model, the source material, the review process, the risk boundary, and the measurable business outcome. Clear definitions make the page easier for people to scan and easier for AI answer engines to quote accurately.

  • Workflow owner: the person accountable for deciding whether Sub-Agents That Build Themselves belongs in the business process.
  • Source material: the documents, examples, policies, URLs, prompts, videos, or customer questions that ground the output.
  • Review boundary: the point where a human checks accuracy, privacy, brand voice, or customer impact before the result is used.
  • Success metric: the measure that proves whether the agent workflow is worth repeating.

Sub-Agents That Build Themselves versus doing nothing

Doing nothing is also a decision. The cost may be slow manual work, weaker search visibility, inconsistent advice, duplicated effort, or staff using unmanaged AI tools without a shared process. The practical question is whether a controlled pilot can reduce that cost without creating a larger governance problem.

OptionWhen it makes senseWhat to watch
Do nothingThe workflow is rare, low value, or already reliable.Competitors may improve speed, content depth, or service consistency first.
Run a small pilotThe task repeats often and has clear review criteria.Keep scope tight and measure the result against the current process.
Build a production workflowThe pilot is repeatable and risk controls are documented.Assign ownership, monitoring, training, and a rollback path.

AI Kick Start handover package for Sub-Agents That Build Themselves

A production handover should be concrete enough that another person can run it. For Sub-Agents That Build Themselves, that means a short brief, a workflow map, approved prompts or tool settings, source material, a review checklist, internal links to supporting resources, and a simple measurement sheet. This is the difference between reading about AI and turning it into operational capability.

That packaging also strengthens E-E-A-T. It shows experience through implementation notes, expertise through decision criteria, authoritativeness through source-aware structure, and trust through risks, controls, and review steps. The article becomes useful even if the reader never buys a tool because it helps them make a better operational decision.

Source trail

Primary references to keep this briefing grounded

AI and automation information changes quickly. Use these official or primary references to verify the claims, pricing, product behaviour, and compliance details before committing budget or production data.

Frequently asked questions

What is the practical takeaway from Sub-Agents That Build Themselves?

Self-building sub-agents grade their own work and spawn better versions of themselves. For AI Kick Start readers, the key is to translate the idea into one agent workflow with clear inputs, review points, and measurable outcomes. The article should be treated as implementation guidance, not a substitute for workflow design.

Who should use Sub-Agents That Build Themselves guidance in Code?

This guidance is most useful for Australian business teams who need to decide whether the topic changes tool selection, automation design, search visibility, data handling, training, or operational governance.

How should an Australian business implement Sub-Agents That Build Themselves?

Start small: define the agent boundary, give it test data, log its actions, and keep approval gates around customer or financial decisions. If the pilot improves successful task completion and review time, document the pattern, link it to the relevant service or resource page, and then decide whether it belongs in a production workflow.

What to do next

  1. For Sub-Agents That Build Themselves, write down the single agent workflow this article should improve.
  2. Collect real examples, edge cases, and source material before testing Sub-Agents That Build Themselves with any AI output.
  3. Before implementing Sub-Agents That Build Themselves, add a human review checkpoint for quality, privacy, brand, or customer-impact risk.
  4. Measure successful task completion, review time, fallback rate for Sub-Agents That Build Themselves before deciding whether to scale.
  5. Connect Sub-Agents That Build Themselves to a related service, resource, or training path so readers have a clear next action.

Want help applying this? Explore AI agent design systems.

AI Kick Start is an Illawarra-based AI studio in Figtree, helping businesses across Wollongong, Shellharbour and Kiama and right across Australia put AI to work.

Explore with AI

Use the article as a decision prompt

Summarise this AI Kick Start article for an Australian business owner. Focus on the useful decision, the risks, and the first practical next step: Sub-Agents That Build Themselves: Advanced Patterns

Turn this into a practical roadmap.

Use the guide as a starting point, then map the first workflow worth building.

Book an AI strategy call