One Net per Level: Developing a Real App as a Hierarchy of Agentic-Nets

Every screenshot in this article was taken on 12 October 2026 from the Agentic-Nets desktop app on my Mac and from the iPhone and Apple Watch simulators. The subject is Poweeer, a readiness app for iPhone and Apple Watch that I am building for myself: 119 Swift files, 31,943 lines, 288 commits since 25 September. Since this week the whole app is described as one model on the runtime, eight levels deep, with the product intent at the top and the code at the bottom. This is what that looks like, how the model is kept true, and why nothing in it is specific to software.

The problem: the most complex artifact is the only one that stays true

In a real application the code is the most complex artifact there is, and it is also the only one that cannot lie: it either compiles and passes its checks or it does not. Everything above it is softer. The concept document says what a value means, the design notes say why a screen is ordered the way it is, the chat with the coding agent holds the reasons behind a formula, and the formula itself lives in a Swift file with a parameter table. These layers drift apart the moment anyone touches one of them. A week later the document describes a rule the code no longer implements, the reason behind a decision is in a conversation nobody can find, and the only way to learn what the app really does is to read all of the code.

Coding agents make this worse, not better. They are very good at the bottom layer and have no place to put the top. The intent, the decisions, the measured facts and the open questions end up in prompts and transcripts, which is exactly where they evaporate.

The idea: one net per level, refinement between them

Agentic-Nets already had the building block that makes this fixable. A transition in one net can be refined by a whole net one level down: the child net’s input and output places carry the same ids as the places around the parent’s transition, so both drawings share those places and the runtime stays flat. The parent transition is abstract; it never fires, the child’s transitions do the work. Applied once, that is a subnet. Applied level after level, it is an abstraction hierarchy, and the Model Explorer (shipped this month) is the view that makes the hierarchy readable: named levels as bands, nets as cards, refinement edges between the bands, shared places as the data that connects them.

For Poweeer the levels are these, top to bottom. Each one answers a single question, and a fact lives on exactly one level:

An eighth band, “Work”, holds what is not the model but the work on it: the applications that ask questions, track goals and cards, and a context net with the reasons behind the newest feature. More on those below.

The whole model is 58 nets with 290 places and 247 transitions, 53 of them refinements of a transition one level up, and every one of the 53 verified by the runtime: the child’s ports match the parent’s preset and postset exactly. Depth is 3. Sixty-three places are shared between nets, which is the horizontal coupling: the same day records place is drawn in the product net, in four rules nets, in the persistence and device sync nets, in the App Group storage net and in two module nets. Click it and the Explorer shows all of them.

Reading one net on each level

Take the Power sleep, the night that every sleep rule in the app uses. On the Concepts level it is one transition, “Power sleep”, inside the “Understanding the day” net, between the recovery phases and the schedule. One level down, the rules net refines it into three steps: group the recovery phases (gaps of at most 60 minutes), take the longest group that ends in the day, refine its edges (onset is the start of stillness before it, wake is the first steps after the last qualifying phase). The net’s definition carries the two parameters it depends on, read from the Swift parameter file, the acceptance statements, and a reference into the concept document with the exact heading that must exist there. One level further down, the module net names the Swift files and the functions that implement the edge refinement.

The same drawing exists in Studio, the editor. A transition that is refined carries a small badge; clicking it opens the child net next to the parent. This is the picture a person reads when they want the structure rather than the text.

At the bottom, the module level is a code map rather than a drawing: 27 nets, each with a domain, a responsible persona and the files it owns. The checker that reads the model also reads the repository: every file a module net references must exist, every function or type a transition names must be declared in one of those files, and every parameter value a rules net states must equal the value in the parameter file. Every one of the 119 Swift files outside the documentation folder is referenced by a module net; on 12 October the checker reported 0 findings over 177 references, 201 named symbols and 35 parameter values.

The work around the model, as applications on the same runtime

