Agents as composers.

Most agents improvise. They choose a step, write its arguments — sometimes write the code itself — run it, and choose again. The plan only exists once it has been performed.

The procedural graph and verified context field notes gave an Octonomous Being two explicit memories: how it has learned to act, and what it believes and why. This note adds the part that touches the world — and changes the Being's role in using it.

It proposes a library of code controllers: small, deterministic programs whose identity is verified and whose behaviour is validated. And it proposes a Being that works as a composer. Instead of performing each step, the Being writes a composition — a short, typed score that binds verified context to verified controllers. The score is checked before anything moves, signed when it passes, and played by code that cannot improvise.

This field note as a podcast conversation

The same ideas in audio — why autonomous AI needs composers, and conductors.

Composing and performing in the same breath

Most agent loops interleave deciding and doing.

Two patterns dominate. In tool calling, the model chooses a function and fills its arguments one step at a time, reacting to each result. In code generation, the model writes a program and a sandbox runs it. Both are capable, and both share a property that matters more the longer an agent lives: there is no moment between deciding and doing when the whole plan exists and can be checked. Each step is committed before the next one is known.

Three failures follow.

None of these is fixed by a better model. A more capable improviser is still improvising — in production, where every wrong note is heard.

Verified is not validated

The two words are often used as if they were one. This note keeps them apart, because they answer different questions, fail in different ways and are checked by different means.

A signed controller with a bug is verified and not validated. A well-tested controller of unknown origin is validated and not verified. A credential from a trusted issuer that expired last month was verified, and is no longer valid. A Being needs both checks, on both sides of what it composes.

Verification answers who and what. Validation answers whether, and for what.

The facts a score depends on

The verified context field note turned every edge of a Being's knowledge graph into a claim, with a source, evidence, a confidence, a signature and a validity window. That note asked how a Being should hold beliefs. Composition asks how it should use them.

In a composition, an input is never free text. It is bound to a context edge by that edge's identifier, and it carries the edge's provenance with it. A controller's preconditions are queries against the same graph. To continue the example from the companion notes — a member asks for money to repair the community hall's switchboard:

step      Disburse@9c41…
payee     ← Vendor ─account_for→ Account
          source bank · confidence high · verified_by bank ✓
amount    ← Quote ─total→ 1,840.00
          source vendor · verified_by vendor ✓
approval  ← Request ─approved_by→ Treasurer
          valid_until 31 Oct ✓
pre       Member ─in_good_standing→ Community
          needs ≥ high ✓

One step's bindings · illustrative identifiers and values

Binding is what defends against the commonest failure in agent systems: the right tool called with the wrong facts. An instruction hidden in an email can still put a claim into the graph — but it arrives as a self-asserted, low-confidence edge, and a precondition that requires a verified issuer won't bind to it. That doesn't make a Being immune to manipulation. It makes the origin of every argument visible, and lets a rule refuse the ones it can't trace.

Small programs that can't improvise

A controller is a small piece of deterministic code with a declared contract: what it accepts, what it returns, what must be true before it runs, what must be true after, and what it changes in the world. It is published under a digest of its own content and signed by the identities that wrote, reviewed and tested it.

The name is deliberate. A controller controls an effect — a write, a message, a transfer, a schedule. Nothing in it is generated when it runs. The intelligence isn't in the controller; the controller is what the intelligence is permitted to use.

Of these, effects matters most. Once every controller declares what it touches, a Being's authority can attach to the class of effect rather than to a list of tool names:

Read freely. Write within scope. Act externally with a record. Do anything irreversible only with a principal or a quorum. This is the decision AI note's principle — authority proportional to justified confidence and to what happens if it's wrong — attached to something a runtime can actually check.

The score is the artefact

With verified context and verified controllers in place, the Being's job changes. It doesn't call tools one at a time. It writes a composition: a short, declarative graph of controller steps, with every input bound to a context edge or to an earlier step's output, every condition written as a query, and every effect declared in advance.

composition  fund-hall-repair · draft 1
intent       repair the community hall switchboard
procedure    OPG › Construct Proposal → Seek Approval → Execute

1  VerifyQuote@d41c         quote    ← Request ─has_evidence→ Quote
2  CheckLicence@77ae        vendor   ← Vendor ─certified_for→ Electrical
3  ReserveFunds@a90f        amount   ← 1.total        write
4  RequestApproval@3b12     reserve  ← 3.id           external
5  Disburse@9c41            approval ← 4.decision     irreversible
                            payee    ← Vendor ─account_for→ Account
   on 4 = declined  ↺ ReleaseFunds@51d0  compensates 3
6  RecordContribution@e0c8  receipt  ← 5.receipt      write

Draft composition · illustrative · digests shortened

Three properties make this different from a plan written in prose. It is small — six steps, not six hundred lines of generated code. It is typed — every arrow either matches a contract or fails before anything runs. And it is whole — the irreversible step, the approval that gates it and the compensation if approval is refused are visible together, before any of them happen.

Nothing moves until the score passes

A composition passes through a sequence of checks before it's allowed to run. Each is cheap, and each can send the score back to the composer with a reason.

Then, and only then, it plays — one controller at a time:

In the funding example, draft 1 fails at step 04. The vendor's licence edge is self-asserted:

04 ground  Vendor ─certified_for→ Electrical
           source vendor (self-asserted) · confidence low
           ✗ needs ≥ high, from a verified issuer
           → returned to composer

