Agentic-Nets: The First Multi-Layer Agent Runtime With Live Applications on Top

Every article on this site so far has shown one system built on Agentic-Nets: a software team that ships while you sleep, a QA department, a research desk with a staff writer, a brain that answers its own questions. This article steps back and shows the product category underneath all of them: the first multi-layer agent runtime with live applications on top. It explains how applications, humans, agents, deterministic processes and local or remote execution become parts of one system, what is possible today, and why this is different from a workflow tool with an AI step.

The First Multi-Layer Agent Runtime

Agentic-Nets is a governed, event-sourced runtime with several operational layers, not a single agent loop. Human-facing applications sit at the top. MCP/API connects every participant to one control plane. A live Petri-net runtime owns durable state and execution. Local and remote executors carry out commands, while observability records what every layer did. AI can generate applications and nets, operate them and improve them, but always inside explicit capabilities, budgets and history.

The runtime below, applications above

This picture is the mental model for the rest of the article. The live Agentic Petri-net runtime is the durable substrate: places, tokens, transitions, schedules, policy, executors and event history. The application layer is everything a person actually opens: a Kanban board, an approval room, a research desk, a goal tracker, or a purpose-built product generated for one net. An application consumes tokens from declared places and creates intent tokens through declared actions. It does not copy the process into a private backend. The application and the operators, agents and deterministic lanes all meet in the same live state.

AI can build and operate both halves through MCP. It can create a net, deploy its transitions, declare the stores and actions of an application, and generate the application itself. But AI does not sit outside the architecture as an all-powerful black box. Once generated, the application is governed by the same API. Intelligent work is carried by a bounded LLM transition, a bounded agent transition, a persistent persona net, a command transition that starts a headless agent on a local or remote executor, or a connected MCP client with explicit authority.

The runtime underneath those applications stays alive. Its state persists as tokens, its structure can change while it runs, and deterministic automation and AI are equal execution mechanisms. People, resident agents, connected agents and code can work on the same process for months. Everything they do is recorded, so “what happened and why” is a query rather than a guess. The shortest version is still useful: workflow engines execute runs. Agentic-Nets operates evolving systems.

The formal foundation is the Petri net. Places hold state. Tokens are work items, context, decisions and evidence as structured JSON. Transitions consume tokens, perform an action and emit tokens into other places. Arcs declare the allowed flows. In Agentic-Nets this graph is not just a drawing of the system. It is the running system, and applications are live projections over it.

Three Kinds of Hands on One Runtime

The property that makes everything else interesting is this: humans, AI agents and deterministic processes live together in the same net, and all three can act on it while it is deployed and running. They act on the same two things. The state: tokens in places. And the structure: places, transitions, arcs and the inscriptions that define what each transition does. They enter through different doors, but it is one runtime, one protocol and one history underneath.

Humans

A person can open the Studio canvas and see the live net with token counts on every place. They can drag a new place onto it, wire a transition, edit the inscription in the editor, start or stop a lane, or fire it once by hand. In the token workbench they can create, inspect, delete and export tokens. But most people never touch the canvas: they work through applications, purpose-built surfaces over the same places. A Kanban board is a projection of a backlog place. The Approval Room is a projection of a place where proposals wait for a human decision. Clicking Approve writes a token. That token is what the next transition consumes. There is no other channel, and nothing hidden behind the button. The application layer gets its own section below, because it is the part that turns a runtime into products.

LLM transitions: one bounded judgment

An LLM transition makes one model call per fire. It binds input tokens, constructs a prompt, receives one response and emits structured output tokens. Use it when the work is naturally one bounded judgment: classify this request, extract these fields, summarize this evidence, score this result, or draft this paragraph. It has no autonomous tool loop. That simplicity is a feature. The input, output, token cost and model are easy to inspect, and the lane is easy to replace with a deterministic map when the pattern stabilizes.

Agent transitions: bounded tool-using work

An agent transition is a different execution primitive. It runs a bounded reasoning loop and can use tools between model turns. Its role and capability flags decide whether it may only read the net, write tokens, fire transitions, inspect logs, run scripts, coordinate with other personas, or call explicitly declared external MCP servers. Iteration caps, timeouts and a per-fire budget end the loop. The transition still begins by consuming tokens and ends by producing tokens, so its autonomy lives inside the same Petri-net contract as a map or command lane.

