Every picture in this article is a screenshot of a live Studio canvas, taken on 8 September 2026, with nothing hidden and nothing drawn by hand. The first example is Hermann, the twelve-factor developer from the last two articles, shown this time as the nets he is made of. The second is the web investigator. Four more follow. The idea is simple: instead of explaining a system and then showing a diagram of it, read the net itself, because on this runtime the net is the system.
How to read one of these pictures
A canvas in Agentic-Nets Studio shows a Petri net that is running. The vocabulary is small enough to learn from one screenshot:
- Orange circles are places. A place holds tokens, and a token is a JSON document with a history. Places are the state of the system, and they are the only state.
- Rounded boxes are transitions, which this article calls lanes. Each carries a kind tag: MAP is a deterministic template, COMMAND is a script that runs on an executor, AGENT is a bounded model call with tools and an answer contract, LLM is a single model call, LINK is a typed relation between two places.
- A green dot on a lane means it is deployed and running on the runtime right now. A yellow dot means the lane is gated by a schedule, a cron or an interval, and is waiting for its next slot.
- A blue number inside a place is the count of tokens in it, refreshed every three seconds from the runtime. A place without a number is empty at that moment.
- Arrows are arcs. A lane fires when every place on its incoming arcs has a matching token; it consumes what it reads unless the arc says otherwise, and it writes to the places on its outgoing arcs. That is the whole execution rule.
- The right sidebar lists the nets stored in the session and, below, the element explorer with the runtime id of every place and lane on the canvas.
Everything else in the pictures is ordinary Studio: the model and session in the header of the Editors panel, the auto-refresh button on the editor’s own header, the version in the top bar. All screenshots were taken at a 1920 pixel page width with the sidebar open and the editor at its normal size. Nothing was maximized, because the nets were laid out so they would not need it. That layout is the first trick, and it deserves its own section.
The trick that makes a big net readable: views
Places and transitions belong to the model. A net is a drawing of some of them inside a session. That distinction is what makes big nets readable, because one runtime element can appear in several drawings. The canonical nets are the ones a pack installs; they carry the inscriptions, the arcs the engine follows, the schedules. A view is another drawing over the same element ids: no inscriptions, a different layout, shorter labels, and only the lanes that belong to one stage of the work. Deleting a view deletes a drawing and nothing else. The runtime does not know views exist.
The web investigator got this treatment first, on 31 August: one canonical net and three views, one per stage. For this article Hermann got the same, generated rather than drawn. A short script reads his five canonical nets, builds one drawing of the whole persona and one drawing per stage, lays each out from left to right in layers (sources on the left, the lanes they feed next to them, and so on, with a layer wider than six nodes split into two columns), gives every node a label of two to four words, and creates the drawings through the designtime API. Eight views, one command, and the runtime kept firing throughout. The script lives in the pack under views/ and is part of the open-source repository.
Two consequences are worth stating. First, a view shows live status and live counts, because the dots and numbers come from the runtime ids, not from the drawing. Second, a person can read a persona one stage at a time without anyone having to simplify the running structure. The complexity stays where it is; only the picture changes.
Example 1: Hermann, a developer made of five nets
Hermann is the twelve-factor Spring Boot developer described in the case study and built step by step in the recipe. On the runtime he is a model with one session and five canonical nets: setup, audit, spec, build and brain. Together they hold 43 places, 38 lanes and 148 arcs. This is what all of it looks like in one drawing.
Stage 0: setup, the part that runs on a clock
Read it left to right. The config, the goal and principles, and the twelve factor cards are places a person fills through the app, which is why they carry no lane in front of them. The health tick is a MAP lane with a yellow dot: it fires once an hour and writes a setup command. The setup process is a COMMAND lane, a script on the executor, and it fans out into six places: audit requests, the repository record, the journal, errors, infra health and the setup log. Every one of those is something the script measured, not something a model said. This is the shape you will see in every example: a script does the work, and the places on its right are its evidence.
Stage 1: propose the next iteration
Three places can start this stage: a decision record, an answer from the person (when a proposal is sent back to be reshaped), or an iteration trigger written by the release stage. Two MAP lanes turn them into a brief command. The render lane is a script: it reads the plan, the knowledge facts, the scorecard and the earlier runs from their places and assembles one brief token. Only then does the AGENT lane run, one shot, against a contract. Its reply lands in the questions for the person place, where the app shows it as a choice, an interview or a request for the goal. A reply that misses the contract does not reach the person at all; it lands in contract misses, which is the second output arc you can see on the canvas.
Stage 2: the person answers, the spec is written and approved
The person’s answer to a proposal becomes a brief command through a MAP lane; the render script builds a spec brief from it; the spec AGENT writes a spec with acceptance criteria, an API, a migration, environment variables and tests. That spec waits in the specs place until the person’s decision arrives in the decisions place, and the approval lane turns the decision into a coder command. Notice what is not on the canvas: no lane connects the spec agent to the coder. The approval is a token that only a person writes.
Stage 3: the coder, verify and review
The coder is a COMMAND lane, not an agent lane, and that is deliberate. The headless coding agent runs as a script invocation on the executor, with the spec as its brief and the tools its definition allows. The definition is a token in the coder definitions place, which is why a different agent or model is a matter of writing a different token. The script records the run, pushes the branch, opens the pull request and writes a verify command. The verify lane builds the image, starts the container, checks the probes, sends a stop signal and reads the logs; the review brief lane turns the diff into a brief; the review AGENT judges it against the spec and writes a verdict. Two of the four lanes touch a model; neither of them is allowed to count anything.
Stage 4: merge, or send it back
This is the third and last human decision of an iteration, and the canvas shows why it cannot be skipped: the merge lane has exactly one incoming arc, and the place behind it is fed only by the person’s decisions. The fan-out on the right is the reason the persona keeps going after a merge. The audit request re-scores the twelve factors on the merged commit, and the iteration trigger starts stage 1 again once the brain has curated what was learned.
The audit: twelve lanes, not one loop
An audit starts from a request, either written by the merge lane or by the weekly cron on the left. The digest lane measures the repository once and writes twelve factor commands, one per factor. Each factor is its own lane with its own script, and each writes a report with a score, the evidence it used and a suggested fix. The scorecard lane reads the twelve reports and the twelve factor cards, which hold the definition of each factor, and writes a scorecard. Because the twelve lanes read from the same place, they can run in parallel, and because each report is a token, the app can show the evidence per row. A single model call scoring all twelve factors would have been one box on this canvas and no evidence at all.
The brain: observe, curate, apply, answer
After every merge the observe lane collects the signals of the run, the coder’s notes, the verdict, the verification, the diff, and measures the component map of the merged commit in a throwaway worktree. It writes a brief for the curator. There are two curator lanes on the canvas because the persona can be configured either way: a bounded one-shot model call that reads only the brief, or a headless agent that may also read the repository. Both write a curation and both archive it. The apply lane is a script again: it adds and retires facts, rewrites the plan, files proposed decisions and files questions only a person can answer. The answer to a brain question comes back through the same brain command place, which is the small MAP lane at the far left. Nothing the persona knows lives in a model; all of it is in the four places on the right.
Example 2: the web investigator
The web investigator is a research persona: it crawls the sources named in a brief, scores and dates what it fetches, has one narrow model lane categorise the survivors, sorts them into recency buckets, and rolls its own telemetry into insights that feed the brief back. It runs on the same desktop runtime, in a model called research-scout, and it was the first net that got views. Here is the canonical net.
The crawl
Two things are visible here that a prose description would hide. The registry is a place, not a database beside the net, so the dedupe that stopped the crawl from fetching the same page twice is a token written at queue time, and you can count it. And the search branch at the bottom is a copy of the fetch branch with different scripts: search queries widen the crawl, a search command runs on the executor, and the lift lane fans the hits into the same frontier. The errors place, 17 tokens, collects lane failures only; a page that simply returned an error is telemetry, not an error of the net.
The analysis
This is the cheapest picture in the article and the one that explains the cost structure of every persona on this runtime. The gate is a MAP lane: a deterministic score threshold, free to fire. The categorise lane is the only AGENT in the stage, it reads one candidate at a time, and it is profiled to a small model. The route lane is a MAP lane again. So the model is paid per candidate that survived a free filter, and the number of candidates is a count in a place, not an estimate.
The reporting, and the links
The three boxes tagged LINK at the bottom are the part of a net that most workflow tools cannot draw. A link is a typed relation between two places, part of the runtime’s knowledge graph: the brief scopes the taxonomy, the telemetry distils into insights, and the insights feed back into the brief. That last link is the persona’s tuning loop. The competitor analysis lane, the one AGENT here, is labelled “interprets facts only” on the canvas itself, because its brief is the rolled-up taxonomy and never the raw pages.
Example 3: the token janitor, the smallest persona that measures
The remaining examples run on the public staging runtime at agentic-nets.com rather than on the desktop, so they are described from their live structure instead of pictured. The token janitor was the first capability pack ever published for the runtime, and its net is a lesson in one picture’s worth of boxes: 16 places, 11 lanes, 41 arcs, in a session called agent-token-janitor.
Read its lanes in order and the design is obvious. A task arrives in natural language in the task inbox. The first lane is the only AGENT, and its label on the canvas is “Janitor (agent): NL to intent ONLY”. It writes an intent token and nothing else. A MAP lane builds a policy probe from the intent, and a policy gate checks it against a policy place that is read without being consumed; a refused intent lands in a refused place that exists only for the audit. An approved intent goes to preview A, an HTTP lane that counts the tokens in the target place, and a lane named “Record BEFORE (from the API, not the model)” writes that count. Then route by strategy, execute the clear, “Record DELETED (from the API)”, preview B for the count after, and finally “Compose the reply from measured values”. Every API failure has its own place and its own lane, “Report an API failure honestly”.
The reason this net looks the way it does is recorded in the runtime’s own history: an earlier version let the agent report the counts, and it fabricated them, at two model tiers. The fix was not a better prompt. The fix was moving every number out of the agent lane into HTTP and MAP lanes, until the agent had exactly one job left. Hermann’s rule that no model is ever asked to count anything was learned here, on sixteen places.
Example 4: a product team where the developer is a lane
The safe-teams model on staging is a product delivery team: eight role sessions (architect, release train engineer, product manager, developer, devops, operations, QA and scrum), a shared domain session, and a net per role. The developer’s net is nine places and seven lanes, and it is Hermann’s direct ancestor. Its lanes read: inbox pass, which consumes the inbox into a staging place; dev plan, which decides the concrete change from the staged item and a config place; build command token; fire Claude Code, a COMMAND lane; result to done or error, a MAP lane that routes the raw result; and dev error to PM status, which hands a failure to the product manager’s net. A LINK lane connects the developer’s knowledge place to the inbox.
Put that next to Hermann’s stage 3 and the lineage is plain: decide, build a command token, fire a headless coder, route the result. What Hermann adds is everything around that shape, the spec contract in front of the coder, the verification and review behind it, the twelve-factor audit, and the brain. The shape did not change. It got places around it.
Example 5: the academy patterns
The academy model on staging holds six small nets in a session called patterns: a traffic light, a fork and join, an if and else, the dining philosophers, a producer and consumer, and an agent bootstrap. They are teaching nets, and the dining philosophers is the one to look at if you want to know why the rest of this article works. Ten places, six lanes, 27 arcs. Three philosophers, Socrates, Plato and Kant, each with a thinking place and an eating place, three forks as places, and for each philosopher a lane labelled “picks up BOTH forks (atomic)” and a lane “puts forks back”, which also writes to a rolling meals place.
The classic deadlock, everyone holding one fork and waiting for the other, cannot happen on this net, because a lane fires only when all of its input places have a token and then consumes them in one step. That single rule is the same rule that makes Hermann’s coder lane wait for a command, an approved spec and a coder definition together, and the same rule that lets twelve audit lanes share one command place without stepping on each other. The academy nets exist so that a newcomer sees the rule on six boxes before they meet it on thirty-eight.
Example 6: applications are nets too
The Studio applications, Goals, Interview, Protocol and Kanban, each appear in the runtime as a tiny net in their own session: the Goals application is three places and two lanes, Interview four places and three lanes, Protocol a single place, the Kanban persona two places and one lane. That is the whole application layer made visible. An application store is a place; an application action writes a token; the application itself owns no state. Hermann’s app, with its twenty-six stores, is the same idea at a larger size: every tab is a projection over places of the five nets above, and closing the app changes nothing on any canvas in this article.
What the six have in common
- Scripts measure. Every count, score, build result and health check in the pictures comes out of a COMMAND or HTTP lane and lands in a place. That is why the numbers on the canvases can be trusted: they were never in a model’s reply.
- Bounded calls judge. The AGENT lanes are few, narrow and contracted. Each has a place for replies that miss the contract, so a bad answer is a token you can inspect, not a silent downstream failure.
- A person decides in a place. Hermann’s decisions and answers, the janitor’s policy, the scout’s brief: wherever a human is needed, there is a place with no lane in front of it. The net waits there for as long as it takes, with no session open.
- Nothing ends. None of these nets has a final place. A merge writes an iteration trigger, an insight feeds a brief, a meal returns a philosopher to thinking. The process is the structure, and the structure keeps running.
- Views are for people, links are for knowledge. A view changes what a person sees and nothing else; a LINK lane changes what the runtime knows about the relation between two places. Both were added to running nets without stopping them.
Take your own pictures
- Open Studio, choose the model and the session in the Session tab, then open the Editors tab and click a stored net.
- Enable auto-refresh on the editor’s header so the places show their live counts, and press F to fit the net into the editor.
- If the net is too big to read, make a view: a second drawing over the same element ids with only the lanes of one stage, laid out from left to right. Hermann’s pack ships the script that does this; for any other net the designtime API takes the same four calls per drawing: create net, add places, add transitions, add arcs.
- Take the screenshot at a wide page width with the sidebar open. A view laid out left to right fits without maximizing, and the sidebar is what tells the reader which model, session and net they are looking at.
The runtime is open source and runs as one desktop download or a Docker Compose file: github.com/alexejsailer/agentic-nets. Hermann’s pack, including the view generator, is in the same repository under capabilities/hermann.