Agentic-Nets: Govern Your Agents Before They Govern You

Govern your agents before they govern you.

Prompt-based agents are great until you put them anywhere near production. The context resets, the permissions are hand-waved, the tool calls are unauditable, the state lives in a chat transcript that nobody can replay, and “multi-agent” usually means “another prompt that hands off to another prompt.”

Agentic-Nets is a different bet: a governed multi-agent runtime where every agent lives inside a formal Petri net, and the net itself defines what the agent can see, what it can do, where its outputs go, and how it talks to other nets. One net can model a single guarded agent; many nets can model an agile team, a development pipeline, or an entire product operating system.

And you build it by talking, not coding. Nets are designed and deployed by a builder agent that lives inside the runtime — you describe the workflow in plain language (“watch this folder, classify the new files, send the urgent ones to Slack”) and the builder creates the places, wires the transitions, fills in the inscriptions, and starts the net for you. No JSON to write, no SDK to learn, no glue code, no programming knowledge required. If you can describe a process, you can run it.

Same job, two structurally different runtimes. The net is what makes the agent operable.

The Problem: prompts with tools are not architecture

Every team that has tried to ship something real with chat-based agents hits the same set of walls:

• Context lives in a transcript. Restart the session and you’ve lost it. Run two agents in parallel and they can’t see each other’s work without a giant shared prompt.
• Permissions are vibes. “Don’t delete the database” written in markdown isn’t a boundary. Real systems need scoped capabilities the agent literally cannot exceed.
• Outputs are unaccountable. When the agent calls a tool, you usually have a log line and a hope. There is no token, no transition, no event you can query weeks later to ask why.
• Multi-agent is a euphemism. “Agent A hands off to Agent B” is just one prompt invoking another. There’s no shared state, no audit trail across the seam, no way for a third agent to inspect what they did.
• Crystallization never happens. The eighth time the agent does the same task, it still pays full LLM cost. There’s no path from “AI figured it out” to “deterministic code, no AI needed.”

The thing missing is a runtime. Not another framework, not another orchestrator, not another prompt — an actual substrate where agents live, with structure, identity, and constraints baked into the substrate itself.

The Idea: Petri nets as governance

A Petri net is one of the oldest models of concurrent computation: places hold tokens, transitions consume tokens from input places and emit them to output places, arcs wire the topology. It is mathematical, deterministic where you want it to be, and visual.

Agentic-Nets keeps the formalism and adds the missing pieces for AI work:

• Places are persistent. Backed by event sourcing, queryable with ArcQL (a small SQL-flavored query language), they survive restarts and crashes.
• Tokens are structured. JSON with metadata, timestamps, and provenance — not opaque blobs, not chat strings.
• Transitions come in seven types. Pass for routing, map for transformation, http for external calls, llm for a single inference, agent for autonomous multi-step AI, command for shell, link for graph connections. Mix them in the same net.
• Inscriptions are auto-generated. Every transition has a small inscription that defines its presets, postsets, action, and emit rules — but you never write one by hand. You describe what the transition should do in plain language; the builder agent produces the inscription and stores it in the runtime. Auditable, diff-able, versionable — and entirely prompt-authored.
• Roles are capabilities. Agents inside agent transitions get one of four scoped role flags — r--- read-only, rw-- read/write, rwx- execute, rwxh full with HTTP. The runtime enforces them; the prompt cannot override them.

The minimum unit of work in Agentic-Nets — not a chat turn, but a token moving through a guarded transition.

Four roles, four flags, runtime-enforced. The agent gets the smallest set that lets it do its job — not a blanket “you have all the tools.”

Three lanes, seven primitives. Build any workflow by composing them.

You build by prompting, not coding

Here is the part most people don’t expect: you never write the JSON, the inscriptions, or any code to build a net. The whole authoring surface is a conversation. You open the visual editor, talk to the builder agent in plain language, and it designs the places, wires the transitions, fills in the inscriptions, and deploys the result into the runtime live. A typical first session looks like this:

You confirm; the net is live. No JSON in your editor, no Java, no Python, no SDK, no glue code. The builder agent has full read/write/execute access to the runtime, so the same conversation that designs the net also deploys it, fires the first test token through it, and revises it when you say “actually, also notify me on Telegram if the queue gets larger than 100.”

If you want to inspect what was generated — the inscription JSON, the PNML, the role flags — it is all there in the editor for the curious or the auditor. But for shipping work, you do not have to. The artefact you author is the prompt. The artefact the runtime stores is the net. They are not the same file, and you only need to care about the first one.

Net of nets: composition is the point

One net can hold one or many agents. Many nets can also work together as a larger runtime: one can guard, one can gather, one can synthesize, one can execute, and all of them exchange structured state through explicit flows instead of hidden prompt handoffs.

The Agent Control view of a multi-net runtime — each box is a self-contained net with its own places, transitions, and tokens, communicating via shared inboxes.

That property — that nets compose — is what lets the same primitives scale from “one guarded developer agent” to “an entire product operating system” without changing models. A team-of-agents net is just nets that share inboxes. A development pipeline is just nets where the output of one becomes the input of the next. A self-improving knowledge engine is just a net whose output writes back to its own context place.

A real net, end to end