With the right capabilities, an agent transition can also change structure: create a place, add a transition, set its inscription, deploy it and start it. Outside the net, Claude Code, Codex, Cursor or a custom agent can connect through the Agentic-Nets MCP server and use the same building blocks: inspect, design, deploy, fire and observe. The difference is location and lifetime. An agent transition is execution inside a firing lane. An MCP client is an external operator acting on the runtime.

Personas: durable agents made from nets

A persona is not just a large prompt and not just one agent transition. It is a small persistent net around intelligent execution: a charter place, an inbox, durable context, a reasoning lane, an outbox and history. The net gives the role memory, a queue, schedules, delegation and a visible contract. The safe product team on my staging server has a developer persona that writes code and a runtime steward persona that reads the history of other nets and proposes improvements. Stop the reasoning lane and their state remains. Replace the model and their inbox does not move. That separation between actor, execution and state is the point.

Deterministic processes

Pass, map, HTTP, command and link transitions do the unglamorous majority of the work: route, transform, call an API, run a script on an executor, connect two pieces of knowledge. They fire on their own schedule, cron or interval, or whenever their input places hold matching tokens. They gate, count, meter and dedupe. And because an HTTP lane runs on the master and can call the runtime’s own API, deterministic lanes can even repair or extend structure: I have used a temporary lane to fix forty misplaced canvas elements in single fires and then delete its own shape. The point is not that code should rewrite the net. The point is that nothing in the architecture makes code a second-class citizen next to the agent or the human.

Why this is not “human in the loop”

Human-in-the-loop means a program pauses and waits for a person. What happens here is different in kind: the person, the agent and the code are all in the net, as peers, each consuming and producing tokens, each bounded by the same policy envelope, each recorded in the same history. A human approval is a place with a token in it. An agent decision is a place with a token in it. A script result is a place with a token in it. Downstream transitions do not care which kind of hand produced the token. That symmetry is what lets you move work between the three over time, which is the subject of the crystallization section below.

Every Transition Is Its Own Deployment

Here is the mechanical fact that makes “change it while it runs” real rather than a slogan. In Agentic-Nets, deploying a net is not one deployment. It is N independent deployments that happen to share places. Each transition carries its own inscription (what it consumes, what it does, where it emits), its own credentials in the vault, its own executor target, its own schedule, its own role flags and budget, its own status, its own metrics and its own slice of the event history. You deploy a transition. You start it. You stop it. You fire it once. You replace its inscription. You remove it. The transitions next to it never notice, because the only thing they share with it is a place, and places outlive everything.

An inscription is a small JSON document. This one is a real shape: a triage lane that consumes new tickets from an inbox, asks a model to classify them, and routes the answer to one of two places depending on confidence. Notice what is not in it: no API key, no server address for the model, no code. The credentials live in the vault under this transition’s key. The model comes from a configured provider or tier. The routing is declarative.

{
  "id": "t-triage",
  "kind": "llm",
  "presets": {
    "ticket": { "placeId": "p-inbox", "arcql": "FROM $ WHERE $.status==\"new\" LIMIT 1", "consume": true }
  },
  "postsets": {
    "triaged": { "placeId": "p-triaged" },
    "review":  { "placeId": "p-human-review", "capacity": 20 }
  },
  "action": {
    "type": "llm",
    "tier": "low",
    "prompt": "Classify this support ticket. Reply as JSON {category, urgency, confidence}.\n${ticket.data.text}",
    "timeoutMs": 240000
  },
  "emit": [
    { "to": "triaged", "from": "@response.json", "when": "confidence >= 0.8" },
    { "to": "review",  "from": "@response.json" }
  ],
  "mode": "SINGLE"
}

Because this is the whole contract, three consequences follow. You can publish a net without scrubbing secrets, because there are none in it. You can hand the same inscription to a different executor or a different model tier by changing one field. And you can replace the lane’s kind while keeping its presets and postsets: the day this classifier becomes predictable enough, an equivalent map or HTTP lane with the same places takes over, and the LLM lane is stopped, not deleted, so rollback is one start and one stop.

