AgetnticOS: The Bootstrap Agent – When an Agentic-Net Manages Itself

Posted on

The Bootstrap Agent – When an Agentic-Net Manages Itself

What if the net itself could set up its own tokens? Not a script. Not a human clicking through the GUI. An agent transition that reads a definition file and creates every token the net needs to run — autonomously, in 11 iterations, in under 7 minutes. This is the story of the bootstrap agent: the moment an Agentic-Net stopped being a passive graph and started managing itself.

The Problem: Scripts That Babysit Nets

Every Agentic-Net needs tokens to start working. Places without tokens are inert — transitions wait forever with nothing to fire. In AgetnticOS, the typical setup looks like this: a shell script calls the node API nine times, each time creating a token in a different place with carefully crafted JSON. It works. It’s also brittle, manual, and completely outside the net’s own execution model.

The gateway verification net is a perfect example. It’s a 23-place, 13-transition Petri net that validates the entire gateway routing system — registration, explicit routing, wildcard routing, fan-out, deregistration. Before any of that can run, nine command tokens must land in nine different places. Each token contains a bash command, a working directory, a timeout, and specific test parameters. One script. Nine API calls. Zero self-awareness.

The question that changed everything: what if the net could do this itself?

The Idea: An Agent That Bootstraps Its Own Net

Instead of an external script seeding tokens, we added an agent transition inside the net itself. The transition reads token definitions from a context place and uses the CREATE_TOKEN tool to place each token exactly where it belongs. One click of “fire once” in the GUI and the net populates itself.

This is not just automation — it’s self-organization. The net contains the knowledge of what tokens it needs, and it has the capability to create them. The agent doesn’t need hard-coded logic. It reads natural language instructions, parses a JSON array of definitions, and iterates through them. If the definition format changes, you update the context token — not the agent, not the script, not the code.

The Bootstrap Pattern context token → agent reads definitions → CREATE_TOKEN × 9 → net is ready Bootstrap Context 9 definitions consume: false t-bootstrap agent • rw • SINGLE Result p-bootstrap-result read summary 9 Target Places context p-context unit-test p-unit-test cleanup p-cleanup register p-register explicit p-explicit wildcard p-wildcard discover p-discover executor p-executor + deregister CREATE_TOKEN × 9 Input Place Agent Transition Output Place Target Places (tokens created by agent) Agent tool calls (CREATE_TOKEN)

How It Works: Anatomy of the Bootstrap Transition

The bootstrap agent is a standard agent transition with role rw (read-write), which gives it access to the CREATE_TOKEN tool. Its inscription is minimal:

{
  "id": "t-bootstrap",
  "kind": "agent",
  "presets": {
    "context": {
      "placeId": "p-bootstrap-context",
      "host": "agenticdev@localhost:8080",
      "arcql": "FROM $ LIMIT 1",
      "take": "FIRST",
      "consume": false
    }
  },
  "postsets": {
    "result": {
      "placeId": "p-bootstrap-result",
      "host": "agenticdev@localhost:8080"
    }
  },
  "action": {
    "type": "agent",
    "nl": "Read the token definitions from ${context}. For each definition, use CREATE_TOKEN with placePath, tokenName, and tokenData. Report a summary when done.",
    "role": "rw",
    "maxIterations": 20
  },
  "emit": [{ "to": "result", "from": "@response" }],
  "mode": "SINGLE"
}

Two design choices matter here:

  • consume: false — The context token is never consumed. This means the agent can be fired again and again. Need to reset the net? Click “fire once” and all 9 tokens are recreated.
  • mode: "SINGLE" — The transition doesn’t auto-fire continuously. It waits for a manual trigger. This is intentional — bootstrapping is a one-time setup step, not a continuous process.

The context token holds all 9 definitions in a single JSON array. Each entry specifies the target place path, the token name, and the complete token data — including the kind, executor, shell command, working directory, and timeout:

{
  "definitions": [
    {
      "placePath": "/root/workspace/places/p-unit-test-cmd",
      "tokenName": "cmd-unit-tests",
      "tokenData": {
        "kind": "command",
        "id": "cmd-unit-tests",
        "executor": "bash",
        "command": "exec",
        "args": {
          "command": "cd /path/to/gateway && ./mvnw test 2>&1 | tail -80",
          "workingDir": "/path/to/gateway",
          "timeoutMs": 120000
        },
        "expect": "text"
      }
    },
    { "placePath": "/root/workspace/places/p-cleanup-cmd", "tokenName": "cmd-cleanup", "tokenData": { "..." } },
    { "placePath": "/root/workspace/places/p-register-cmd", "tokenName": "cmd-register", "tokenData": { "..." } }
  ]
}

What Actually Happened: 11 Iterations, 9 Tokens, Zero Errors

We deployed the bootstrap agent into a live gateway verification net and clicked “fire once.” Here’s the complete execution trace from the master logs:

Agent Session Trace: t-bootstrap Session 90cb6714 • 20:45:25 – 20:52:13 • 6m 48s total THINK Iter 1 20:45:38 CREATE TOKEN p-context 20:46:25 CREATE TOKEN p-unit-test 20:46:50 CREATE TOKEN p-cleanup 20:46:57 CREATE TOKEN p-register 20:47:26 CREATE TOKEN p-explicit 20:48:14 CREATE TOKEN p-wildcard 20:49:21 CREATE TOKEN p-discover 20:49:58 CREATE TOKEN p-executor 20:50:33 CREATE TOKEN p-deregister 20:50:50 DONE Iter 11 20:52:13 Plan Execute (9 tokens) Complete Concurrent Net Activity (while bootstrap was running) t-verify-unit-tests (2 iter) t-verify-reg (3 iter) t-verify-routing (2 iter) t-final-verdict (5 iter) Command transitions (unit-test, cleanup, register, explicit, wildcard, discover, executor, deregister) also executing concurrently Session Results 9/9 Tokens Created 11 Iterations Used 6:48 Total Duration 0 Failures LLM: Ollama (local) • Role: rw– • Available tools: 39 • Tools used: THINK, CREATE_TOKEN, DONE

The agent followed a clean execution pattern: 1 THINK (plan the work) + 9 CREATE_TOKEN (one per definition) + 1 DONE (emit summary). Every CREATE_TOKEN call succeeded. The agent emitted a summary token to p-bootstrap-result and the session completed.

What’s remarkable is what happened concurrently. While the bootstrap agent was still creating tokens, the net’s command transitions were already picking them up and executing. The executor polled, found the new unit-test token, ran mvnw test, and the verification agent analyzed the results — all before the bootstrap agent had finished creating all 9 tokens. The net didn’t wait for bootstrapping to complete. It started working the moment the first token appeared.

Why This Matters: From Static Graphs to Living Systems

The bootstrap agent demonstrates a fundamental shift in how we think about workflow orchestration. In traditional systems, there’s a hard boundary between setup and execution. Scripts set things up; the engine runs them. Configuration happens before runtime; runtime doesn’t modify configuration.

In Agentic-Nets, that boundary dissolves. A transition inside the net can:

  • Create tokens in any place — seeding work for other transitions
  • Create new places and transitions — extending the net’s own topology
  • Read and modify inscriptions — changing how other transitions behave
  • Inspect the net structure — understanding its own architecture

This isn’t theoretical. The bootstrap agent used CREATE_TOKEN with place paths — it knew the net’s structure and placed tokens exactly where they needed to go. A more advanced agent with rwx role could deploy new transitions, start them, and wire up entirely new sub-nets at runtime.

Agent Capabilities by Role The more capabilities you grant, the more the net can manage itself r— (Read) 15 tools QUERY_TOKENS LIST_PLACES GET_NET_STRUCTURE EXPORT_PNML VERIFY_NET Observe & analyze the net rw– (Read-Write) 28 tools • Bootstrap agent uses this + CREATE_TOKEN + DELETE_TOKEN + CREATE_PLACE + CREATE_TRANSITION + SET_INSCRIPTION Modify net data and structure rwx- (Execute) 38 tools + DEPLOY_TRANSITION + START_TRANSITION + STOP_TRANSITION + FIRE_ONCE + DOCKER_RUN Deploy, start, stop the net itself rwxh (Full) 41 tools + THINK + DONE + FAIL Full autonomy with explicit control signals Each role includes all tools from the previous role. More capability = more self-management.

