The Harness Control System

1 · Executive summary

The harness is the asset. The runtime is its control system.

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 watchers that turn raw intelligence into dependable work. Practitioners call this the harness. Agentic-Nets is built on a simple claim: the harness deserves its own operating system.

• One medium for everything. Seven transition types on a Petri-net substrate express workflows, single agents, personas, whole teams, structured memories, and watchdogs — in the same runtime, under the same observability, governed by the same permission model.
• The runtime is also the control room. Because every action is an event-sourced token movement, the system's own history is queryable data. You can travel back in time, see exactly what happened and why, and use that to improve what happens next.
• Strong models are gardeners, not engines. Day-to-day execution runs on deterministic lanes and cheap models. The expensive frontier model (Fable, Opus, Codex) is pointed at the harness itself — via MCP or the Genesis command room — to analyze, extend and repair it. Improvement compounds; spend does not.
• The system can extend itself. Agent transitions hold net-building tools: a net can decide, design and deploy new nets, then measure them — because it lives inside the runtime it is measuring. Autonomy runs inside a fence of capacity gates, permission flags, retries and a kill switch.
• Harnesses multiply. Egress-only executors put hands anywhere; NetHub packages whole models — scrubbed of secrets — so a proven domain harness can be installed per team, per customer, per site.
• This is running today. A public, autonomous software team has been operating a forum, a project board and a real product for weeks — the standing proof behind every claim in this paper.

2 · The problem

Automation that cannot see itself

Every organization automates. Almost none of that automation can explain itself, and none of it improves itself.

Classic automation is blind. Scripts, cron jobs, RPA bots and CI pipelines execute fixed instructions. They know nothing of their own history; when the world drifts, they break silently or fail loudly, and a human reverse-engineers what happened from scattered logs. Change requires a developer, a deployment, a ticket.

Chat agents are the opposite failure. They are marvelously flexible and completely ungoverned: state lives in a scrolling context window, permissions live in a prompt (where a clever input can talk them away), memory evaporates between sessions, and nothing is measurable after the fact. You would not run payroll on one. The essays behind this system have drawn the dividing line the same way for eighteen months: chat agents are great for exploration; Agentic-Nets are what you use when exploration turns into operations.

The gap between them is a missing layer — a runtime where automation is explicit (you can read the process as a graph), durable (state survives every disconnect), governed (permissions enforced by the runtime, not requested by the prompt), and above all self-describing: the system records enough about its own behavior that it can be analyzed and improved as a matter of routine.

That layer is what Agentic-Nets provides — and the practice it enables deserves a name: harness engineering. The harness is the totality of nets that run your domain. The runtime is its control system: the place where the harness is observed, measured, adapted and extended. This paper is about that loop.

3 · The medium

Petri nets with seven verbs

Underneath everything sit three primitives from a sixty-year-old formalism — chosen precisely because they make state, concurrency and gating visible.

A place is a persistent, event-sourced container. A token is a JSON document living in a place — a work item, a config, a memory, a result. A transition consumes tokens, acts, and emits results; it is the only thing in the universe that acts. Arcs carry a small query language (ArcQL) that decides which tokens bind; emit rules decide where results land; capacities gate flow.

On this substrate, Agentic-Nets defines exactly seven kinds of transition — seven verbs:

Two properties matter more than any feature list. First, five of the seven verbs never call a model — the formalism pushes you toward determinism, and AI appears only where judgment genuinely earns its cost. Second, the verbs compose without limit: everything described in the rest of this paper — teams, brains, memories, watchdogs, self-building systems — is nothing but these seven verbs arranged on the same substrate. There is no second system to learn.

4 · The stack

One runtime, every layer

The claim that sounds most like marketing is the most technical one: from seven verbs you really can build everything — workflows, tools, agents, personas, teams, memories, brains, and the watchdogs that guard them all. Each layer is nothing but nets, so each layer inherits the same durability, the same observability, and the same governance.

Three of these layers deserve a closer look, because they are where Agentic-Nets departs hardest from agent frameworks.

Personas are nets you can read

In a chat framework, a "role" is a system prompt. Here, a persona is a structure: Devon the developer is an inbox place, a planning transition, a command transition that runs a confined coding agent on an executor, a result-router, and an explicit error path back to the product manager. You can open Devon in the Studio and read him like a sentence. When Devon misbehaves, you don't re-prompt and hope — you look at which transition failed, with which token, and fix that step.

Memory is structure with behavior

Most agent memory is a vector store: a bag of embeddings that answers "what looks similar?" A memory net answers better questions. Knowledge lives as tokens in typed places; link transitions weave places into a navigable graph; scheduled distiller transitions refine raw capture into durable notes while nobody is connected; and because memory is event-sourced like everything else, "why does my memory say X?" has an answer — the event trail that wrote it. Memory here doesn't just persist. It runs.

Teams have physics

Wire personas through shared places and you get an organization whose rules are mechanical, not aspirational. The QA gate in the live system is not a convention — a red controller test aborts the Docker build itself, so broken code cannot ship. Work-in-progress limits are place capacities. Escalation is a place a token lands in after three failed rework loops. The org chart is the net.

