Agentic-Nets

Agentic-Nets / AgenticOS: Petri Nets as Agents, Agentic Processes & Remote Executors

We live in a strange moment in software automation. On one side we have no-code and low-code platforms that let us drag and drop agentic processes together. On the other side we have AI agents that promise to “just do things” for us.

In practice, both worlds often share the same problems:

• Agentic Processes become black boxes – it’s hard to see why something happened.
• Agents are hidden prompts with tools attached, not real, inspectable systems.
• Debugging and monitoring are painful and scattered across tools.
• It’s hard to cleanly combine automation, agents, executors and humans in one model.

Agentic-Nets / AgenticOS is my answer to this gap.

What are Agentic-Nets?

Agentic-Nets are visual Petri nets designed for the age of AI agents, remote executors, and modern automation.

You model your system as a graph of:

• Places – buckets that hold data as JSON tokens.
• Tokens – the actual data, events, and intermediate results.
• Transitions – active steps that are configured via inscriptions and can:
  • Call HTTP APIs,
  • Run commands on remote executors,
  • Transform / map data,
  • Pass data through, route, or filter,
  • Or call an LLM, up to full agent transitions that can do multiple steps.

The twist:

Every Agentic-Net can be seen both as a agentic process and as a domain agent.

As a flow, it orchestrates tools, APIs, executors and sub-processes. As an agent, it behaves like a specialist: it has skills (transitions), memory (places/tokens), control logic (the net itself), and – if you want – its own LLM- or agent-based “brain”.

Instead of:

“I have some hidden agent prompt that sometimes works…”

you get:

“I have a visual, inspectable Agent-Net that I can design, test, debug, monitor – and even change at runtime.”

From Model to Runtime: Master, Node & Executors

Under the hood, Agentic-Nets are not just diagrams. There is a concrete runtime architecture behind them:

• Angular UI – the visual editor and console. You design Petri nets, define inscriptions (HTTP, MAP, PASS, LLM, AGENT, COMMAND), inspect tokens, and manage deployments.
• Master – the central orchestrator. It:
  • Binds tokens to transitions (Petri net semantics),
  • Executes local actions (HTTP, MAP, PASS, LLM, AGENT),
  • Delegates COMMAND transitions to remote executors,
  • Emits new tokens back into the net.
• AgenticNet Node – the persistence layer. It sits typically in a private subnet of a VPC and stores nets, tokens, and state. The master talks to it via a secure, internal connection.
• Remote Executors – lightweight worker processes, often in other networks or regions. They:
  • Have only outbound connections,
  • Poll the master for COMMAND payloads,
  • Execute the commands in their local environment (including MCP tools),
  • Send results back, which the master turns into new tokens.

Result: the net logic & state live in the master + node, while side effects and tools live in remote executors with a very clear boundary.

Design-Time vs. Runtime

The Angular UI supports both phases explicitly:

• Design-time – draw places and transitions, define inscriptions, connect arcs, configure presets/emits, and let AI help you generate parts of the net from natural language.
• Runtime – inspect live tokens, trigger transitions manually, tweak inscriptions, add or remove transitions and arcs, and redeploy nets while they are running.

The idea: a net is not a static drawing. It is a living structure that you can evolve while traffic runs through it.

Inscriptions: HTTP, MAP, PASS, LLM, AGENT, COMMAND

Each transition has an inscription that defines what it actually does when it fires:

• HTTP – call REST or internal services. Request is built from preset tokens, response becomes new tokens on the emit side.
• MAP – deterministic data transformations: mapping JSON schemas, enriching, filtering, calculating values.
• PASS – cheap pass-through / routing logic. Good for branching, validating, or quickly wiring stages together.
• LLM – a single LLM step. It:
  • Builds a prompt from preset tokens,
  • Calls an LLM,
  • Parses the result into emit tokens (e.g. classification, extraction, or small decisions).
• AGENT – a multi-step agent loop in a single transition:
  • Can see the whole net around it (places, transitions, context),
  • Can do multiple LLM calls (plan, reflect, refine),
  • Can interact with other nets or shared places,
  • Finally emits tokens that represent plans, commands, or results.
• COMMAND – a remote command. The master does not execute it directly; instead it:
  • Creates a command payload based on preset tokens,
  • Queues it for remote executors,
  • Waits for executor results and turns them into emit tokens.

All of this still respects classic Petri-net semantics – the inscriptions just define how a firing step interacts with the outside world or an LLM.

Net as Flow vs. Net as Agent

Agentic-Nets make sense in two complementary modes.

1. Net as Flow

You model a process:

• Places as states and queues (for example, “Incoming Requests”, “Validated Data”, “Ready to Send”).
• Transitions as actions (HTTP calls, mappings, command executions).
• Tokens flowing through the net, showing where each case currently is.

That alone is powerful for orchestration and visibility – especially when you can inspect tokens in every place in real time.

2. Net as Agent

Now add LLM and AGENT transitions:

• An LLM or AGENT transition reads tokens from places as rich context.
• It calls an LLM with a clear role (for example, “planner”, “summarizer”, “tool orchestrator”).
• It emits new tokens (plans, decisions, enriched data, or generated commands).

The net itself becomes an agent:

• Skills = transitions (including deterministic and agentic ones).
• Memory = places & tokens.
• Control flow = arcs & firing rules.
• Brain = one or more LLM / AGENT transitions + remote executors with tools.

Often you start with “Net as Flow” and gradually add more “Net as Agent” capabilities where it makes sense.

Why not just use no-code / low-code platforms or a coding agent?