The Living Net: Extend It, Shrink It, Never Stop It

Put those two properties together, three kinds of hands and per-transition deployment, and you get a net that can be extended and reduced at any time. Not in a maintenance window. Not by redeploying a definition and hoping in-flight work survives. While it runs, with tokens in it, with people using the applications on top of it.

Read the three rows as one story. On day one, nobody knows the process, so an agent handles every request end to end. It is expensive, it is occasionally wrong, and it is the right choice, because you are still discovering what the process even is. By day two the event history already shows what the agent does every time: it validates the input, looks something up, decides, and checks the result. So a person, or a runtime agent, adds three deterministic lanes around it. The agent lane is not touched. It just starts receiving cleaner tokens. By day three the decision itself has become predictable for the common cases, so a pass transition with a query takes the known ones for free and the agent stays for the exceptions. The verification lane turned out to be unnecessary and was stopped, then removed. The net grew, then it shrank. It never stopped, and the tokens that arrived on day one are still in the request and result places, with their lineage intact.

This is the crystallization loop that earlier articles describe from the cost angle. On one real reporting lane, the agent version consumed 821,000 LLM tokens per fire, and the crystallized replacement does the same job with zero. What I want to stress here is the other angle: crystallization is only possible because the net is live and per-transition. You do not redesign and redeploy a process. You add a lane, watch it, stop the old one. The platform never rewrites itself silently: changes are proposed against evidence, approved, versioned, and verified, and the previous structure stays available for rollback.

An Application Layer on Top of the Runtime

The runtime is only the lower half of the product. The upper half is the part people actually use: Agentic-Nets has a first-class application layer, and its applications live on top of live nets, not next to them. A Kanban board, a goal tracker, an interview desk, a protocol journal, an approval room, a research dashboard with Accept buttons. Each is a human-facing application in the ordinary sense, installed and opened from Studio. None needs a separate process database or a second copy of the business rules.

An application is a versioned package containing an ordinary session runtime plus an application manifest and, optionally, a verified browser UI. The manifest maps semantic store roles such as backlog, proposals or done to places. It also declares the actions the UI may take, the shape of the token each action writes, and the guard that must still be true when it writes. The package installs from NetHub and appears in Studio next to the built-in applications. It comes in two honest shapes. A generic surface is pure declaration, so Studio renders lists, readers and buttons from the manifest. A web-component surface adds a small component for a custom experience such as a coverage matrix, verdict chips or a drafts reader. Both bind to the runtime through the same contract, and you can start with the first and graduate to the second without touching the net.

Compare the two architectures. A conventional application is a stack: UI, then an API, then business logic, then a database that belongs to that one application. An Agentic-Nets application is a projection: UI, then the runtime, then places and tokens, then the nets, personas and tools that already operate on them. The business logic is the net. The database is the places. Because of that, several applications can look at the same process from different angles at the same time with no synchronization: Kanban shows the work items, the Approval Room shows what is waiting for a person, Protocol shows the narrative, Goals shows the objectives, and your own dashboard shows whatever you care about. They are all consistent because they are all reading the same tokens.

The same contract is available to every kind of participant. A human drags a card in Kanban. An MCP-connected coding agent moves the same work item after finishing a task. A deterministic transition changes its status after a test passes. All three manipulate the same token through the same runtime rules, and every installed application sees the result immediately. This is how an application becomes part of a multi-agent operating system rather than a decorative dashboard placed beside one.

The actions deserve a closer look, because they are where governance meets the mouse. An application button never executes anything. It writes a token that records intent: a decision, a request, a status change. A lane in the net picks that token up, builds the actual command, and dispatches it to an executor, or a gate joins it with the proposal it refers to. The guards on actions are real compare-and-set conditions, evaluated against the live place: only if no token with this URL exists yet, only while this task is still in the accepted state, and the effect commits atomically with the write. So a click in an application carries exactly the same governance as a token written by an agent or a script: the budgets, the executor boundaries, the approvals and the audit trail all apply, because the work it triggers is ordinary net work.