To make this concrete, here is a small crawler. URLs land in p-urls. An HTTP transition fetches each one. An agent transition reads the response and decides whether the page is interesting. Pages flagged as interesting flow to a command transition that runs follow-up work on a remote executor. The rest are routed to p-archive via a map. No box is special — the topology is the architecture.

One net. Five transition types. Real work, all of it inspectable.

This is what the builder agent produces for the classifier transition behind the scenes — you would never type it. You would prompt the builder with something like “watch p-fetched, send each successful response to an agent that decides interesting vs. archive,” and it generates and deploys the inscription below. We show it only so you can see how compact the contract is:

{
  "id": "t-classify",
  "kind": "agent",
  "presets": {
    "input": {
      "placeId": "p-fetched",
      "arcql": "FROM $ WHERE $.status==200 LIMIT 1",
      "take": "FIRST",
      "consume": true
    }
  },
  "postsets": {
    "interesting": { "placeId": "p-interesting" },
    "archive":     { "placeId": "p-archive" }
  },
  "action": {
    "type": "agent",
    "role": "rw--",
    "nl": "@input.data.classifyInstruction",
    "autoEmit": false
  },
  "mode": "SINGLE"
}

That’s the whole contract — small enough to fit on a slide. The agent receives the token, runs as rw-- (cannot execute or call HTTP), reaches a decision, and writes a result token to one of the two postset places. No hidden state, no chat transcript, no out-of-band escape hatch — and again, you never write this file. The builder agent owns it; you own the prompt.

The same five-field structure governs every transition — pass, map, HTTP, LLM, agent, command, link. The builder agent fills in the fields from your prompt; you read inscriptions for verification, never to hand-write them.

What you can model with it

• Virtual developers with explicit permissions, durable memory, and execution boundaries — not “I gave Claude shell access and crossed my fingers.”
• Virtual agile teams. Planner, builder, reviewer, tester, and releaser as five communicating nets, each with its own role and inbox. The PM is the only one talking to the user.
• Smart development tools that behave like reusable nets instead of throwaway prompts — same tool, two different teams, same governed surface.
• Development pipelines that generate code, run checks, gate releases, and keep a durable audit trail of every token that passed through.
• Product-level systems where backlog, QA, docs, incidents, and operations communicate as structured nets — the runtime that ties the whole product together.
• Industry-specific operating models in software, finance, support, operations, research, healthcare, logistics — any domain that can be expressed as communicating nets where structure, coordination, and verification matter.

Open at the edges, governed at the core

Agentic-Nets ships as a hybrid stack: open-source services with public source, plus a small set of closed-source services distributed only as Docker Hub images. The split is deliberate — the parts you adapt and integrate are open; the orchestration core is governed.

A staging-first release pipeline

Releases are not done by typing docker push. The whole pipeline is automated, staging-first, and operator-gated — because the runtime is exactly the kind of system where a bad image landing on Docker Hub at midnight breaks every fresh install for a week.

Five steps. Two operator gates. The git push to public GitHub stays on the human — CI never pushes.

The CHANGELOG comes first

Every release requires a hand-written CHANGELOG entry in both repos before the pipeline can fire. The rule is simple: write for the consumer of the release, not the contributor. Group by component, no commit timestamps, no SHAs — just what changed and why it matters. The result is a release timeline that reads like a product story instead of a git log.

Patch (x.y.Z) is for bug fixes and polish. Minor (x.Y.0) is for new capabilities, endpoints, or config keys. Major (X.0.0) is reserved for breaking changes. The version source of truth lives in a single ci/VERSION file at the workspace root, and CI fails if any compose file references a version other than that one.

Try it in five minutes

The full hub-only stack — nine services, monitoring included — comes up with two commands:

git clone https://github.com/alexejsailer/agentic-nets.git
cd agentic-nets/deployment
cp .env.template .env

# Hub-only (everything pre-built)
docker compose -f docker-compose.hub-only.yml up -d

Once the gateway reports healthy, the visual editor is at http://localhost:4200, the master orchestrator at :8082, the data engine at :8080, and Grafana at :3000 with admin/admin. The intended path from here is to open the editor and talk. Describe the net you want in plain language, let the builder agent design and deploy it, then watch the tokens flow through the visual editor and Grafana. Hand-drawing places and arcs in the editor is supported but optional. Importing a JSON inscription is supported but rarely needed. Most users never see a single line of JSON — and never have to.

Watch the series

If reading is not how you absorb this kind of thing, the playlist below walks through the same ideas in video form — the runtime, the visual editor, real nets being built and fired live.

The bet

The bet behind Agentic-Nets is that the next generation of AI systems will not be defined by which model you pick or how clever your prompts are. It will be defined by the runtime the agents live in — whether they have structure, identity, scoped permissions, durable memory, replayable history, and a clear path from “AI figured it out” to “this is now deterministic code, no AI needed.”

Prompt-based agents got us to “this is interesting.” Agentic-Nets is the substrate that gets us to “this is operations.” Govern your agents before they govern you — or at least before the next ten you spawn run naked across your codebase.

Agentic-Nets is the public open-source side of the AgenticNetOS platform. Source, deployment compose, monitoring configs, and the BSL 1.1 license are at github.com/alexejsailer/agentic-nets. The full architecture and crystallization patterns are documented across the rest of this blog.