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:
- 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)
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_instructionsThe 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:
- Regression tests: New configurations must not break tasks that previously passed
- Diversity requirements: The configuration space has to stay diverse so it does not converge too early
- Human review gate: Deployments touching production require human approval
- Kill switches: The ability to revert to a known-good configuration on the spot
- 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 area | What to check | Production signal |
|---|---|---|
| Intent | Does Sub-Agents That Build Themselves solve a real workflow problem? | The use case has a named owner and measurable outcome. |
| Data | Can the required data be used safely? | Sensitive data is classified and access is controlled. |
| Quality | Can a reviewer judge the output consistently? | Examples, rubrics, or acceptance criteria exist. |
| Scale | Can 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.
| Option | When it makes sense | What to watch |
|---|---|---|
| Do nothing | The workflow is rare, low value, or already reliable. | Competitors may improve speed, content depth, or service consistency first. |
| Run a small pilot | The task repeats often and has clear review criteria. | Keep scope tight and measure the result against the current process. |
| Build a production workflow | The 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.