A model that only describes would still drift. What keeps it alive is that the work happens through it, and the work has a home on the same runtime: the Interview application for questions to me, Goals for progress per level, a Persona Kanban for findings, and one persona per level. The personas are not running agents. Each is a charter: a short prompt that says which level it owns, what sits above and below, how to read its level from the live model, what counts as a finding and where to record it. I play them from Claude Code, connected to the desktop app over MCP, by saying “play the rule keeper and work through its checklist”. The persona reads the model with the explorer tools, checks it against the documents and the code, files findings as cards, asks me through the Interview, and reports progress on its goal. It changes only its own level, and a change always goes through the specification file and the builder, so the model never drifts from its source.

One feature, top to bottom, in one evening

On 12 October I wanted a new page that shows my workouts from Apple Health. The feature started at the top: a goal, and two draft definitions, one on the rules level (“which records are activities and which values does each carry”) and one on the experience level (“where is it shown and what does it open with”), each hanging under the transition it refines. The personas asked four questions through the Interview, each one addressed to the net it was about, with options to pick from: which Health records count, which values to show, where to place the page, what it opens with. I answered in the inbox. The answers became decisions, the two definitions were revised with them and marked ready, the module developer wrote the Swift code on iPhone and Watch, the logic checks were extended, and the two nets were realized together with two new module nets that reference the new files. A context net on the Work band keeps the reasons: my words, the decisions, the Health sources and types, the code, what was measured and what stays open, connected by link transitions that never fire and only say how a fact relates to another. The goal reports 10 percent at the start, 90 percent after the build, 95 percent after the chart that followed.

Keeping it true: confirmations, flags and question rounds

After the first day I measured something uncomfortable. Ten questions had been asked and answered, all of them about new work; not one checked whether the abstraction I had written the day before was right. All 65 definitions said “realized”, which only means “built”. Nothing could record that I agreed with a net, and nothing could take that agreement away again when the code moved. So the second thing the Explorer got was a review layer, and it is the part I now use most.

• Confirm. I read a net, or one transition of it, and it describes what it claims to describe. The confirmation records the definition revision and a hash of every file the definition references.
• Flag. Something is stale, unclear, wrong, a contradiction, unmeasured or too coarse. A flag stays open until it is resolved, and a deterministic id makes a repeated mechanical check idempotent.
• Stale climbs up. When the referenced sources change after a confirmation, a tool flags the net stale and flags the transition it refines one level up as “level below changed”. That is the bottom-up direction: the higher layers show where a statement may no longer be true.
• Needs me. Every band shows how many of its nets are flagged, have open questions, or were confirmed; every card carries the same badges; one filter shows only what waits for me.
• Question rounds. “Run a question round on the rules level” makes the persona check what it can measure, flag it, and then ask me one question at a time about what only I know: the reason behind a rule, whether a description still fits, a better name, whether a net is too coarse. The round is a pair of MCP tools, not a prompt: one returns the worklist of a level top-down and bottom-up (transitions nothing refines yet, refinements that do not verify, nets that hang below nothing, open flags, open questions, nothing confirmed), each item with a ready-made question; the other asks, records the answer and confirms or flags in the same call. Any MCP client can run the whole loop without a server-side model.

Confirmations and flags are an application like the others, a manifest with two stores and three guarded actions and no user interface of its own; the Explorer is its surface. It lives in the open-source repository and the runtime seeds it into every installation.

Nothing here knows what a source is

Poweeer is an app, so its lowest level is code. That is a property of this model, not of the runtime. The levels, the refinement, the shared places, the definitions with their references, the confirmations and the question rounds work the same for a process whose lowest level is a checklist, an organisation whose lowest level is a role description, a body of rules whose lowest level is a paragraph of law, or a curriculum whose lowest level is a lesson. A reference is a kind and a location: a document, a code file, a trace, a dataset, a record, a web page, or a word of the domain. The hash a confirmation records is the hash of whatever local files the definition names. The checker that compares parameter values with a source file takes a file and a pattern, not a programming language.