5 · The core thesis

The harness control loop

Here is the idea this whole paper exists for. 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. Agentic-Nets is deliberately both: the fabric the harness is made of, and the control room it is improved from.

Time travel is the analysis superpower

The node service stores all state as an immutable event log folded into a read model. Nothing is overwritten, ever. That turns debugging and improvement from archaeology into queries: Which transition consumed this token, and what did the world look like at that moment? Where do tokens pool on Tuesdays? Which agent step fails most, on which input shape, at what cost? The event trail answers with data, not recollection — or, as one of the platform essays puts it: "the event log is the system's memory of itself, and you've already paid for it." You analyze the past precisely to change the future: tighten an ArcQL filter here, add a validator transition there, split a persona that is doing two jobs, crystallize the step that has stopped needing intelligence.

The levers: Genesis and MCP

Improvement needs hands, and there are two pairs. In the Studio, the Genesis command room pairs a coordinator agent with live workspace editors — you say what should change; it focuses nets, edits inscriptions, builds structures, and you watch the canvas move. From the outside, the MCP server exposes roughly 104 tools to any capable model — Claude Code, an IDE agent, a scheduled cloud job — including net building, memory, diagnosis (event_trail, net_stats, diagnose_transition), templates, and a pause_model kill switch. The pattern that emerges is the economically interesting one:

The loop runs at every timescale

6 · The economics

Crystallization: intelligence hardens into infrastructure

Most agent systems have a cost problem: every execution reasons from scratch, so operating cost scales with usage forever. The harness inverts this with a formal pipeline the repo calls crystallization.

Agents explore first — that is what they are for. The runtime keeps a usage ledger of every tool call an agent makes. When the same call pattern recurs, it becomes a crystallize candidate; the Forge — a tool-building meta-agent — turns it into a deterministic tool-net with a manifest, a schema, and a lifecycle (draft → blessed). Reliable tool-nets get promoted; rotting ones get flagged and retired. The public docs put it plainly: "Teams start with agent transitions to explore a problem, then harvest the working recipe into deterministic transitions. The net's AI spend shrinks as the net matures."

This is the deep answer to "won't this burn tokens forever?" — and it is also why the harness, not the model, is the durable asset. Swap the model next quarter; the crystallized library, the memory nets, the gates and the watchers all remain. Fourteen years of your domain's operational knowledge cannot be re-prompted; it can be accumulated.

7 · The frontier

The system that builds itself

Agent transitions carry write-capability 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. Combine it with scheduled ideation, a deciding council, and native self-measurement, and the harness stops being something you extend — it becomes something that grows.

This is not a roadmap slide — every station in Figure 7 is running on the public staging instance today:

• Sense: a scheduled agent maps the product's own architecture into a live net; a zero-LLM sentinel probes every surface every ten minutes.
• Decide: a brain net brainstorms candidates every 12 hours, grounded in the live codebase report; a five-specialist council convenes only when the code actually advanced and emits exactly one decision token.
• Act: the persona team builds the decided feature through enforced QA and deploy gates.
• Build: the Persona meta-agent constructs new nets from a conversation; the Forge scaffolds tool-nets from an intent; the sentinel restores its own scripts from tokens in p-script-store when a container wipe deletes them — the net rebuilding its own hands.
• Measure: every step lands in the ledger and the event line, which the next brain cycle reads.

The foundations document closes the thought with the best sentence in the repository:

8 · Scale

Multiplying the harness

A harness that works once is a success. A harness you can copy is a business. Three mechanisms make the architecture multiply.

Hands, anywhere

Executors — the hands of the system — make outbound calls only. They poll for work every two seconds and never accept an inbound connection, so they run behind any firewall with zero open ports: a laptop, a build server, a machine inside a customer's network, a box next to the hardware it controls. Register as many as you like, each with an identity and a model allowlist; the master routes command work to the right hands. Capability arrives as data — a command token carries the script; the executor runs it — so executors are disposable and re-provisionable. If a partition cuts the link, work queues and the executor simply resumes polling; nothing is lost, because nothing was pushed.

One brain, many masters

The gateway keeps a registry of masters, each declaring which models it serves; new models are assigned round-robin to wildcard masters, and stale ones are evicted by heartbeat. State lives in the event-sourced node, so masters are restartable and horizontally boring — the way infrastructure should be.

The harness as a shippable artifact

NetHub packages a net, a session, or a whole model — the complete harness with its structure, inscriptions and (by policy) its config tokens — as a versioned artifact. Credentials are always scrubbed; a token policy (none | config | all) decides how much runtime state travels; installing a model artifact spins up a new running model with hosts rewritten. Peer instances can federate catalogs (hub_add_remote), opt-in and read-only by default. The consequence is a new kind of deliverable:

9 · Application

Use cases: harnesses by domain

The pattern is always the same — processes become nets, actors become personas, tools become tool-nets, knowledge becomes memory nets, and the control loop improves all of it. What changes per domain is only the topology. A useful way to gauge where you stand is the maturity ladder:

