Application architecture

An application here is entities and actors: it declares the things of its ontology, and it runs as actors acting on them and observing them. Everything on this page makes that sentence precise, and most of it is design rather than shipped software — the floor underneath is built and exercised, the shape above it is worked out and not yet compiled designed.

The entity ships the behaviour; the actor comes from outside

An entity declares its ontology and ships functions — the verbs anything may invoke against it. It also declares seats: roles its story expects to be occupied, never the beings that occupy them.

The actor is not part of the entity, and it has exactly two capacities. It acts — invoking a function, which deposits a payload and lands an act — and it observes. Nothing else is on offer, and nothing else is needed.

Both capacities are identical at every altitude: a hand at a keyboard, a woken script, an agent with a life of its own. A person and a cron job share no structure whatsoever, so what makes them both actors cannot be anything they are made of — it is a position taken toward something else. The actor’s identity is what signs the commit; a seat is what the entity was expecting.

Which is why a reactor is never a program of its own. It is one of the entity’s functions with a line plugging it into an event. The behaviour belongs to the entity, not to the application around it.

One act is one sentence

The irreducible act of the platform is small: an actor writes into an instance’s worktree and commits. The commit is the action.

Read any log and you do not see commits appearing on their own; you see someone having done something — attributable, dated, signed, publishable. Every layer that supervises, audits, approves or bills agency works in that unit, and the platform performs the mechanics once for everybody rather than each application reinventing them.

The primitive itself carries no verb, because the noun is all the substrate can read — enough to match a subscription, never enough to interpret:

$ entity act acme.note:n1 write -- /usr/local/bin/append-outline

Method semantics — parameters, an expected result, whatever a “call” was for — live on the function the entity declares, one floor above. The body runs in the act’s own private area rather than in the directory you typed from, so that command is named by absolute path.

The application is a graph

Vertices are actors; edges are armings — this landing wakes that function.

$ entity on acme.note:n1 write.landed -- /usr/local/bin/reindex

The root of every chain is an act nobody was woken for, which is where external will enters — a person, a clock, a message arriving from outside. The chain then runs until nothing is armed on what last landed, and that exhaustion is what an idle application is. Nothing initiates.

The wiring is written by hand today: one arming line per row of the entity’s own table. Compiling that graph from a declaration is a Process’s job, and it comes after the applications that would prove it designed.

Three things fall out of the shape, and none of them is a feature anyone built:

• Every application gets a hook system. A gate that refuses an act before it is true, a stage that runs after one lands, a stranger’s extension wired into an ontology it did not write. What an agent framework builds by hand, inside one process, at one vendor, for the length of one session, is here the same mechanism that makes any entity work at all. The arming mechanism runs and was seen firing runs; that it is free in every application is the design designed.
• Observability is a property of the substrate. One source, many lenses — the conversation view, the audit, the aggregate, the unrolled chain of what happened all read the same tree. A tracer is a lens pointed at a coordinate, not an agent injected into a runtime.
• Federation is a matter of deployment, not design. Arming is per installation, so two sites may arm different halves of the same table — one running a seat, one merely watching it. A push crosses the same hook a local commit does, so the graph does not learn that a vertex moved to another machine designed.

The circuit, read aloud

The worked example is a chat application, and its shape is every application’s. The entity declares the seats, the payloads and the state machine; the installed application is a hook plus a table of armed commands, and that table is the machinery designed.

1. Whoever holds the user’s seat calls user say, which writes the turn and commits prompt — the root act, the one nobody was woken for.
2. The hook fires, runs what is armed at prompt.landed, and returns. The commit is never held hostage to the chain it starts.
3. Armed there is the runner, which is the assistant’s reply function — registered by the actor itself, since which occurrence obliges it is part of what it is.
4. The runner folds the tree, sees owes_inference, calls the model through its /dev/llm/ device — the long wait lives inside the vertex, synchronous within — commits reply, and dies.
5. The hook fires again on that very commit. The runner wakes on its own act, folds, sees nothing owed, and stands down. Idempotence by reading, never by remembering.
6. If the reply carried function calls, the fold says owes_results; whoever holds the executor’s seat commits one function-result per call, the hook fires each time, and the chain continues until the fold says idle — the graph exhausted.

Nothing in that list is a component of the application. There is no runtime in the middle, no dispatcher, no supervisor. Every box is one of the entity’s own functions and every arrow is a line in a table. The temptation is to call the middle vertex the runtime — it is the one that calls the model, waits, and decides — but it decides nothing the fold does not tell it, and the same shape with a different fold is any other application. What varies between a chatbot and an agent is the sophistication inside one function, never the circuit around it.

Two bodies raised for the same landing both act and both try to commit; compare-and-swap refuses the loser, which re-folds, sees nothing owed, and discards its turn. The residue is exactly one wasted model call — priced, not prevented designed.

The face is an actor that only observes

A frontend is the acting-and-observing pair wired to a surface, and the backend beneath it is byte-for-byte the same whatever the surface is: a terminal, a window, a script. Of the two capacities a view exercises one — it reads and it never acts — which makes writing a view for an entity you did not write the normal case rather than an integration: the model is on the floor and the type is declared, which is all a lens needs.

That is the platform effect arriving at presentation, the exact twin of what publishing occurrences does for behaviour. Someone can put a face on your software, or automate around it, without your cooperation and without your knowledge.

Which is the whole argument of this section, in its last form: the reason any of this composes is that the state, the occurrence and the identity of who did what are held by the machine, once, beneath every language — and what remains for you to write is the part that was actually yours.