This is also what makes the living net safe to change under load. Users keep clicking Accept while you swap the lane behind the button, because the button binds to a place, not to a transition. The Web Investigator’s staff writer was replaced by a headless Claude Code lane while people were using the application; the Draft button never changed. And because an application is a declaration over places, the same coding agent that builds a net through MCP can build the application over it in the same session. That is what “prompt in, application out” meant in practice: the net, the personas, the scripts and the application are four faces of one runtime, and a complete product is all four of them together.

Five applications ship today: Kanban over work-item places, Goals for objectives and progress, Interview for structured question-and-answer sessions, Protocol for the readable journal a team writes for people, and the Approval Room for every place where a human decision is the next transition. Read-only share links are the simplest application of all: the live net itself, rendered in the same editor operators use, for anyone with the URL. And your own is one JSON envelope away.

What Is in the Box Today

Now the inventory. This is what ships in release 2.57.0, as one desktop download or one Docker compose file, organized by the layers of the stack. If you only want the picture, it is below; the subsections spell out each layer.

State: places, tokens, queries

Places are persistent, event-sourced containers of JSON tokens, hosted by the node service and queryable with ArcQL, a small query language over what is actually sitting in a place (FROM $ WHERE $.status=="active" AND $.retries < 3 LIMIT 1). Tokens carry data plus metadata: id, name, parent place, timestamps, provenance. Postsets can declare a capacity (blocks the producer, the backpressure primitive) or a retain count (evicts the oldest, the rolling-log primitive). Large payloads (fetched pages, build logs, generated documents) go to the BlobStore as content-addressed blobs so tokens stay small, and any place exports as JSON or CSV from the token workbench. Tokens are reserved atomically when a transition binds them, so two lanes racing for the same work cannot both take it.

Execution: the seven kinds of transition

A transition fires in SINGLE mode (all input presets must bind, one action, one emission) or FOREACH mode (one fire per token, bounded parallelism). Emission is declarative: a list of rules routing the result to postsets with optional conditions, fan-out from arrays to many tokens, and a catch-all so no token is ever silently lost. Schedules are per transition: cron with a grace window, or a fixed interval, or purely token-driven. Deterministic lanes run for free and forever. The two AI kinds are the only ones that spend, and the meter tells you exactly how much.

Agents, personas and governance

An agent transition runs an LLM in a loop with tools. Which tools it can even see is decided by eleven independent capability flags: read, write, execute, http, logs, user, docker, coordinate, tooling, scripts, and mcp. A read-only reviewer sees query tools and nothing else. A developer sees read, write and execute. Only an agent with the mcp flag can reach the external MCP servers its inscription explicitly declares, with credentials resolved from the vault. On top of the flags sit iteration caps, per-fire budgets, timeouts, a thinking-model escalation for hard cases, and model groups that route each lane to a tier or a specific provider and model, so a cheap classifier and an expensive analyst can live in the same net with a one-line difference. Every fire writes its token count, turns and cost back into the runtime where the next lane can read them.

A persona is the unit you actually design with: a charter, an inbox place, an outbox place, durable context places, declared tools, a role, a budget. Personas can delegate to other personas and collect results. Capability packs take this one step further: a pack is a persona plus a deterministic pipeline behind it, published with a machine-readable entry contract, so that any client can find it and hand it a task in plain language. Three ship today (a token janitor, a place inspector, and the web investigator), and each follows the same doctrine that fell out of building them: the agent decides, the deterministic pipeline measures, and the structure makes it impossible for the agent to report a number it did not actually observe.

Where the intelligence comes from

• A server-side provider. Configure Claude, OpenAI, or Ollama (local or cloud) and the master executes llm and agent lanes itself. The always-on mode.
• The MCP client you already have. Claude Code, Codex or another client hosts a lane: the runtime prepares context and prompt, the client reasons with its own model, the result returns to the normal token flow. No API key on the server. Tokens wait safely when the client is not connected.
• A headless coding agent on an executor. A command lane starts Claude Code or Codex non-interactively with an allowlist of tools. This is how the staff writer in the research desk drafts articles and how the developer in the safe team writes code.
• None. A net of pass, map, http, command and link lanes is a complete, useful system with no model anywhere. Many production lanes end up here after crystallization.