The Bigger Picture: Nets That Manage Nets

The bootstrap agent is the simplest form of a pattern we call meta-management — transitions that operate on the net itself rather than on external data. Once you accept that an agent transition can create tokens, the next questions are natural:

  • Self-healing: An agent that monitors place token counts and recreates missing tokens when a transition fails
  • Dynamic scaling: An agent that adds new command transitions when workload increases, and removes them when it drops
  • Net composition: An agent that reads a high-level goal and constructs an entire sub-net — places, transitions, arcs, inscriptions — to achieve it
  • Inscription adaptation: An agent that observes failure patterns and modifies transition inscriptions to handle edge cases
  • Cross-net orchestration: An agent that coordinates between multiple nets, routing tokens from one net’s output to another’s input

Each of these is already possible with the existing tool set. The bootstrap agent used 3 out of 39 available tools. An rwx agent would have access to deployment, lifecycle control, and Docker operations. The net doesn’t just execute workflows — it can design, deploy, and optimize them.

The Gateway Verification Net: Context

The net that the bootstrap agent manages is itself worth understanding. The gateway-routing-verify net is a 4-phase verification pipeline that validates AgetnticOS’s gateway proxy routing system:

  • Phase 1 — Unit Tests: Runs mvnw test on the gateway codebase, verifies BUILD SUCCESS
  • Phase 2 — Registration: Cleans up any existing test masters, registers two test masters (one with explicit models, one with wildcard), verifies heartbeat and listing
  • Phase 3 — Routing: Tests explicit model routing (model-a → master-1), wildcard routing (unknown model → master-2), discover fan-out, and executor listing fan-out
  • Phase 4 — Final Verdict: Deregisters test masters, verifies fallback to seed master, collects all phase verdicts into a final pass/fail assessment

This is not a toy example. It’s a production verification pipeline with 23 places, 13 transitions (8 command, 4 agent, 1 bootstrap), JWT authentication, real HTTP calls, and concurrent execution across multiple service boundaries. The bootstrap agent sets up the entire pipeline in one click.

Try It Yourself

The gateway verification net setup script includes the bootstrap agent. After running the script, open the AgetnticOS GUI and click “fire once” on t-bootstrap:

<pre class="wp-block-syntaxhighlighter-code"># Set up the gateway verification net (creates places, transitions, context token)
cd agentic-nets/agentic-net-gateway
./scripts/setup-gateway-verification-net.sh
# Or fire the bootstrap agent directly via API:
curl -X POST "http://localhost:8082/api/transitions/t-bootstrap/fireOnce" \
  -H "Content-Type: application/json" \
  -d '{"modelId": "agenticdev"}'
# Check the result token:
curl -s "http://localhost:8080/api/models/agenticdev/children?parentId=<p-bootstrap-result-uuid>" | jq .</pre>

Watch the master logs to see the agent iterate through its 11 steps. Then watch the rest of the net come alive as command transitions pick up the newly created tokens and start executing.

The bootstrap agent is the first step toward nets that manage themselves. Today it creates 9 tokens. Tomorrow it might create the net itself — reading a high-level specification, generating the PNML, setting inscriptions, deploying transitions, and firing the first token. Not because we programmed that sequence, but because we gave an agent the right tools and a clear instruction.

That’s the promise of Agentic-Nets: workflows that don’t just run — they think, adapt, and grow.

Built with AgetnticOS — the Agentic Workflow OS. The bootstrap agent ran on Ollama (local LLM) with the agenticdev model, completing 11 iterations in 6 minutes 48 seconds.

Date: March 10, 2026

Leave a Reply

Your email address will not be published. Required fields are marked *