Nets That Build Nets
What happens when you give an AI agent inside a Petri net the ability to create other agents — inside the same net? You get a self-extending multi-agent framework where the orchestration topology builds itself. We tested this with AgenticNetOS. Here’s what happened.
The Idea: Recursive Agent Creation
Most multi-agent systems require a separate orchestration layer — a “manager agent” that spawns “worker agents” through an external API. The agents don’t know about each other. Communication happens through message queues or function calls that live outside the agents’ world.
In AgenticNetOS, agents live as transitions in a Petri net. Their communication channels are places. Their coordination rules are inscriptions. When an agent creates another agent, it’s adding a transition to the same graph it lives in. No external bus. No separate runtime. The net is the framework.
We wanted to prove this by running a simple experiment: give one agent transition the power to create other agents, then ask it to replicate itself and build a real workflow — all autonomously.
Step 1: An Agent That Creates Agents
We started with an empty Petri net and asked the Workflow Builder persona to create an agent transition with rwxhl rights — read, write, execute, HTTP, and log permissions. This gives the agent access to 56 tools, including the ability to create places, transitions, arcs, set inscriptions, and deploy them.
The builder created three elements: t-agent-builder (the agent transition), p-input (where instruction tokens arrive), and p-output (where completion summaries land). One transition. Two places. That’s the entire starting net.
The critical part is the inscription — specifically the action.role field:
{
"id": "t-agent-builder",
"kind": "agent",
"action": {
"type": "agent",
"nl": "@input.data.instruction",
"role": "rwxhl",
"sessionId": "2026-04-15_19-30-10",
"autoEmit": false,
"maxIterations": 20
},
"presets": {
"input": {
"placeId": "p-input",
"arcql": "FROM $ LIMIT 1",
"consume": true
}
},
"postsets": {
"output": { "placeId": "p-output" }
},
"emit": [
{"to": "output", "from": "@response"}
]
}
The action.nl: "@input.data.instruction" reads the task from the input token’s instruction field. The role: "rwxhl" gives the agent full capabilities. Drop a token with an instruction, and the agent does the rest.
Step 2: The Agent Creates a Copy of Itself
We dropped a token into p-input with this instruction:
“Create another agent transition in this same net with the same capabilities. Give it rwx rights so it can create other elements too.”
The agent builder transition fired. It read the instruction, looked up the inscription language reference from the knowledge graph via SEARCH_KNOWLEDGE and READ_BLOB_TEXT, and then autonomously:
- Created t-agent-builder-2 as a new transition in the PNML
- Created p-input-2 and p-output-2 as its input/output places
- Connected them with arcs
- Created runtime token containers for both places
- Set the inscription with
action.role: "rwx"andaction.sessionId - Verified the net structure with VERIFY_NET
An agent that created a copy of itself — with full capability to do the same thing again. The second agent can create a third, which can create a fourth. Recursive self-replication, constrained by the Petri net topology.
Step 3: The Agent Builds a Weather Workflow
Next, we instructed the agent to build something useful — a weather data pipeline:
“Build a weather subnet with a fetch-weather transition, input place for city names, output for weather data, and a storage place.”
The agent created a complete subnet:
- t-fetch-weather — a transition that calls a weather API
- p-weather-input — accepts city name tokens
- p-weather-output — emits weather response data
- p-weather-data — stores historical weather records
- All arcs, runtime places, and inscriptions configured correctly
We then dropped a token for “Karlsruhe” into the weather input, fired the transition, and got live weather data back — all built by the agent, not by a human developer.
Why This Matters
Multi-Agent by Design, Not by Framework
In AgenticNetOS, the multi-agent topology is the net. Agents live as transitions. Their communication channels are places. Their coordination rules are inscriptions. When an agent creates another agent, it’s modifying the same graph it executes in. There’s no external orchestration bus — the net itself is the multi-agent framework.
Self-Improvement Through Structure
When an agent builds a new transition, that transition immediately becomes part of the executable workflow. It can be started, stopped, connected to any place, given its own LLM model and parameters. The net specializes over time: a general-purpose builder creates a weather agent, which could create a data-cleaning agent, which could create an alerting agent. Each is a first-class transition — not a subprocess, not an ephemeral function call.
The Crystallization Path
Today, the weather transition uses an LLM agent to interpret instructions. But the pattern it follows — fetch data from URL, parse JSON, store results — is deterministic. Once proven, it can be crystallized into a pure HTTP transition at zero LLM cost. Same net. Same places. Same tokens. Just a different inscription. The cost curve bends toward zero as patterns solidify.
Observable by Default
Every token in every place is visible. Every transition firing is logged. Every inscription is inspectable. When t-agent-builder creates t-fetch-weather, you can see what instruction it received, what tools it called, what elements it created, and whether the result works. The net topology is the audit trail.
What We Learned
The knowledge graph is essential. The agent’s first attempts at building inscriptions missed the role field entirely. Once we added comprehensive inscription documentation to the blobstore knowledge graph, the agent looked it up via SEARCH_KNOWLEDGE before building — and got it right every time.
SessionId is the missing link. Without action.sessionId in the inscription, the agent couldn’t find the correct net and wasted all 20 iterations guessing. A single missing field turned a 30-second task into a failure. Once set, everything worked.
Context compaction prevents timeouts. With 56 tools and growing conversation history, LLM calls can exceed time limits. Auto-compaction of conversation history keeps the context manageable — keeping the first message (task context) and the last 10 messages (recent work), replacing everything in between with a summary.
Per-transition model selection enables specialization. Each agent transition can now specify its own LLM model via action.model. Use a fast, cheap model for simple routing tasks and a powerful model for complex building tasks — all in the same net.
What This Proves
AgenticNetOS is not just a workflow engine that happens to support AI. It’s a self-extending multi-agent framework where:
- Agents create agents — not through an external API, but by modifying the graph they execute in
- The net IS the multi-agent topology — no separate orchestration layer
- Every capability is a transition — adding a new skill means adding a transition, not writing code
- Patterns crystallize — AI exploration becomes deterministic execution over time
- Everything is observable — the net structure is the audit trail
The gap between “AI chatbot” and “production automation” is the gap between conversation and structure. Agentic-Nets close that gap. A net that can build other nets is a net that can improve itself — and that’s where autonomous operations begin.
This article documents a real experiment run on April 15, 2026. Every transition, token, and inscription described here was created live in a running AgenticNetOS instance — observed, verified, and executed.
AgenticNetOS is the Agentic Workflow OS. Learn more at alexejsailer.com.