Agentic-Nets Is a Backend, Not a Demo: 14 Kinds of System You Can Run on a Petri Net

Agentic-Nets Is a Backend, Not a Demo

It’s easy to show an AI agent doing one cool thing once. It’s much harder to answer the only question that matters for real work: what can I actually run on this? This is the answer: Agentic-Nets reframed as a backend, and a map of the fourteen kinds of system that fall out of it cleanly.

The Problem: A Demo Is Not a Backend

Most agent demos, ours included, are a screenshot and a vibe. An agent writes a function, files a ticket, drafts an email, and everyone nods. But you don’t run a claims pipeline, an approval flow, or a nightly reconciliation job on a chat transcript. Transcripts are ephemeral, unauditable, and impossible to resume. The moment work has to survive a restart, wait for a human, retry an API, or prove what happened, a clever prompt loop stops being enough and you need a backend.

So here’s the reframe. Forget “autonomous agents you watch.” Look at AgenticNetOS the way you’d look at Temporal, Step Functions, or an event-sourced state store: as the substrate you build services on. Once you do, a surprisingly large slice of everyday backend work maps onto it, and a few things light up that no ordinary backend gives you.

One Mental Model

There’s a single test for whether your problem fits:

If you can draw it as work items moving through stages (some need judgment, some call an API, some run a command, some just route), it maps onto Agentic-Nets as a backend.

• Tokens are the work items: durable, queryable JSON with provenance, not ephemeral queue messages.
• Places are the stages, queues, and state your work sits in.
• Transitions are the steps, in seven flavours, each a recognisable backend primitive.

What makes those primitives a backend rather than a flowchart is the machinery underneath: an event-sourced token store (immutable, replayable, audit-trailed), a query language over live state (ArcQL: FROM $ WHERE $.status=="active"), real concurrency control (token reservation, CAS, capacity gating as backpressure), egress-only executors that run jobs behind a firewall, model-per-tenant isolation, and an ops console that ships in the box.

The Use-Case Map: 14 Kinds in 6 Families

Here is the whole landscape on one canvas. Colour is honesty about fit: green = a shipped net already does it; blue = maps cleanly with little new build; amber = maps, but needs some building.

The detail, family by family. Each line is one kind, with a concrete example and what it leans on.

1 · Judgment at a gate (human-in-the-loop)

• Approval / review backends. Inbound request → AI drafts → the token simply waits in a gated place → a human releases it → downstream action fires. Loan and credit approval, expense and refund sign-off, content moderation, KYC/onboarding review, contract and hiring pipelines. The waiting token is the durable work queue; the monitor is the reviewer’s console.
• Compliance / audit / governed-AI backends. Here the event log is the product: every decision is an immutable, replayable, explainable token trail. Regulated finance and healthcare decisioning, AI-decision logging, model-output governance. Role flags (rwxh) decide who can do what; the read-only scope lets auditors watch without touching.

2 · Messy input → structured action

• Document & unstructured-data processing. Ingest → extract/classify (AI) → validate (map) → route (pass) → store. Invoices, insurance claims, contracts, resumes, forms, scanned PDFs, inbound email. As formats stabilise, the AI extraction step crystallises into a deterministic parser.
• Triage, classification & routing. An inbound stream gets categorised and dispatched. Support tickets, bug reports, sales leads, alert routing, content tagging. Already proven by the safe-teams PM intake and the obsidian-brain cortex router.
• Data enrichment & ETL-with-judgment. Pipelines where some steps need a model (entity resolution, dedup, categorisation) wired between deterministic transforms. CRM enrichment, lead scoring, data cleaning, catalogue normalisation.

3 · Autonomous execution (doing the work)

• Software delivery. Story → code change → test → deploy, where git push is the deploy. Feature work, code review, auto-fix, dependency bumps, mass migrations. This is safe-teams, agenticos-developer, and module-reviewer, the most battle-tested family we have.
• Distributed job / batch backends. Fan work out to polling executors, capacity-gated, with full lineage on every job. Bulk processing, scraping fleets, test farms, scheduled ETL.
• Integration / orchestration hubs. Webhook in → transform → fan out to many SaaS APIs, and because executors are egress-only, the work runs behind your firewall. The n8n/Zapier seat, but AI-native.
• Scheduled / background operations. Cron- and interval-driven nets that do recurring work with no external trigger. Daily reports, reconciliation, digests, periodic scans, maintenance sweeps.

4 · Knowing & deciding (intelligence)

• Self-improving knowledge / research / RAG. Crawl/ingest → synthesise → link into a knowledge graph → answer queries, and it gets smarter over time. Market and competitive intel, internal knowledge bases, second brains. Proven by intel-gather and obsidian-brain; the query API is the read-only Domain Expert.
• Monitoring & autonomous ops (AIOps). Ingest signals → detect → diagnose (AI) → remediate (command) → escalate to a human. Log analysis, incident response, anomaly detection, self-healing infra. Proven by log-analyzer, whose investigation loop resolves repeat errors faster as it learns.
• Multi-agent reasoning with durable shared state. Specialised agents coordinate through shared places (durable shared memory) with concurrency control, human pause points, and observability that ephemeral frameworks (LangGraph, CrewAI) don’t have. Expert panels, simulations, negotiation. Proven by expert-team and safe-teams.

5 · Producing  ·  6 · Long-lived coordination