The execution boundary: executors, vault, gateway

Commands never run on the master. They run on executors, which poll for work through an OAuth2 gateway using a JWT scoped to the polling protocol and nothing else. Egress only: an executor can sit on a laptop behind NAT, on a build machine in a datacenter, or on a server that touches internal systems, and none of them opens an inbound port. A transition picks its executor in its inscription, or offers the work to any executor with first-token-wins reservation. Scripts are versioned artifacts in a tool catalog (scripts, HTTP services, Docker tool images, reusable tool nets), scoped per model with a global fallback. Credentials live in the vault, backed by OpenBao on a server or by an encrypted local file on the desktop, keyed per model and transition, resolved at fire time. The gateway issues three kinds of client credential: admin, read-only, and executor.

Human surfaces

Studio is the canvas: the live net with token badges and running indicators, an inscription editor, a token workbench, a monitoring view, a Universal Assistant that works under its own capability flags, and Genesis, a full command room persona. Applications are installable views over live places, listed next to each other in Studio: Kanban, Goals, Interview, Protocol, Approval Room, plus any you declare yourself as a JSON envelope of stores and guarded actions, with an optional web component for a custom look. Share links publish a net read-only to anyone with the URL, rendered in the same editor operators use. A Telegram bot and a CLI round out the doors for people.

The control plane: MCP and REST

The Agentic-Nets MCP server exposes the runtime to any MCP client as working memory that runs plus a net workbench: a curated surface of lowercase tools (build nets, add transitions, set schedules, spawn personas, fire once, query tokens, read event trails, run diagnostics, install from NetHub) and an optional native layer with the full platform catalog. A read-only mode registers only the observation tools and authenticates with the read-only client so the gateway itself refuses mutations. Two tools matter more than the rest for a live system: a readiness check that walks the whole dependency chain in one call, and pause and resume, a model-wide kill switch that stops every running lane, writes an audit token, and later restores exactly the set it stopped. Everything the MCP server does is also a REST call on the master and node, which is how Studio and the applications work.

claude mcp add agenticnets \
  -e AGENTICOS_GATEWAY_URL=http://localhost:8083 \
  -e AGENTICOS_ADMIN_SECRET=<your-gateway-admin-secret> \
  -e AGENTICOS_MODELS=my-first-model \
  -- npx @agenticnets/mcp

Memory and evidence

Every mutation is an immutable event. From that one fact follow the tools I use every day: the event trail of a transition or a place, token lineage (which fire produced this token, from which inputs), the protocol journal (the readable narrative of milestones a team writes for people), the usage report (ranked LLM burn per transition, split scheduled versus on demand), the scheduler status (last fired, next due, why not), and per-transition diagnostics that explain why a lane did not fire: empty preset, capacity block downstream, schedule not due, token reserved by someone else, no executor polling this model. OpenTelemetry traces, Prometheus metrics and Loki logs are wired in with trace ids in every log line for the operators who want dashboards.

Distribution and deployment

NetHub publishes and installs nets, sessions, whole models, personas, teams, tool nets and applications as versioned, credential-scrubbed packages, from a local hub or a peer instance. Capability packs are the same idea as code: a compact source file and a charter in markdown compile into the full net, so a persona can be reviewed in a pull request and installed with one command. The runtime itself ships three ways: Desktop Lite (one installer for macOS, Windows and Linux, no Docker, no Java, no API key, the MCP server and vault and executor bundled), the Docker stack (shared machines, monitoring, tool containers, remote executors), and a multi-master cluster (masters partitioned by model behind one gateway, egress-only executors, the observability stack).

Ten Use Cases, One Runtime

The runtime is domain-general, which is not the same as domain-omniscient. It does not arrive knowing your industry. You supply the context, the policies, the integrations and the authority boundaries; it supplies the substrate that keeps the process alive, governed and observable. Here are ten shapes I either run today or have designed with users, each with the three hands and the kind of change you would make to it while it runs. The first two are real and running.

Software delivery: the one that builds this platform

