I built an AI agent that forges its own tools mid-task — and asks first (open source, 60-second demo)

Rameswaran Mohan — Tue, 08 Sep 2026 21:36:03 +0000

I asked my agent to password-protect a PDF. No such tool existed. Here is what happened next, in 60 seconds, built only from the real, unedited screenshots of the run:

Watch the walkthrough (MP4, 60s)

What it is

Systemu is a local-first AI agent runtime. When a task needs a capability the agent doesn't have, it doesn't fail and it doesn't fake it. It requests the capability, and a Governor arbitrates by risk:

One card lands in your Inbox, rated HIGH because the agent chose it. Safe default: Skip.
You review the spec, then the generated code, before anything exists.
Dependencies get their own approval (no silent pip install).
Even the first run is gated as dangerous-until-proven.
Deployed with provenance: AGENT-BUILT · dry-run PASSED, revocable in one click.

Approvals bind to a hash of the tool body plus its effect set, so a re-forge asks again. Anything that runs a shell, deletes, sends or writes to the network can never be bulk-approved.

Does the governance kill the capability?

I measured instead of asserting. On tasks that are impossible without acquiring a missing capability (23 tasks, 6 families, 5 models from 5 vendors, external-oracle graded):

Frozen toolkit: 6%
Governed self-provisioning: 61%
179 trials, McNemar p = 2.8 × 10⁻¹⁰

Try it

pip install "systemu[dashboard]"
systemu init && systemu start

Works with a local Ollama or your own OpenAI / Anthropic / Google / OpenRouter key. MIT licensed.

Honest limits

Small / flash-tier models write noticeably worse tools.
First install is heavy (Playwright + Chromium for browser tools).
The benchmark is mine and n = 179. I'd genuinely like someone to break it; everything is in cgb_eval/.
Solo project from Chennai. Treat it as a serious beta.

Repo: https://github.com/rameswaran-mohan/project-systemu
Preprint: https://doi.org/10.5281/zenodo.20816383
Longer write-up on why (the three September papers on self-patching agents): https://dev.to/rameswaran_mohan_9c8b5d8f/your-ai-agent-will-patch-itself-the-question-is-who-approves-the-patch-gl

If your agent could grow its own toolkit under review, would you let it?

Your AI agent will patch itself. The question is who approves the patch.

Rameswaran Mohan — Tue, 08 Sep 2026 19:35:23 +0000

In the first week of September three arXiv papers landed on the same nerve:

HarnessDev (2609.01437) asked whether LLMs can create and evolve their own agent harness.
SafeEvolve (2609.02786) had agents co-evolve their own safety policy from experience.
PatchBench (2609.04075) measured how well agents patch real security vulnerabilities — and found the usual proof-of-concept check inflates solve rates by 1.83×.

Read together, they say one thing: agents are starting to modify the thing that runs them. Their own tools, their own guardrails, the code they operate on.

Every one of those papers leaves the same question open. Who approves the patch?

An unreviewed self-patch is a supply-chain risk you invited in

We spent a decade learning not to curl | sh from strangers. Then we learned to pin dependencies, sign builds, and review every PR. A self-improving agent that writes a tool and runs it in the same breath undoes all of that in one step — and it does it inside your perimeter, with your credentials.

The tempting answer is "don't let agents write tools." But that throws away the capability that makes agents useful: the thing your agent needs is almost always discovered mid-task. A PDF encryptor that doesn't exist. A library it can't import. A file format nobody wired up. Freeze the toolkit and the agent either fails or — worse — fakes it.

So the real question isn't whether agents should grow. It's how the growth gets governed.

What a governed self-patch looks like (a real run, unedited)

I've spent four months on an open-source runtime called Systemu that takes one specific position on this. Last week I watched it work end-to-end on a boring, real task: "encrypt these PDFs with a password." No such tool existed.

Prefer watching? The whole loop in 60 seconds, built only from the real, unedited screenshots of the run: systemu-demo.mp4

1. The agent asks — it doesn't fail, it doesn't fake.
The running agent issues a REQUEST_HARNESS — "provision what I lack." One card lands in the Inbox:

HIGH — Forge tool: pdf_encrypt
Apply password protection to a PDF file and save the encrypted version to a new path.
What approve does: generates + reviews the tool code, then enables it.
Safe default: Skip

The safe default is Skip. Do nothing, and nothing happens.

2. You review the spec, then the code — before anything exists.
Approving the card doesn't run anything. It generates the tool and shows you the source with a plain warning: this does not prove the code safe — read it before approving. The LLM reviewer can flag problems, but it can only ever push the decision toward deny or escalate. It cannot open a hole.

3. Dependencies gate separately.
The generated tool wanted pypdf. That's its own approval. No silent pip install, ever.

4. The first run is gated too.
Even after the tool is deployed, its first execution lands as an action card marked dangerous-until-proven, with the actual arguments shown. Safe default: Deny. Re-forging the tool re-gates it.

5. Deployed, with provenance.
Minutes later the Build page shows pdf_encrypt — DEPLOYED · AGENT-BUILT · dry-run PASSED. The toolkit grew by one. Every step is in the decision ledger, attributed to the run that made it, revocable in one click.

That's the whole loop: gap → request → govern → grow.

Two ideas underneath it that I think are non-obvious

A self-requested capability is more dangerous than a pre-provisioned one. The agent chose it. So it's gated more strictly, not less — the opposite of how most frameworks treat "the agent decided it needs X."

Judgment can only downgrade toward safe. When an ambiguous request needs an LLM judge, the judge may deny or escalate, never grant beyond policy. A judge fault fails to escalation, not to grant. Your safety doesn't depend on the model being right.

Does the governance kill the capability?

That was my fear, so I measured it instead of asserting it. A Capability-Gap Benchmark: tasks that are impossible without acquiring a missing capability, across six capability families (tool, skill, file/secret access, compute budget, sub-agents, MCP servers), across 5 models from 5 vendors, graded by an external oracle rather than the system's own verifier.

Frozen toolkit (classic push harness): 6%
Governed pull (full Governor, human gates): 61%
179 trials, McNemar p = 2.8 × 10⁻¹⁰

Governance isn't the brake on self-improving agents. It's the steering. Preprint on Zenodo.

Honest limits

The forge step is only as good as the model. Flash-tier models write noticeably worse tools.
First install pulls a lot of dependencies; the dashboard extra is heavy.
The evaluation is mine. I would genuinely like someone to try to break the 6% → 61% result — the trial logs are available.
It is a solo project from Chennai. Treat it as a serious beta, not a product.

Try it

pip install "systemu[dashboard]"
systemu init && systemu start

MIT licensed. The 22-second walkthrough is at the top of the README: https://github.com/rameswaran-mohan/project-systemu

If your AI patched itself tonight — would you know?

DEV Community: Rameswaran Mohan

I built an AI agent that forges its own tools mid-task — and asks first (open source, 60-second demo)

What it is

Does the governance kill the capability?

Try it

Honest limits

Your AI agent will patch itself. The question is who approves the patch.

An unreviewed self-patch is a supply-chain risk you invited in

What a governed self-patch looks like (a real run, unedited)

Two ideas underneath it that I think are non-obvious

Does the governance kill the capability?

Honest limits

Try it