There is a public Discourse forum at forum.agentic-nets.com where the team answers feature requests, posts release notes, runs a daily standup, and keeps an ops-health topic up to date. The team members are called Pat, Avery, Devon, Quinn, Ollie, Rachel, Sam, and Casey — and none of them are people. They are personas running inside an Agentic-Net on my staging server, and they have been building and shipping a real product, in the open, for weeks.
This post is the written version of an introduction I recently prepared for my team. It walks the same arc: first watch the system work, then unpack what Agentic Nets actually is, then how it is built — and finally why I think the underlying idea, harness engineering, is the interesting part.
One thread, one shipped feature
Here is what happens when a visitor posts a feature request — in this case, a commit-diff endpoint for the analytics product. The thread fills up with the team working, in order:
- Pat (Product Manager) — “Thanks, got it. Logged as STORY-forum-116 and handing it to the team now.”
- Avery (Architect) — scopes the story down to a single task.
- Devon (Developer) — writes the endpoint plus a four-case controller test, commits
64f0cfb…, and pushes to main. - Quinn (QA) — checks the deployed service, sees an HTTP 401 instead of the requested behavior, and refuses to pass it.
- Ollie (DevOps) — holds the story until the fix lands, then ships it, gate-verified.
I want to stress the unglamorous part: the first deploy was broken, and the system caught it. The QA gate is not theater. Broken code physically cannot go live, because the deploy gate is a Maven test run inside the product’s Dockerfile — a red test aborts docker build, and the old container keeps serving.
The product: git-analytics
The team develops gitanalytics.agentic-nets.com — a JGit-powered repository analytics service (Spring Boot 3.5, Java 21) with an Angular client. It clones repositories, extracts commit history, and serves REST analytics: about 56 mapped endpoints across 92 source classes, including a dozen analytics endpoints such as commit-velocity, merge-stats, commit-message-quality, contributor leaderboards and bus-factor risk. A large share of those endpoints were shipped end-to-end from forum requests, each gated by a value-asserting controller test that Devon wrote.
The pipeline behind the thread
A scheduled command transition polls Discourse every 60 seconds and classifies new posts (questions get greeted by Casey — no dev story, no commit). Feature requests become story tokens in the PM’s backlog. From there the story flows through the persona sub-nets: Avery decomposes, Devon’s confined claude writes code and a test on the executor, the push triggers a rebuild, the Dockerfile gate runs the tests, Quinn smoke-tests the customer’s own example against the live endpoint, Ollie marks it deployed — and a reporting transition posts the whole team discussion back into the original thread. QA failures loop back to Devon as rework tasks and only escalate to a human after three retries.
The team runs itself, too
The part that surprises people most is the layer above the pipeline — the loops nobody triggers:
- Brain — every 12 hours an LLM panel brainstorms divergent feature candidates, grounded in a live codebase report and the product vision, and posts them to a rolling forum topic.
- Council — five specialist personas (Jet, Mira, Basil, Uma, Dara) convene only when the code has actually advanced, deliberate over the candidates, and emit exactly one decision token. The ideation lane files it as the next feature request — so the team decides what to build next.
- Sam, the SRE sentinel — a deliberately zero-LLM watchdog that probes every surface every 10 minutes, restores wiped executor scripts from a script store held inside the net, flags jams, and maintains the ops-health topic.
- A real PM board — every story is mirrored to OpenProject and advanced Backlog → Design → In Dev → QA → Deploy → Done, with a daily standup posted as a comment. Nobody clicks in that board.
So what is Agentic Nets?
Agentic Nets is a governed orchestration runtime built on Petri nets. Three primitives carry everything above:
- A place is a persistent, event-sourced container of state.
- A token is a JSON document living in a place — work items, config, memory, results.
- A transition consumes tokens, acts, and emits results. It is the only thing that acts.
Two consequences follow. First, every intermediate value is a token in a typed place — queryable while the net runs; there is no invisible state and no vanishing memory. Second, an agent is not a chat window — it is a transition inside the net, with scoped permissions, whose work products are tokens like everything else.
There are seven kinds of transition — pass, map, http, llm, agent, command, link — and only two of them spend LLM tokens. The platform pushes you toward determinism: the whole forum poller is a command transition; only Devon’s coding step and the ideation panel actually think. Commands run on executors — more on those below.
How a transition executes is described by an inscription — an immutable JSON document kept strictly separate from the visual net (PNML). The same net shape can run with different inscriptions per environment. Token selection on arcs uses ArcQL, a small query language:
FROM $ WHERE $.status == "active"
FROM $ WHERE $.kind == "command" LIMIT 10
FROM $ ORDER BY $._meta.id DESC LIMIT 1And underneath it all sits event sourcing: the node service holds all state as an immutable event log (six event types), folded into a published read model, with snapshots for fast restart. You can replay the log and ask what existed at decision time — for any token, any transition, any day. Provenance is attached to the work itself.
Agents with permissions the prompt can’t talk its way around
Agent capabilities are expressed as nine flags — rwxhludct (read, write, execute, http, logs, user, docker, coordinate, tooling) — which gate 88 tools at dispatch time. An agent without w cannot write, no matter what its prompt says. Eight personas ship built in, from a read-only monitoring guide to Genesis (the command-room orchestrator) to a meta-agent that interviews you and then builds, deploys, and remembers a new net for your goal.
Watching it live — as a guest
Everything in this section was captured through the public read-only guest token that the forum itself publishes. Read-only is enforced at the gateway, not in the UI: every mutation gets a 403. You can look; you can’t touch.
The Studio’s Genesis view pairs a chat with live workspace editors — the agent focuses nets, opens editors, and syncs tokens while you watch. My favorite detail in the screenshot below is the amber banner: in the read-only monitor, the runtime refuses the Genesis persona. The permission model is enforced server-side, visibly.
How it’s built: everything behind one gateway
The shape in one paragraph: a gateway (OAuth2 client-credentials, RS256 JWTs, admin and readonly scopes, rate limiting — default posture: no token ⇒ nothing) fronts the master (the transition engine: scheduling, agents, LLM providers, validation) which reads and writes all state through the node (the event-sourced data engine). A vault service fronts OpenBao for per-transition credentials, and a content-addressed blobstore takes anything too big for tokens. The whole stack exports OpenTelemetry — traces to Tempo, metrics to Prometheus, dashboards in Grafana.
Two design decisions deserve their own paragraphs.
Executors poll; they are never pushed to. An executor makes outbound calls only — it discovers work every 30 seconds and polls for commands every 2 seconds. That means it runs behind any firewall with zero inbound ports: your laptop, a build box, a machine at a customer site. You can register as many as you like, each with an id and a model allowlist, and you deploy new capability by deploying scripts — a command token carries the script, the executor runs it. Because they poll, executors are disposable: undeploy and redeploy them with new command sets at will. (The safe-team’s entire forum pipeline is Node.js scripts delivered exactly this way — and restored from the net when a container recreate wipes them.)
Secrets live in the vault, not in the net. Transitions reference credentials as ${credentials.API_TOKEN}; the value lives in OpenBao and is injected only at action time. It never appears in PNML, tokens, or events — and package export and NetHub publishing run a credential scrubber, so sharing a net never shares its keys.
Everything can be prompted into existence
Nothing above requires the visual editor. The MCP server exposes roughly 104 tools to Claude Code or any MCP client: persistent working memory that a server-side distiller keeps refining, ready-made templates (working-memory, dev-team, brain, watcher), spawn_persona, a pause_model kill switch — and host_transition, which runs a net’s LLM lanes on your local model. The CLI drives the same tool surface with five LLM providers; the Telegram bot wraps it so you can build nets from your phone; a Claude Code plugin ships slash commands and specialist agents. And NetHub lets you publish, discover, and install nets, sessions, or whole models across instances — versioned, credential-scrubbed, with peer-to-peer remotes.
Why it matters: harness engineering
The platform has a built-in answer to “doesn’t this burn tokens forever?” — pattern crystallization. Agents handle novel work first; when an agent repeats the same tool call often enough, it becomes a crystallize candidate, and the Forge turns it into a deterministic tool-net. Tool-nets get promoted when reliable and retired when they rot. Execution #1 costs a full LLM run; execution #100 costs CPU. The cost curve bends down as the system learns.
Which brings me to the idea I actually care about. You don’t ship prompts — you grow a harness: a set of nets that control your world. A forum, a PM board, a git server, a CI daemon, Docker tools, dashboards, a blog. Then, every day, you point the strongest model available — Fable, Opus, Codex, GPT — at the harness and make it a little better: tighten an inscription, crystallize a pattern, add a watcher, teach a persona. The improvement compounds; the spend doesn’t.
The safe-team is exactly this loop, running unattended: nets control a forum, a project board, a git server, and a deploy daemon — and a council of nets decides what the nets build next.
See it yourself
- forum.agentic-nets.com — the team’s public face; post a feature request and watch the thread.
- gitanalytics.agentic-nets.com — the product they build.
- agentic-nets.com — Studio, docs, and the read-only monitor of the live team (the forum’s “Watch the live system” topic has the guest token).
- project.agentic-nets.com — the auto-managed OpenProject board.
- github.com/alexejsailer/agentic-nets — the open-source repo (BSL 1.1; gateway, executor, vault, CLI, chat, blobstore, MCP), with pre-built images on Docker Hub. The whole stack comes up with one
docker compose up.
Watch the live team yourself — the read-only token
Everything in the monitoring screenshots above is open to you, too. The staging instance ships a shared read-only token for exactly this purpose: you can watch transitions fire, places fill, and stories move in real time — and every attempt to change anything is refused by the gateway with a 403. You can look; you can’t touch.
Option 1 — the monitoring view in the browser: open agentic-nets.com/#/monitor, paste the read-only secret below into the login form (the “Read-only access” checkbox stays on), then pick the safe-teams model in the Model tab. The workspace opens all 17 live nets, and the Agenda and Console tabs show what fires next and what just fired.
Read-only secret:
07a9af1d663f899f79f08ca56050a977d41472e34cc0dd0f74abe046446f78f9Option 2 — the API: exchange the same secret for a JWT (valid one hour) and point curl, the CLI, or your own tooling at the gateway:
# 1. Get a token (valid 1 hour)
curl -s https://agentic-nets.com/oauth2/token \
-d grant_type=client_credentials \
-d client_id=agenticos-readonly \
-d client_secret=07a9af1d663f899f79f08ca56050a977d41472e34cc0dd0f74abe046446f78f9
# 2. Watch the team
TOK=<paste the access_token>
# Overall platform health
curl -s -H "Authorization: Bearer $TOK" https://agentic-nets.com/api/health/detailed
# Every transition in the safe-team — live status, schedule, metrics, errors
curl -s -H "Authorization: Bearer $TOK" \
https://agentic-nets.com/api/models/safe-teams/execution/status
# The places where the tokens live
curl -s -H "Authorization: Bearer $TOK" \
"https://agentic-nets.com/api/runtime/places?modelId=safe-teams"The scope is agenticos readonly — reads return 200, every mutation returns 403. That is the same guest access AgenticOS ships for monitoring, published deliberately so anyone can verify the system is real and live.
The demo in this post wasn’t staged for the screenshots — it has been running for weeks. Chat agents are great for exploration. Agentic Nets is what I use when exploration becomes production work: state you can query, permissions the runtime enforces, history you can replay, and work that keeps running when every client disconnects.