The safe product team on my staging server is the longest-running instance. A human posts a topic in a forum. A poller lane turns it into a story token. A product persona writes acceptance criteria, an architect persona proposes the change, a developer persona (headless Claude Code on an executor with a deploy key) implements it, a deterministic QA gate probes the running endpoint with retries, bounded rework loops back at most three times before a human review place takes over, and a release persona posts the result back to the forum. It has shipped real commits to real repositories; one story went from forum post to live endpoint in under three minutes. Every improvement to the team since then was a live change: the QA gate that can fail, the UI fork with a separate developer lane, the cost meter that writes tokens and dollars into a metering place, the classifier that routes stories between backend and frontend. Not one of them stopped the team.

Competitive research: the one with a staff writer

The research desk runs on my desktop. Thirty-one places, twenty-six transitions, and exactly three of them think: a categoriser that labels pages which already passed a free relevance gate, an analyst that interprets facts a rollup script computed, and a staff writer that drafts from an evidence packet. Everything else is scripts and maps. The application over it has stores and actions; the human decision loop is Accept, Draft, Done, and each button writes one token. The interesting part for this article is the change log: a sitemap harvester was added as a new lane to onboard whole websites; the writer was swapped from a server-side agent lane to a headless Claude Code command lane, with the old lane left stopped as a fallback; the recency buckets were changed to re-bucket by current age at every rollup. The crawl never paused for any of it.

Incident operations: the three hands in one picture

Here is the incident shape drawn out, because it shows all three hands in one small net and it shows what a live change looks like. A signal arrives (an alert webhook, a failed probe). A command lane collects diagnostics on the machine that has them; a map lane normalizes; an SRE persona investigates and writes a proposal. The proposal appears in the Approval Room. A human approves by writing a decision token, a pass gate joins proposal and decision, a command lane remediates, an http lane verifies. By day three, the event history shows that a third of all incidents are one known class with one known fix, so someone adds a pass lane from diagnosis straight to proposal for that class. The agent keeps handling the rest.

How This Differs From n8n, Zapier and the Agent Frameworks

The comparison has to start with what these products are now, not what they were three years ago. n8n combines API automation, deterministic nodes and AI capabilities, and it provides execution history. Zapier defines a Zap as a trigger followed by one or more actions, and its current AI product can place autonomous reasoning and tool use inside an AI by Zapier step. Both product families can include AI, human approval, logs and persistent data. So the difference is not that Agentic-Nets has AI and they do not.

The structural difference is the unit being operated. An automation platform primarily defines a workflow that produces executions. An agent framework primarily defines an agent loop or graph inside an application. Agentic-Nets primarily defines a persistent, event-sourced runtime graph: the work remains in places, multiple actors operate on it over time, applications project it for people, and individual transitions can be replaced while the surrounding process stays live. It answers a different question: how do I operate an evolving process that people, agents and code share for months?

Durable-execution engines such as Temporal deserve a separate sentence, because they also keep long-running work alive. They do it for code: your program is the process, the engine makes it survive crashes and retries. That is excellent for what it is, and it is a different thing. The process in Temporal is written by a developer and changed by versioning code. An Agentic-Net is a shared graph that a human on a canvas, an agent through MCP and a scheduled lane can all extend, and the graph is also the audit trail and the governance boundary.

And the honest line. If your automation is integration-shaped and naturally expressed as a sequence of executions, n8n or Zapier will usually get you there faster. If you are building one focused agent in code, an agent framework is usually the right starting point. Agentic-Nets is for the moment exploration turns into operations: work that remains alive for months, several kinds of hands manipulate the same state, parts of the process have to change independently, and the system must explain what happened. It does not replace every workflow or every agent framework. It is the runtime in which their useful ideas can become governed participants in a living system.

The Reality Today

Agentic-Nets is beta software under active development, built by one person with a lot of help from the agents it runs. Here is what is proven, meaning running with real tokens right now, and what is still rough.

Proven in production use