Compared to no-code / low-code platforms

No-code and low-code platforms are great at:

• “When X happens, call Y API, then do Z.”

But they tend to be:

• Linear and static,
• Hard to debug in detail (“what exactly was in that step?”),
• Not built for agents that reason, summarize, or re-plan on top of deterministic calls.

Agentic-Nets give you:

• Token-level visibility – you can see and inspect every piece of data in any place.
• Petri net semantics – natural parallelism, branching, and synchronization.
• LLM / AGENT transitions in front of deterministic transitions – so natural language gets turned into clean, repeatable HTTP or COMMAND calls.

You can still call your existing no-code / low-code flows from a transition. Agentic-Nets become the command center and analytics layer above them, not a replacement.

Compared to classic coding agents

Coding agents are great at writing and refactoring code, but often:

• Are just one big prompt with some tools,
• Don’t live as persistent, structured processes,
• Are hard to reuse and test as building blocks.

Agentic-Nets give you:

• Explicit structure instead of a hidden internal chain-of-thought.
• Testable agent behavior – you inject tokens, run simulations, and inspect results step by step.
• Reusable front-door nets for typical tasks like “understand request & route to deterministic transitions”.

Key Use Cases (Updated to the New Runtime)

1. LLM Front-Door in Front of Deterministic APIs

A very common pattern in this architecture is:

LLM / AGENT transitions in front, deterministic HTTP or COMMAND transitions behind.

• Input place receives natural-language tasks (e.g. “Reset my password”, “Generate weekly report for project X”, “Check weather for tomorrow in Berlin”).
• An LLM or AGENT transition analyzes the text, determines intent, and emits:
  • Structured parameters (user id, project id, city, date),
  • A selected route (which deterministic transition should follow),
  • Or even a list of commands to run on remote executors.
• Downstream HTTP transitions call your existing REST APIs or backend services.
• If needed, COMMAND transitions send tasks to remote executors (e.g. to run MCP tools or access on-prem systems).

This front-door net can be reused across projects. You simply plug different deterministic transitions behind it.

2. Smart Weather Decision Net (Centralized Weather Logic)

Example from our discussion: a central weather net for multiple services that don’t know or care about the actual weather API.

• Services drop “tasks” as tokens into an WeatherTask place (free-text descriptions like “plan outdoor meeting tomorrow in Berlin”).
• An LLM transition decides:
  • Is weather needed at all?
  • Which location and time?
• If needed, it emits a clean WeatherQuery token (city + date), which feeds into an HTTP transition calling the weather API.
• The response becomes WeatherResult tokens that other nets or services can consume.

All callers just know: “Put a token into the net, get a unified result back.” The details (API vendor, schema quirks) live inside the net.

3. Net That Designs Other Nets

Your AgenticOS exposes APIs like createPlace or createTransition for a given net. Now you can build a meta-net that designs nets for you:

• Input place gets tasks like “create a net that checks inbox, summarizes new emails, and posts a daily digest”.
• An AGENT transition analyzes the task and generates:
  • Candidate places and transitions,
  • Concrete HTTP calls to the master API to create them.
• Downstream HTTP transitions call the AgenticOS API to actually create those places/transitions in a target net.

In this setup, a net becomes an agent that builds other nets – fully aligned with the architecture (master + node) and still traceable as Petri-net logic.

4. MCP-Enabled Tool Agent via Remote Executors

Remote executors can host an MCP server (Model Context Protocol) that exposes tools like “run shell command”, “query database”, “read log file”. A typical flow:

• Task token: “Analyze today’s logs and summarize errors.”
• An AGENT transition plans MCP commands (list files, read logs, filter for errors).
• Those commands are emitted as tokens into a COMMAND transition.
• A remote executor polls, picks up the command, runs the MCP tool, and returns results.
• Results become tokens for another LLM/AGENT transition that summarizes findings into a human-friendly report.

The full loop is visible as tokens and transitions, while the actual execution happens safely on the executor side.

How it feels to work with Agentic-Nets

Working with Agentic-Nets / AgenticOS typically follows these phases:

• Design Phase – Draw places and transitions in the Angular UI, attach inscriptions (HTTP, MAP, PASS, LLM, AGENT, COMMAND), optionally let an LLM help generate them from natural language.
• Exploration Phase – Inject example tokens, test APIs, check how preset/emits behave, inspect token content.
• Testing & Simulation Phase – Run nets with test data, watch tokens move, verify that AGENT/LLM transitions produce correct deterministic calls behind them.
• Deployment Phase – Mark nets as deployed, connect remote executors, and let the master orchestrate real traffic.
• Interactive Operation Phase – While the system runs, inspect state, adapt nets, tweak instructions, and even hot-deploy new transitions.
• Monitoring & Evolution Phase – Build observer nets to aggregate metrics, drive analytics and AI-based summaries, and refactor large nets into reusable front-door modules.

What’s next?

Agentic-Nets / AgenticOS is my approach to bringing Petri nets, agents, remote executors and practical automation together in one visual model. It is designed so that complex flows and agents are observable, testable, composable – and evolvable at runtime.

On this blog I will share more concrete examples (email analysis, log analysis, integration scenarios) and show how the visual editor and the master / node / executor architecture play together.

If you’re curious and want to:

• Design your own Agent-Net,
• Wrap an API behind an LLM/AGENT front-door net,
• Or connect MCP-enabled executors to a Petri-net based control plane,

…then stay tuned here. And if you know me personally, feel free to reach out – I’m happy to give you an early demo of AgenticOS / Agentic-Nets.