In my last post I introduced Agentic-Nets through the live demo: a public forum operated by software agents that designs, builds, tests and ships a real product. This post is about the idea underneath that demo — the one I think matters most. Models come and go; every few months a stronger one appears. What compounds is everything around the model: the workflows, roles, gates, memories, tools and watchdogs that turn raw intelligence into dependable work. Practitioners call this the harness. My claim: the harness is the durable asset — and it deserves its own operating system.
Agentic-Nets is that operating system, and it plays a double role that no agent framework I know of plays: it is the fabric the harness is made of, and simultaneously the control room the harness is observed, measured, adapted and extended from. I’ve started calling this a harness control system, and it changes what “automation” means for a domain.
One runtime, every layer
The claim that sounds most like marketing is actually the most technical one: from seven transition verbs — pass, map, http, command, link, llm, agent — on a Petri-net substrate, you really can build everything a domain automation needs. Not metaphorically: structurally.
- Workflows are deterministic rails — routing, transforms, API calls, commands. The process itself, readable as a graph.
- Tool-nets are recurring fragments promoted into named, versioned, schema-described capabilities — the reusable verbs of your domain, with a lifecycle (
draft → blessed). - Personas are roles as nets. A persona is a region of the graph, not a paragraph in a prompt: an inbox, a decision graph, scoped permissions, an explicit error path. You can open “Devon the developer” in the Studio and read him like a sentence.
- Teams are personas wired through shared places, with gates that have physics: the QA gate in the live system is a Maven test run inside the Dockerfile — a red test aborts the build, so broken code cannot ship. The org chart is the net.
- Memory and brains are knowledge as structure with logic: link transitions weave places into a navigable graph, and scheduled distillers refine raw capture into durable notes while nobody is connected. Memory here doesn’t just persist — it runs.
- Watchers and sentinels are the immune system: zero-LLM probes on a schedule, jam detection, self-healing. The live system’s SRE sentinel restores its own wiped scripts from tokens stored inside the net.
Because every layer is only nets, every layer inherits the same durability, the same observability, and the same permission model (rwxhludct capability flags, enforced by the runtime at tool dispatch — not requested politely in a prompt).
The harness control loop
Here is the core of the thesis. A harness that runs is table stakes. A harness you can observe, interrogate and rewrite while it runs — from inside the same runtime — is a different kind of asset.
Observe: the live monitor, the console stream, the agenda that shows what fires next. Analyze: this is where event sourcing earns its keep. Nothing in the node is ever overwritten; the system’s whole history is a queryable corpus. You can travel back in time and ask which transition consumed this token, and what did the world look like at that moment? Where do tokens pool? Which agent step fails most, on which input shape, at what cost? As I wrote in an earlier essay: the event log is the system’s memory of itself, and you’ve already paid for it. Improve: the levers are the Genesis command room in the Studio (chat on the left, live editors on the right) and the MCP server’s ~104 tools from any capable client — tighten an ArcQL filter, add a validator transition, split an overloaded persona, extend the net. Measure: the usage ledger and net statistics tell you whether the change helped — with numbers, not vibes.
The economics of this loop are the point:
Run the domain on cheap, deterministic lanes. Spend the frontier model on the harness itself. Execution cost stays flat while capability compounds.
Day-to-day work flows through deterministic transitions and small models. The expensive model — Fable, Opus, Codex, whatever is strongest this quarter — is pointed at the harness, not at the workload: a daily gardening session that reads the trails, fixes friction, and crystallizes the step that has stopped needing intelligence. Crystallization is the formal version of that last move: the runtime tracks repeated agent tool-calls, flags candidates, and the Forge turns them into deterministic tool-nets. Execution #1 costs a full LLM run; execution #100 costs CPU. Teach once, formalize, automate forever.
The system that builds itself
Agent transitions carry net-building tools: CREATE_NET, CREATE_PLACE, CREATE_TRANSITION, SET_INSCRIPTION, DEPLOY_TRANSITION. Read that list again — a net can contain an agent whose job is to build more net. Add scheduled ideation, a deciding council, and native self-measurement, and the harness stops being something you extend. It becomes something that grows.
Every station in that diagram is running on my staging instance today. A scheduled agent maps the product’s own architecture into a live net (sense). A brain net brainstorms feature candidates every twelve hours, grounded in the live codebase report, and a five-specialist council convenes — only when the code actually advanced — to emit exactly one decision token (decide). The persona team builds the decided feature through enforced QA and deploy gates (act). The Persona meta-agent constructs new nets from a conversation, the Forge scaffolds tool-nets from an intent, and the sentinel restores its own scripts when a container wipe deletes them (build). And everything lands in the ledger and the event line, which the next cycle reads (measure) — the system can measure itself because it lives inside the runtime it is measuring.
The fence is what makes this responsible rather than reckless: capacity gates, retry budgets with human escalation, capability flags, vault-scoped secrets, inscription validation before anything deploys, and a pause_model kill switch that stops every transition in a model with one call. Autonomy needs an off switch, and this one writes an audit token when you use it.
Multiplying the harness
A harness that works once is a success. A harness you can copy is a business. Executors — the hands — poll egress-only, so they run behind any firewall with zero open ports: your laptop, a build box, a machine at a customer site, a box next to the hardware it controls. Capability arrives as data (a command token carries the script), so hands are disposable and re-provisionable. And NetHub packages a net, a session, or a whole model — credentials always scrubbed — as a versioned artifact that installs into a fresh running model on another instance, with peer-to-peer catalog federation between instances. Build the domain harness once, prove it against the live event trail, then install it per team, per customer, per site — and let each copy start its own control loop.
Who profits — beyond developers
Developers get a runtime. But the visual, promptable, governed nature of the system makes it legible to people who never open an IDE — and several of them get more out of it than developers do:
- Process owners and ops managers see a live diagram of their process — readable like a BPMN chart, but running. This is RPA’s successor: automation with judgment at the branches and gates you can point at.
- Engineering leaders get governed, measurable AI adoption — an answer to “what did the agents do, what did it cost, and who allowed it?” That question, not demo speed, is what decides enterprise adoption at 3am.
- Domain experts operationalize their expertise by conversation: the Persona agent interviews them and builds the net; the expert owns the knowledge places.
- Consultants and integrators get a new deliverable: the domain harness as a versioned product on NetHub, plus recurring harness-gardening engagements.
- Regulated operations get agent automation that can face an auditor: replayable decisions, scoped capabilities, secrets that never touch a prompt.
- Solo founders get the existence proof: everything described in this post — the forum, the board, the product, the releases — is operated by one person, multiplied by a persistent team of nets.
Where to start
You don’t adopt this all at once; you climb a ladder. L1: put one weekly process on deterministic rails — five places, four transitions. L2: add an llm transition at the single point where judgment lives. L3: split the work across two or three personas with a real gate between them. L4: add a watcher and a memory distiller so the thing maintains itself. L5: give it a brain and let it propose its own next extension — inside the fence.
And at every level, the control loop is the same: open the event trail after the first week and let the history tell you what to improve. That is harness engineering. It compounds from day one — and the runtime that makes it possible is running, in public, right now at agentic-nets.com, forum.agentic-nets.com and github.com/alexejsailer/agentic-nets.