I checked this on the evening the review layer went in, because the first draft had leaked its first use: a field called code hash, reference kinds limited to code, trace and document, prose that said “after a code change”. All of it is renamed now, and the design document carries the rule: domain words belong in a model’s specification and in its level names, never in the platform.

What a domain brings is the specification: a JSON file with its levels, its personas, its nets (places, transitions with inputs and outputs, which parent transition each net refines), the definitions with their references, and the applications to install. The builder turns it into the live model and is idempotent: a second run creates and changes nothing. The checker finds the gaps before anything is written. The end-to-end script verifies the live model, 44 checks when built from nothing into a scratch model and deleted again. Poweeer’s specification lives in Poweeer’s repository, next to its code; the tools live with the runtime and contain no word of the domain.

Measured on 12 October 2026

• The app: 119 Swift files outside the documentation folder, 31,943 lines, 288 commits since 25 September 2026, built for iPhone and Watch.
• The model: 8 levels, 58 nets in the specification (70 in the catalogue with the persona charters and the application nets), 290 places, 247 transitions, 53 refinements all verified, 63 shared places, depth 3, 71 explicit relations, 8 link transitions and 56 fact tokens in the context net.
• The checker: 177 references into the repository and the documents, 201 named symbols, 35 parameter values, 0 findings.
• The work: 10 questions asked and answered through the Interview, 10 active cards on the board, 8 in the backlog and 2 in review, plus 6 done, one feature taken from a goal to running code on both devices in one evening.
• The review: 70 of 70 nets unconfirmed at the end of the day. That number is the point: the model now says out loud what nobody has agreed to yet.

Try it

The Model Explorer, the Interview, Goals and Curation applications and the MCP tools are part of the current Agentic-Nets desktop app and of the open-source repository. A specification is a JSON file; this is the shape of one net in it:

{
  "key": "rules::power-sleep-rules",
  "name": "Power sleep rules",
  "refines": {"net": "concepts::understanding", "element": "t-power-sleep"},
  "places": {"p-phases": "Recovery phases", "p-health": "Health readings",
             "p-phase-groups": "Phase groups", "p-sleep-candidate": "Longest group",
             "p-sleep": "Power sleep and night"},
  "transitions": [
    {"id": "t-group-phases",  "label": "Group phases",  "in": ["p-phases"], "out": ["p-phase-groups"]},
    {"id": "t-longest-group", "label": "Longest group", "in": ["p-phase-groups"], "out": ["p-sleep-candidate"]},
    {"id": "t-refine-edges",  "label": "Refine edges",  "in": ["p-sleep-candidate", "p-health"], "out": ["p-sleep"]}
  ],
  "parameters": {"powerSleepGapMinutes": 60, "powerSleepRefinedEdges": true},
  "definition": {
    "acceptance": ["Smaller groups recharge with their phase gains; only the Power sleep drives the asleep rules."],
    "references": [{"kind": "doc", "uri": "Docs/CONCEPTS.md", "contains": "Power sleep"}]
  }
}

Check it, build it, verify it, and ask what needs you:

python3 -I check_spec.py  model.json            # 0 findings, or the list
python3 -I build_model.py model.json            # creates what is missing, changes what differs
python3 -I e2e_model.py   model.json --scratch  # the same spec from nothing, verified, deleted
python3 -I curate.py      model.json status --needs any
python3 -I curate.py      model.json stale --apply   # after the sources changed

Then open the Explorer, pick the model, and start a question round on the top level. The first question will be whether the product net describes what the thing is for. It is a good question to be asked by your own model.

Built and measured on the Agentic-Nets desktop app, version 2.60.0 with the development builds of 12 October 2026. The model, the persona prompts and the specification are in the app’s own repository; the builder, checker and curation tools are domain-neutral and ship with the runtime.

Related: Read the Net: Six Agentic-Nets Examples, Explained From Their Canvases, Hermann: A Twelve-Factor Developer That Lives in a Net.