• Content generation & publishing pipelines. Generate (agent) → review (human or AI gate) → format (map) → publish to channels (http). Blog and social, newsletters, marketing, docs generation, localisation. Proven by obsidian-brain, and in fact by the pipeline that drafts these very articles.
• Saga / long-running business transactions. Multi-step processes that run for minutes, days, or weeks, with compensation paths; places hold the saga state durably across restarts. Order fulfilment, provisioning, subscription lifecycle, multi-party workflows.

The Trick No Ordinary Backend Has: Crystallization

Most backends cost the same on run one and run ten-thousand. A net doesn’t have to. Because deterministic and AI steps live on the same substrate, you can let a model handle the novel, ambiguous work first; then, once a pattern repeats reliably, replace that step with a deterministic map or http transition that does the same thing with no model call. The expensive thinking happens only while there’s genuine ambiguity to resolve. The cost curve bends down.

You Build It, and Rebuild It, with Claude Code

Look again at every row in that map. None of those nets is hand-assembled JSON. Whatever the domain, the workflow is the same: you describe what you want in plain language, and an AI builder turns it into a complete plan and then the actual net. A net-designer agent (or Claude Code itself) lays out the model, the places, the transitions, the arcs, and the inscriptions, wires them together, and deploys. The same kind of coding agent that drafts these articles builds the backends that run them.

And building is never one-shot. Because every transition fire emits a structured event, and the whole token store is queryable with ArcQL, the running system can be read straight back. Claude Code tails the event-line, asks where tokens pile up or stall, and then improves the net in place: add a validation stage, split a transition, insert a human gate, drop in an entire new sub-net, retune a model tier, or crystallize an AI step into a deterministic one. The observability that makes the monitor useful to a human is exactly what makes the net improvable by an agent.

So the backend is not a thing you build once and freeze. You describe the change, the agent plans it, applies it against the live model, and watches the events to confirm it landed. That loop is how the safe-teams net you can watch right now grew to 37 transitions and six figures of versions in the first place. The domain does not matter: the same loop builds and tunes an approval backend, a claims pipeline, or a research net.

The Honest Edges

A backend pitch that only lists strengths is a sales deck. Here is where Agentic-Nets is weak today, and the specific thing that would fix each:

One more bit of candour: the data engine, orchestrator, and visual editor are proprietary (you run them from Docker Hub), while the gateway, executor, vault, CLI, chat, and blobstore are open (BSL). So the credible play is “build on it via the API”, not “fork the engine.” That’s exactly why a typed SDK is the highest-leverage thing on the list above.

Where It Sits

Put it on the map. On one side, workflow engines (Temporal, Step Functions, n8n, Camunda) give you durability and orchestration but treat AI as just another task you bolt on. On the other, agent frameworks (LangGraph, CrewAI, AutoGen) give you fluent multi-step AI but lose the plot on durability, concurrency, audit, and human gates. Agentic-Nets is strongest precisely in the seam: where a workflow is durable and long-lived, needs judgment at one or more steps, benefits from a built-in audit trail and ops console, and repeats often enough that crystallization pays off. That seam is not crowded.

See a Backend Running, Read-Only

You don’t have to take any of this on faith. One of these use-cases, an autonomous software-delivery team (Family 3), is running live, and you can watch it through a read-only window that can read everything and change nothing.

• Open agentic-nets.com/monitor, tick “Read-only access”, and paste the key:
  07a9af1d663f899f79f08ca56050a977d41472e34cc0dd0f74abe046446f78f9
• Watch the Console narrate transitions firing in plain English, then open Agents and ask the Domain Expert “what am I seeing?”

Prefer the terminal? The same read-only key is just a backend credential. Mint a token, read the live feed, and watch a write bounce off the gateway:

SECRET=07a9af1d663f899f79f08ca56050a977d41472e34cc0dd0f74abe046446f78f9

TOK=$(curl -s -X POST https://agentic-nets.com/oauth2/token \
  -d "grant_type=client_credentials&client_id=agenticos-readonly&client_secret=$SECRET" \
  | python3 -c "import sys,json;print(json.load(sys.stdin)['access_token'])")

# READ the live token feed  -> 200
curl -s -o /dev/null -w "read  %{http_code}\n" -H "Authorization: Bearer $TOK" \
  "https://agentic-nets.com/api/event-line/safe-teams?limit=5"

# WRITE into the net        -> 403 readonly_scope
curl -s -o /dev/null -w "write %{http_code}\n" -H "Authorization: Bearer $TOK" \
  -X POST "https://agentic-nets.com/api/runtime/places/p-pm-inbox/tokens?modelId=safe-teams" \
  -H "Content-Type: application/json" -d '{"name":"x","data":{"text":"x"}}'

That’s the backend talking. Now look back at the map and pick the row that matches something you actually have to ship: an approval flow, a claims pipeline, a triage queue, a nightly job. The question was never “can an agent do a trick.” It’s “what can I run on it”, and the answer is: most of the work items moving through stages that your business already runs on something less observable.

Every “proven” tag in the map points at a net running in the AgenticNetOS deployment today; every “honest edge” is a real gap in the current API, not a hypothetical. The read/200, write/403 transcript above was run against the public host while writing this.

Related reading: the read-only monitor walkthrough for how that live window is built and secured, and “From One Sentence to Live Deploy in 2:44” for the software-delivery row of the map doing its thing end-to-end.