Yesterday, Hermann was one virtual developer living in a net. Today, Agentic-Nets gets the organization around him: a Product Office above Service Teams, with a virtual Product Owner, Architect, QA Engineer and Developer for each service placed under management. The first product this organization is developing is Agentic-Nets itself.
Every picture in this article is a screenshot taken on 10 September 2026 from a live Agentic-Nets runtime on my Mac. The node team is the one team exercised end to end. Nothing in that photographed run is mocked: its requirement, spec, acceptance criteria, branch, verification and review were produced by the nets described here, and the only thing still waiting at the end is my click on Merge. The separate proof harness later in the article deliberately uses a fake coder.
From one developer to a software organization
The design gives every service a small team of four personas: a Product Owner who owns requirements, an Architect who owns decisions and specs, a QA Engineer who owns acceptance and production readiness, and a Developer who delegates implementation to a coding agent. Above them, a Product Manager maintains the product goal, allocates iterations across teams and collects everything that waits for the person. Three rules are structural rather than cultural: every change has a spec before implementation, work stays on branches, and the person decides what enters the product.
The organization itself runs on Agentic-Nets. Under the applications is a persistently deployed, event-driven bipartite graph: places on one side, transitions on the other. Places keep durable tokens for requirements, decisions, questions, context, status and evidence. Transitions react when the state they need arrives. An implementation run can finish. The organization, its context and its open decisions remain deployed and alive.
Why nets and not a workflow
A team of personas is not a temporary pipeline. Questions may wait for days. Approvals arrive out of order. A verification can fail and send the coder back with notes. A reviewer can approve while leaving a major observation for the person. In a conventional workflow, the execution is usually the unit that lives and ends. Here the net is the unit that lives: a question is a token in one place, an approval is a token in another, and a transition fires when the state it needs is present. That state survives restarts, stays queryable and remains visible to someone who was not watching the run.
The second reason is context. The coding agent is the expensive, powerful and least predictable part. It gets exactly one input: a context pack assembled by the architect’s lane from the requirement, the spec, the acceptance criteria, the accepted decisions and the constraints. The pack is a token. It can be read before the coder starts, and it is what the reviewer later compares the diff against.
The third reason is history. Model mutations are event sourced, and the operational event line and the teams’ own journal places make the work observable. An operator can inspect what changed, which transition acted, what evidence it produced and why the process is waiting. The current state can be reconstructed from persisted events, while the amount of operational history kept is a deployment policy rather than an unlimited promise.
The Developer is a role; the coder is a tool
The virtual Developer owns the branch, the delegation, the hand-off to QA and the review-and-merge boundary. The coding agent behind its command transition is replaceable configuration. This run used Claude Code with Opus. The pack also contains a Claude Code profile for Fable and a Codex CLI definition. A Codex definition backed by Astra, or another headless coder, can be added behind the same command-and-result contract, but that was not exercised in this run.
The same distinction matters when the organization changes itself. An operator or appropriately scoped runtime agent can add a place, install a Tool-Net, or stop and replace one lane between firings while unrelated lanes continue. Existing tokens do not have to disappear with the old lane. The coder in this case has none of that authority: it receives no runtime MCP token, sees one approved context pack and works only in a scoped repository clone. Adaptable does not mean self-authorizing.
Two packs, one model
Everything lives in one model, agenticnets-product, as two NetHub packs.
- product-office is installed once, into the session
product. It holds the product charter (goal, principles, constraints, services), the product manager lane, the roadmap, the registry of teams, the inbox of everything waiting for the person, a daily digest and a brain. - service-team is installed once per service, into a session named after the service. The hub prefixes every place, transition and net with the service, so the node team’s places are
p-node-team-*and the master team’s will bep-master-team-*. One pack, many instances, one model.
A team registers itself with the office when it is provisioned, and from then on it pushes its status rows, its questions, its approvals and its merge decisions into the office places. The person works in two apps: the office app for the product and the allocation across teams, and one team app per service.
The application is the human interface
Nobody has to operate this organization by moving Petri-net tokens. The Product Office app turns the product goal, roadmap, team registry and shared inbox into a product-management surface. Each Service Team app turns the same live runtime into Product Owner questions, architecture decisions, acceptance evidence, coder runs and a review queue. The screenshots in this article are those applications, not a separate reporting system placed beside the nets.
An Agentic-Nets Application is not merely a decorative frontend around an agent in a conventional backend. Its manifest binds named stores and guarded actions to places in the live runtime. A form writes structured state for a persona. A Kanban board can expose work moving between places. A review surface can assemble the requirement, spec, verification, review and diff, then write the person’s decision back into the same process. Close or replace the application and the organization continues to wait and work.
The same application layer can provide goals, interviews, protocols, incident consoles, forms, dashboards or completely domain-specific views. Applications and nets can evolve together, but not by magic. Replacing a transition behind an existing place can leave the interface unchanged. Adding a new persona, store or action to a bespoke interface requires an intentional application and manifest update. The pack can version and install that update through NetHub while preserving the durable state of an additive upgrade.
NetHub makes the organization portable. A versioned artifact can carry the nets, inscriptions, scripts, dependencies, manifest and interface that define a capability, with credentials left behind. Another model can install the Product Office, add a namespaced Service Team or bring in a Tool-Net as a new governed skill. A running net can also be shared through an expiring, read-only live view. What is shared is executable organizational behavior and its observable state, not just a prompt.
The office: goal, roadmap, allocation
The office starts with a question. The first iteration of the product manager lane rendered a brief from the charter and found no product goal, so its one-shot agent asked for it with three example goals to adapt. Eleven seconds after the iteration token landed, the question was in the person’s inbox. After I wrote the goal, the next brief carried it, and the product manager proposed the next steps across teams: install the node team first, then a bounded improvement for the node. Every option comes with an effort, a risk, the evidence lines from the brief it was built on, and exactly one recommendation.
An allocation is two tokens: a roadmap item in the office and an iteration trigger in the team’s iterate place, looked up from the registry. The office never calls the team. It writes a token where the team reads.
The product owner: measure first, then propose
The iterate token becomes a brief command. Before the product owner proposes anything, the lane measures the module: file counts by type, test files, recent commits, and a read-only analysis by the coding agent that describes the module for someone who must decide what it needs next. For the node service that analysis took 351 seconds and came back with entry points, debt and a list of what already looks production-ready.
The proposal was grounded in that measurement. The office had asked for a health check endpoint; the analyst had found that the node already exposes actuator health, metrics and mappings. So the product owner proposed a new endpoint as the recommended option, following the office’s direction literally, and a custom HealthIndicator on the existing actuator surface as the second option. I chose the second with a note. The answer became a requirement under a contract: story, summary, scope, out of scope, measurable done conditions, risks and priority. A draft copy went to the architect.
The architect: a spec catalog that mirrors the code
The rule is that every change has a spec before anyone implements it, and specs must live somewhere structured. The architect’s lane builds a spec catalog as a net: it scans the service’s code, creates one place per module and links every module place to the catalog root with a typed contains link transition. For the node module that is 14 modules, from the backup package to the REST layer. A spec is a token that names its module, so the catalog is browsable the way the code is browsable.
The spec itself was written by a one-shot agent from a design brief: the requirement, the catalog, related specs, accepted decisions and the constraints. It named the module, listed the design steps, the interfaces (two configuration keys with defaults, the component name), the files, the constraints, the verify condition and the risks, and it proposed a decision record: reuse the actuator health surface with a bounded catalog check. The person is asked to approve the spec, in the team app and in the office inbox. Approving the spec accepts the decision record.
QA: criteria a script can run
An approved spec becomes an acceptance brief. The QA’s one-shot writes criteria in given, when, then form, each with a check that a script can run: a test method name, a compile command, a curl with a time budget. Six criteria for this spec, and the list of tests the developer must add. The acceptance record is what triggers the context pack: the architect’s lane assembles it from the requirement, the spec, the acceptance criteria, the accepted decisions and the constraints, runs the policy gate (autonomy level and daily budget), and asks the person to start the coder.
The developer: a branch, never a push
My approval of the pack started the virtual Developer. It checked out the team’s own clone of the repository, created the branch node/spec-node-001, and delegated the bounded implementation to the configured headless coding agent with the rendered pack as its only instruction. The rules in the pack were short: only files under the service directory, commit on this branch, never push, never merge, run the test command before finishing, note every deviation. The run took 762 seconds and 52 turns and produced five files: the indicator, a unit test class, an integration test class, a test property file and a note in the team’s spec catalog document. The coder’s report lists its deviations, including the one that mattered later: the bean could not be named as the spec said because that name was taken.
QA then verified the branch: build, the test suites, the diff against the spec’s files and the service scope, and every criterion mapped to the evidence. The first verification failed with exit code 127, because the charter’s default commands assumed a Maven wrapper the node module does not have. That is the kind of thing a measured pipeline finds in minutes. The command was corrected in the charter, the re-verification passed, and QA replaced its own record.
A passing verification becomes a review brief with the full diff. The reviewer approved with one major point (the bean name deviates from the spec, the component key is kept) and two minor points. Then the developer’s lane asked the person to merge.
Merge is a click, and the click is a decision token. A map transition turns it into a merge command, and the command transition does the merge: no fast-forward into the clone’s main, the branch fetched into the workspace repository, and the workspace main merged only when that tree is clean and on main. Nothing is pushed by a net. The person pushes.
Reading the nets
The team is seven nets and 31 lanes; the office is four nets and 15 lanes. The canonical nets are what the pack installs and what the inscriptions belong to. Because places and transitions are global in a model and a net is only a drawing of some of them, I can also draw views: one drawing per persona over the same element ids, laid out left to right, with no inscriptions of their own. Deleting a view deletes a drawing, never a place or a lane. The views below are those drawings, straight from Studio.
Setup
An hourly health tick and the setup process: it measures the host, stores the runtime’s MCP token for the command lanes, clones the workspace repository into the team’s home, and registers the team with the office by writing a command token into the office’s setup place. Pause stops every lane but these two; resume starts exactly what pause stopped.
Product owner
An iteration trigger becomes a brief command, the brief becomes a proposal by a one-shot agent, the proposal lands in the prompts place and a copy goes through a map lane that tells the office. The person’s answer becomes a requirement brief; the requirement is written by a second one-shot under a contract, and a copy of it is the draft the architect consumes. A reshaped question goes back to the brief.
Architect
The requirement draft becomes a design brief; the spec is written by a one-shot; a draft copy asks the person for approval; the acceptance record (from QA) triggers the context pack and the gate.
QA
The person’s spec approval becomes an acceptance brief; the criteria are written by a one-shot; the developer’s lane hands every built run to the verify command; a weekly cron runs the readiness audit into a scorecard, and red checks become bugs.
Developer
The pack approval starts the coder; a passing verification produces a review brief; the review one-shot’s verdict becomes the merge question; the merge decision runs the merge command; a change request sends the coder back with the reviewer’s points and the person’s notes.
Brain
After a merge, the observe command collects what happened (the requirement, the spec, what QA measured, what the reviewer said, what the coder reported) into a signal; a curator turns it into facts with sources and confidence, a plan, decision proposals, questions and ideas; the apply command writes them into the knowledge places, asks the person the questions and starts the next iteration when nothing waits.
The office
The office has the same brain as a team, one level up: it observes a team’s release, curates facts and a plan across teams, and asks the person its questions.
What the proof harness checks
Before the live run, the whole chain ran on a proof model with a fixture repository and a fake coder that commits one documented file: install, provision, allocate, requirement, spec (with the catalog and its link lanes), acceptance and pack, implement, verify, review, merge into the clone’s main and into the workspace main, and a guard that refuses a run for a spec that was never approved. Eleven checks, green in about two minutes, three times in a row. The harness found the defects that a person would have found in the app days later: a map lane that reads without consuming re-fires on the same token, an empty array counts as a missing field in an answer contract, and a runtime restart replays in-flight command tokens and can start a second coder in the same working tree. Each became a rule in the pack.
When the organization becomes one of its own products
One reflexive loop is already real: a Product Office and Service Team running on Agentic-Nets used Agentic-Nets to prepare a change to Agentic-Nets. The proof harness also found defects in the organization around that work, and those defects became rules in the packs. This is a self-hosting engineering harness. It is not a team silently rewriting or approving its own controls.
The next loop is governed self-improvement. The packs, transitions, applications and proof harness can themselves become product components, then pass through the same requirement, spec, acceptance, test, review and human-decision chain. A dedicated, separately authorized lane can use event and outcome history to propose a new validation step, a specialist persona or the replacement of a repeated agent procedure with a deterministic Tool-Net. The proposal can be versioned, tested, reviewed, installed and rolled back while unaffected teams keep operating. The platform never needs to rewrite itself in secret.
What a person actually does
- Defines the product goal, principles and services once, in the office app.
- Installs a team per service and clicks Provision. The team registers itself.
- Answers the product manager’s proposals and the product owners’ proposals: a choice, an interview, or a reshaped question.
- Approves specs and context packs, or sends them back with notes.
- Merges, requests changes, or drops a run. The merge is a command transition.
- Reads the digest, the scorecards, the brain’s facts and its questions.
Everything else is a lane. The lanes are visible, their journal is a place, and they can be independently stopped, replaced and restarted between firings while the rest keeps running. This is more than workflow automation: the implementation run ended, but the team and its state did not. What exists now is a living software organization that can keep operating while its tools, nets and applications evolve through controlled change. Developing the runtime with that organization is the most honest test I could think of.
Both packs are in the Agentic-Nets repository under capabilities/product-office and capabilities/service-team, with their view builders and the proof harness. The merge for spec-node-001 is still waiting for my click.