draft 2    + 0  RequestEvidence@c2f9
                from Vendor · wants licence credential
           ‖ hold until the edge verifies

Nothing was reserved, nobody was asked to approve anything, and no money moved. The composer revises the score to begin by asking for evidence, and the Being waits. It's the same outcome the context-graph note reached — reached at compose time, at no cost.

Judgement in the model, execution in code

This is the middle ground the procedural note found between free-form agents and workflow engines, applied to execution. The model still decides — which controllers, in what order, bound to which beliefs, with what fallback. What it no longer does is perform. Non-determinism is concentrated in one artefact, small enough to read, at one moment, before anything moves.

Not every step needs a controller. Work whose output is read by a person, or checked by the next step, can stay generative. The line is drawn at effects:

Character reads the whole score

Policy can check each step. Only something with a view of the whole can ask whether this is the right composition at all — and because the whole exists before it runs, the 4Cs can be applied to it rather than reconstructed afterwards.

Propose, don't improvise

Sometimes the library has a gap. An improvising agent fills it on the spot: write some code, run it, see what happens. A Being treats a missing controller the way the procedural note treats a graph mutation — as a proposal, not an action.

Drafting is a good use of a model, and the Being may well write the first version. What it can't do is promote its own draft. Review and release are signed by other identities, so a controller's provenance always includes someone other than the Being that wanted it. A new controller starts under a lower effect ceiling and earns more through use — the same provisional authority a Being steps down to when it changes engine.

Controllers change too, and their history is part of the record:

A revoked digest fails at Resolve in every composition that names it, immediately and everywhere. Compositions signed against an earlier release still say exactly which code they ran.

What each one answers

The companion notes ended with two graphs. Composition adds two more artefacts, and each changes at its own pace.

Each stays in its lane. A controller that embeds its own facts goes stale; one that embeds procedure becomes a workflow engine by another name. A context graph that encodes procedure becomes a brittle rules engine. Kept apart, the graphs can learn, the library can be reviewed, and the composition is the one place where they meet — and the one place a person needs to read to know what is about to happen.

From one tool call to one composition

The Octonomous lab runtime already has most of the shape. A Being handles each event through a fixed lifecycle:

In v1.0, decide asks cognition for a single action: a tool name and its input. govern checks whether this Being may call that tool — against its constitution, required approvals and delegated capabilities. act runs the handler registered under that name, and remember signs a receipt of what happened.

The governance is real and the receipts are signed. What isn't yet checked is the code. The tool registry is keyed by name, so a handler can change without anything noticing, and each tool's input schema is stored as metadata rather than checked when the handler runs. Composition fits the same lifecycle:

step       v1.0 today                 with composition
decide     { tool, input }            { steps, bindings, effects }
govern     may I call this tool?      resolve · type · ground ·
                                      authorise · 4Cs · approve
act        handler, by name           controller, by digest
                                      pre → run → post
remember   receipt of the event       receipt naming every digest

None of it needs a new runtime: a richer return type from decide, a stricter govern, a registry keyed by digest, and a receipt that names what actually ran.

This is buildable now

Like the context-graph note, this one doesn't depend on a new research result. Every part rests on infrastructure that already exists.

No new trust layer is required. Code already has digests and signatures; claims already have credentials. What's missing is a Being that composes from both, and declines to run anything it can't name.

What this note doesn't claim

A verified controller can still be wrong; tests catch what they test. A validated controller can still be misused. A well-formed composition can pursue the wrong intent, and a manipulated context graph can still bias which composition gets written. What this pattern changes is where errors can be caught, and who can see them — before the effect, by anyone who can read the score.

Octonomous is a framework for what a being is. Composition doesn't make code safe by itself, and none of this is a security appliance. Autonomy concentrates responsibility; composing makes it legible.

The composer answers for the score

Today's agents are performers — often gifted ones, improvising live, where every wrong note is heard. Octonomous asks something else of a Being: to compose. To know what it believes, and why. To know what it can do, and that the code it uses is the code it trusted. To write down what it intends before anything moves, have it checked, sign it, and let code that cannot improvise play it.

Curious checks every fact it binds to. Caring declares every effect. Constructive composes from what's been verified, and leaves the score behind. Chill writes the smallest score that works — and won't improvise a missing instrument.

Sources

• Octonomous (2026). An Open Framework for Self-Sovereign Intelligent Beings. octonomous.io/paper
• Octonomous (2026). From Procedural Graphs to Self-Sovereign Beings — field note. octonomous.io/procedural-graphs
• Octonomous (2026). From Knowledge Graphs to Verified Context — field note. octonomous.io/knowledge-graphs
• Octonomous (2026). From Decision AI to Accountable Beings — field note. octonomous.io/decision-ai
• Octonomous (2026). Lab runtime v1.0 — source. github.com/selfdriven-octo/octonomous
• Lu, Y., Chen, Y., Wu, S. & Arık, S. Ö. (2026). Procedural Graphs: Self-Evolving Execution Structures for LLM Agents. arXiv:2609.09153
• Smith, S. M. Key Event Receipt Infrastructure (KERI) and Authentic Chained Data Containers (ACDC). github.com/WebOfTrust/keri
• OpenSSF. SLSA — Supply-chain Levels for Software Artifacts. slsa.dev
• in-toto. A framework to secure the integrity of software supply chains. in-toto.io
• Sigstore. Software signing and transparency. sigstore.dev
• JSON Schema. json-schema.org
• WebAssembly. webassembly.org
• Model Context Protocol. modelcontextprotocol.io