Two more deserve a sentence each. Edge and multi-site operations: because executors poll, a fleet of sites can each run local hands under one governed brain — same net definition, many environments. And the meta-use-case: the harness that improves your other harnesses, which is just the control loop of Section 5 given its own net.

10 · Who profits

Beyond developers

Developers get a runtime. But the visual, promptable, governed nature of the system makes it legible to people who would never open an IDE — and several of them get more out of it than developers do.

11 · Proof

Live evidence

Every claim above has a running counterpart. The public staging instance has operated a forum, a project board, a git server and a real product for weeks — autonomously.

12 · Outlook

Where this goes

Near: closing the authoring loop

The in-Studio assistants (inscription chat, token workbench) are being upgraded from one-shot generators to grounded agents that see real net topology and real token samples, validate their output against the runtime, and self-correct before handing you a result. Every friction point in authoring is a candidate for the same treatment: the harness improving the tools that improve the harness.

Near: richer hands

Executors today speak bash and filesystem. The direction is executor fleets with hot-deployable capability — OSGi/Karaf and Spring Boot executors receiving new command bundles over the same polling channel, plus MCP-speaking handlers. Because executors are disposable, upgrading the hands never risks the brain.

Mid: the self-optimizing default

The event log already contains everything needed for automatic improvement proposals: an organizer net that clusters agent journals, flags transitions where one branch dominates, shadow-runs a deterministic candidate against the corpus, and files a crystallization proposal for human approval. A/B experiments as sibling transitions scored against real history; promotion by evidence. The pieces — usage ledger, crystallize API, variant comparison — exist; the outlook is wiring them into a loop that runs unattended.

Mid: the harness marketplace

NetHub today shares artifacts between peers. The natural next step is a catalog of domain harnesses — a support desk, a research brain, an SRE sentinel pack — installable, versioned, credential-clean, each arriving with its own control-loop instrumentation. Skills marketplaces share prompts; this shares running organizations.

Far: harnesses of harnesses

Nothing in the substrate limits the control loop to one model. A supervisory net can watch the ledgers and event lines of many models — many domains — and route a gardener's attention to whichever harness drifts most. Federation across instances makes that loop cross organizational boundaries. The endpoint of the thesis: operations as a fabric of self-measuring processes, each one gate away from a human, all legible in one formalism.

13 · Candor

Honest limits

• There is a learning curve. Places, tokens, inscriptions and ArcQL are a real vocabulary. The promptable surfaces (Genesis, Persona, Builder) flatten it, but thinking in nets is a skill you acquire.
• It is a young system with a small community. One author, powerful conviction, real running proof — but not yet an ecosystem. Frameworks with hundred-thousand-star communities ship more integrations, faster.
• The core is not fully open. The gateway, executor, vault, CLI, chat, blobstore and MCP server are BSL 1.1; the node, master and GUI ship as proprietary images. That is a deliberate trade, and a real adoption consideration.
• Judgment steps still fail like LLMs fail. The mitigation is structural — validators after agents, gates before deploys, retries with escalation, catch-all emits so nothing is lost — but "structural mitigation" is engineering you must actually do.
• Async by design. The runtime is a polling fabric, not a synchronous API; sub-second request/response is not its habitat. Autonomy is an operational commitment: schedules act while you sleep, which is the point — and a responsibility.

14 · Lineage

Roots: fourteen years of Petri nets

Agentic-Nets is not a framework improvised onto the AI wave. It is the direct descendant of a 2012 diploma thesis at the Karlsruhe Institute of Technology — a Java simulation engine for XML-Netze, a higher-order Petri-net variant in which places hold structured documents and transitions are guarded by inscriptions.

The architectural map is nearly one-to-one across fourteen years: typed XML tokens became typed JSON tokens; the thesis's ANTLR-parsed inscription queries became ArcQL; sequential and parallel firing strategies became SINGLE and FOREACH modes; and — most tellingly — the thesis's risk model, which attached likelihoods, impacts and reduction measures to transitions at firing time, became today's governance: capability flags, capacity gates, retry budgets and vaulted credentials, all carried in the same inscription that routes the data. Risk-aware business processes then; risk-aware agents now. As the foundations document puts it, the thesis wanted to simulate not only the fair-weather flights of a process but what happens when things go wrong — "the same intent applies to AI agents; the things that go wrong are different in kind, not in shape."

The lineage matters for a practical reason: Petri nets carry sixty years of formal results — liveness, reachability, boundedness, soundness — that agent systems need and rarely articulate. These are not vibes; they are decision problems with formal answers, and they are reachable when the system is built on a net substrate rather than chained prompts. An agent that can run a shell command needs every guarantee a business process ever needed, plus a few more.

15 · Next step

See it yourself

Or start where the thesis starts: pick one process your team runs every week, draw it as five places and four transitions, put an agent at the single point where judgment lives — and then open the event trail after the first week and let the history tell you what to improve. That is the control loop. It compounds from day one.