Systems and levels
Table of Contents
1. Summary
A regulator presented with more variety than it can use stops regulating. This page holds the framework's answer to that: a session declares the System it acts as, and that declaration attenuates the catalogue to the portion in scope for the work.
Attenuation comes in two strengths, and the difference decides what the framework may claim. An advisory default is convenience and regulates nothing, since an agent may disregard it without consequence. A binding constraint regulates, because it holds whether or not the agent would prefer otherwise. One row of the table below binds; the rest are ergonomics, and are named as such (The Cybernetic Skills Framework).
This document states the actor vocabulary, the System a session or delegate acts as, what each level sees, and the boundary a read-only System cannot cross. For how an agent is configured, isolated and left to run, see Running agents.
2. Detail
2.1. Terminology of Actors
Everyone says "agent", and it is overloaded three ways in this project. The ladder, from general to specific:
| Word | Means |
|---|---|
| Agent | Any LLM process doing work. The general word; use it when the distinction does not matter |
| Session | The agent a human is talking to. It has a conversation and an operator |
| Delegate | An agent spawned by another agent to do a bounded piece of work and report back. It has no operator, only a brief |
| System | The role either one acts as. Not a process at all |
A delegate is what the harness and most other tooling call a subagent. We say delegate because the relationship is what matters here — it was given a brief by something that stays responsible for the result — and because "sub" implies a hierarchy of importance rather than of scope. Read the two as synonyms when reading anyone else's documentation.
The trap worth naming: the S1 level is called "Agent", and it is a System, not a process. "The S1 Agent" is a role a session or a delegate adopts, in the same way "S3* Auditor" is. When it matters, write "a session operating at S1" rather than "the S1 agent".
The owning rule: a session owns its delegates' work. A delegate's summary of what it did is not evidence; the artefact it produced is. Review the diff, not the report.
2.2. The Level Attenuates the Catalogue
A session declares its System once, at the start. That sets the cybernetic level, and the level selects the slice of the catalogue in scope by default.
| Level | System | Horizon | Sees |
|---|---|---|---|
| S1 | Agent | Hours | Execution in full, sequencing, citation, declaration |
| S2 | Orchestrator | Days | Story and task actions, decomposition methods, deliberation |
| S3 | Sprint Planner | Weeks | Sprint and backlog actions, planning and review methods |
| S3* | Auditor | Continuous | Read-only and audit actions only |
| S4 | Version Planner | Months | Version and release actions, strategy deliberation |
| S5 | Identity Steward | Indefinite | Identity and backlog-fit actions, deliberation |
Attenuation has two strengths, and they must not be confused.
- Advisory, for S1, S2, S3, S4 and S5. Default visibility only. Nothing is forbidden and an agent may reach outside its level by saying so. The point is ergonomics: a default small enough to choose from well.
- Binding, for S3*. The auditor may not mutate a work item. An audit channel that can be talked into editing what it observes is not an audit channel. This row is enforced.
Constraint flows down and signal flows up, unchanged from the levels model: a method at S1 inherits the story goal from S2, which inherited the sprint mission from S3; a task result becomes a story result becomes a sprint retrospective.
2.3. Systems Adopted by Delegates
The levels above are Systems a session acts as. The same artefact serves a second purpose: a System is also what a delegate acts as when a session spawns one.
This matters because delegation is where discipline is most easily lost. A session that has declared its System, loaded the principles and copied a method's phases in can hand work to a delegate that has done none of those things, and the delegate will produce something plausible that satisfies none of the gates. The fix is structural: a delegate is spawned as a named System, never as a generic agent. If a spawn names no System, the discipline stops at the boundary.
A System definition therefore states what the delegate must read before it begins, and what it may do.
2.3.1. Read-only Systems
The advisory-versus-binding distinction that separates S3* from the other levels applies to delegates too, and here it is easier to enforce.
A reviewing System is unable to write, not asked not to. A comment reviewer touches comments and names refactor targets; it never writes application code. An auditor reports; it never mutates the thing it observes. Stating the boundary in the System definition and enforcing it at spawn time is worth more than any instruction inside the prompt, because a delegate under pressure to finish will reinterpret an instruction and cannot reinterpret a capability it does not have.
The enforcement is what is on disk when the delegate starts. Pruning the deployed catalogue to a level removes every out-of-scope skill from it, so an agent spawned afterwards cannot load one:
python3 build/scripts/apply_skill_levels.py --prune-deployed s3star
An auditor spawned into that tree sees five skills, all of them read-only.
Rebuilding the bundle restores the full set. Read-only is derived from the
verb register rather than declared per skill, which is one of the reasons
the register exists: show- and find- promise to change nothing, and the
promise is now load-bearing.
2.3.2. Structural Findings
A read-only System that cannot change the code is not thereby limited to complaining. It can name the structural change that would remove the problem, and that naming is often the more valuable output.
The pattern worth generalising: when a reviewer finds prose explaining a surprise in our own code, the prose is the symptom. The comment goes, and the reviewer flags the exact symbol for the rename, extraction, retype or rearchitecture that would make the behaviour obvious without prose. Only surprises forced by something outside our control — a platform, a vendor, a protocol we cannot reshape — earn a comment instead of a fix.
That is encode-lessons-in-structure made operational
(The pstack Collection): a finding
that ends in a structural flag outlives a finding that ends in a deletion.
2.4. Inventory
What each System sees by default, counted from the levels the skills carry. Attenuation is advisory everywhere except the audit channel, where it is binding and enforced by what is deployed.
| Level | System | Horizon | Sees | Attenuation |
|---|---|---|---|---|
s1 |
Agent | Hours | 64 skills | advisory |
s2 |
Orchestrator | Days | 19 skills | advisory |
s3 |
Sprint Planner | Weeks | 21 skills | advisory |
s3star |
Auditor | Continuous | 5 skills | binding |
s4 |
Version Planner | Months | 16 skills | advisory |
s5 |
Identity Steward | Indefinite | 16 skills | advisory |
15 skills are tagged cross and appear in every advisory slice: the documents and the skills themselves, and the orientation any System starts from.
3. See also
- The Cybernetic Skills Framework — why attenuation is structural, and when a constraint may be called regulation.
- Skill architecture — the index into the cluster this page belongs to.
- Cybernetic Levels — the five Systems and this project's departures from them.
- Systems — the priming context each System loads.
- Running agents — how a delegate is configured and bounded at spawn.