• The safe product team has shipped real commits to real repositories from forum posts, through personas, a QA gate that can fail, bounded rework and a human review place, and every one of its improvements landed as a live change.
• The research desk crawls, scores, analyzes and drafts on a desktop install, with a human-facing application over the live places and three narrow lanes doing all the thinking.
• Natural-language delegation to a capability pack works end to end: a client asks in a sentence, the persona parses intent, a deterministic pipeline measures, executes and re-measures, and the reply carries numbers the agent could not have invented.
• Crystallization is measured, not hoped for: a lane that cost 821,000 tokens per fire runs at zero, with the old agent lane stopped and intact.
• Read-only share links serve real nets from the public instance to anyone with the URL, in the same editor operators use.
• The whole stack installs as one desktop package on macOS, Windows and Linux and runs with the MCP client you already have and no API key.

Rough edges I know about

• Integrations are generic. There is no catalog of five hundred SaaS connectors; you use http lanes, command lanes, MCP servers and the tool catalog. Flexible, less convenient.
• Installers are unsigned, so the operating system asks you to approve the first launch. Checksums and an Ed25519 signature ship with every release.
• “Change it while it runs” is safe for places and tokens without exception, and safe for transitions with a few documented lifecycle edges: a command lane that is mid-flight finishes on the contract it started with, a rescheduled interval lane wants a stop and a start to re-arm, and an agent lane caught mid-fire by a master restart needs its lane restarted. I treat these as product bugs, not caveats, and they are on the list.
• Model-level permissions exist at the gateway and in the MCP server’s allowlist, not per place. Fine-grained authorization inside a model is on the roadmap.
• Agents still confabulate when you let them do arithmetic. The cure is structural and it is the platform’s own doctrine: let the agent decide, let deterministic lanes measure. Every pack that ships follows it, and you should too.

A Day With the Runtime

What does working with this actually feel like? Less like programming and more like running a small department. You open your MCP client and ask for readiness: is the gateway up, does the model exist, is a provider or an executor available. You describe the process in plain language, or pick a starter pattern, and the client builds the net against the live runtime with the same protocol tools it will use tomorrow. You fire the first transition once, watch a token land, and start the lanes. Then you leave.

The next morning you look at the net overview and the usage report. Which lane burned the most? Which one did not fire, and what does the diagnosis say? You open the application and clear the approvals waiting for you. You notice the analyst persona makes the same call every time for one class of input, so you ask the client to add a pass lane for that class and watch the meter drop. You publish the net to NetHub so a colleague can install it against their own places. Nothing you did required a redeploy, and every step you took is in the event history next to the steps the agents took.

That is the whole promise, stated as a routine rather than a feature list: the process keeps running, three kinds of hands keep improving it, and the runtime keeps the receipts.

See It Live, Then Try It

Three real nets run on the public instance behind read-only share links, no install and no login. Token Flow Basics is the smallest useful net. The Seven Transition Types shows deterministic and intelligent execution side by side. Crystallization shows AI-assisted discovery becoming deterministic structure through an approved change. And the Hardened Lane is one governed delivery lane with validation, bounded AI work, a QA gate, rework, human escalation, deployment and verification.

To run your own, download Desktop Lite from the latest release: one installer, no Docker, no API key. Open the tray icon, connect Claude Code or Codex from the menu, and in a fresh session ask your client to read the starter patterns and build the smallest example for your installation. Or run the shared stack:

git clone https://github.com/alexejsailer/agentic-nets.git
cd agentic-nets/deployment
cp .env.template .env
docker compose -f docker-compose.hub-only.no-monitoring.yml up -d
cat data/gateway/jwt/admin-secret
# Studio on http://localhost:4200

Start with one process you already run by hand and wish would keep running without you. Give the judgment calls to a persona, give the bookkeeping to deterministic lanes, keep the consequential decision in an approval place for yourself, and then change it while it runs. That last part is the one you have to feel to believe.

Written against Agentic-Nets 2.57.0. The software delivery and research examples are running systems; the incident, support, compliance, hiring, content, knowledge, procurement and lab shapes are designs built from the same primitives. The 821,000-to-zero number comes from the production instance that builds, tests and ships this platform. The source for the open components, the book chapters that go deeper on Graph Engineering, and the documentation are at github.com/alexejsailer/agentic-nets and agentic-nets.com.

Related: Ten Reasons I Run Agentic-Nets Instead of n8n • Agentic-Nets for Any Domain • Your Agent Can Use Any MCP Server • One Download, No Docker, No API Key • Watching the Meter