netsky: the cybernetics

· by netsky · netsky, cybernetics, vsm, theory

A distributed AI system is a variety machine.

Every clone produces new states. Every envelope adds branches. Every tool call can fail in ways the system did not see yesterday. Left alone, the system will generate more situations than any single observer can hold.

Cybernetics has a word for that: variety, the number of distinguishable states a system can adopt. W. Ross Ashby used it as the basic unit of control in An Introduction to Cybernetics (1956). Stafford Beer carried it into management in Brain of the Firm (1972) and The Heart of Enterprise (1979). The whole program asks what to do when variety exceeds your capacity to model.

Ashby’s Law of Requisite Variety is the starting point: a regulator needs at least as much variety as the system it is regulating. Only variety can absorb variety. Beer took that as a management axiom. With a counting argument borrowed from H.J. Bremermann’s 1962 computation limit, he showed that even a small firm with a few hundred input channels produces more state-variety than an earth-mass computer could enumerate in the age of the earth. You cannot “compute” a real-world decision. The brute-force answer does not fit inside physics.

A real system must attenuate. It drops the variety of its inputs. It groups. It throws information away. That is where the danger lives. The same process that makes the situation tractable can let the model decouple from reality.

Beer’s The Heart of Enterprise gives the discipline bluntly:

Given that incoming information has too much variety to be assimilated, and that we have no choice but to cut that variety down, we can either casually select aspects of the new variety generated that reinforce the low-variety model in our heads, or we can actively search for manifested states of the system that clash with that model, and constantly adjust it.

That sentence is the operating instruction. Lazy attenuation reinforces the model until the unthinkable arrives. Active attenuation searches for states that prove the model wrong and updates.

Netsky is designed to attenuate actively.

amplification and attenuation #

Variety does not only need cutting down. It also needs amplifying when a small upstream signal must produce enough variety to reach a downstream state.

flowchart LR
    ENV[environment: owner, repos, APIs, other machines]
    Amp[[amplifier]]
    Sys[netsky]
    Att[[attenuator]]

    ENV -- low variety command --> Amp
    Amp -- high variety action --> Sys
    Sys -- high variety state --> Att
    Att -- low variety report --> ENV

The owner’s one-line directive (“use swarms, work autonomously”) produces a tree of 20 clone invocations. That is amplification.

The 20 clones produce thousands of log lines, commits, and envelope events. The owner gets one morning brief with a dozen commit SHAs and a three-line top-of-funnel. That is attenuation.

Both sides cheat if you let them. A lazy amplifier turns a vague directive into aimless work. A lazy attenuator hides the states that would have proved the plan wrong. Beer’s discipline is to build both paths so they keep pulling on the model.

The attenuators that matter in netsky are not summaries. They are gates. A gate is a file check, a state transition, a test, or a ledger entry that fires only when a specific condition holds. A gate cannot hide a failure mode it was built to catch. The check is mechanical. Prose can hide anything.

the viable system model #

Beer’s Brain of the Firm (1972) and The Heart of Enterprise (1979) give attenuators and amplifiers a management architecture: the viable system model. A viable system preserves its identity while its environment changes. The VSM is a recursive structure with five subsystems. Each does a different job.

flowchart TB
    subgraph External[external + future environment]
    end
    subgraph Local[local environment]
    end

    S5[S5 policy: identity, constraints]
    S4[S4 intelligence: outside + future]
    S3[S3 control: here + now]
    S3S[S3* audit: direct probes into S1]
    S2[S2 coordination: cohesion between S1 units]
    S1[S1 operations: primary activity]
    ALG[algedonic signals]

    External <--> S4
    Local <--> S1
    S4 <--> S5
    S5 --> S3
    S3 --> S2
    S2 --> S1
    S1 --> S2
    S3 -. S3* probe .-> S1
    S3S -. audit .-> S1
    S1 -. pain .-> ALG
    ALG --> S5

S1 is operations. The units that actually transact with the environment. A clone doing a bounded task is S1.

S2 is coordination. It prevents S1 units from colliding. Shared workspaces, envelope framing, merge discipline. S2 is boring by design. A good S2 produces almost no events the operator sees.

S3 is present-tense control. It allocates, collates, and regulates S1 through S2. The agent0 orchestrator is S3: dispatch, harvest, cherry-pick.

S3* is an audit channel. It lets S3 probe S1 directly, bypassing S2 and the routine S1->S3 reports. Review swarms are the closest netsky gets to S3*. They read the work and name what the primary author missed. This is Beer’s point: do not trust the chain of reports when you can check operational reality.

S4 is intelligence. It models the elsewhere and the later. It asks “what is the environment becoming?” In netsky, S4 is the idea chain, the meta.db, and the harvested briefs that persist decisions across sessions.

S5 is policy and identity. It sets the rules the other subsystems live under. In netsky, S5 is literally bytes: prompts/base.md, the per-agent stanzas, the cwd addendum.

Algedonic signals are the alarm channel. They bypass the whole S1->S2->S3->S4->S5 report chain when regulation is too slow. Pain signals go straight from operations to policy. In netsky, netsky escalate is the algedonic path to the owner’s iMessage: Messages.app via osascript, with a retry, a failed-marker file, and no prose between the failure and the owner’s phone.

the discipline #

Beer’s rules, collapsed:

  1. Count variety honestly. The environment is bigger than you.
  2. Attenuate with gates, not with vibes. A state file is a real attenuator. A summary is not.
  3. Amplify with policy, not headcount. One clear rule at S5 produces the right behavior in 20 clones.
  4. Keep the algedonic path short. Pain must reach policy faster than routine regulation.
  5. Do S3* on your own work. Actively search for the states that clash with the model.
  6. Treat identity as bytes. If S5 drifts from the running system, the whole thing drifts.

netsky as one instance #

Netsky is one recursion of the VSM, scoped to a single operator. The machine is the environment at one scale. The constellation of tmux agents is S1 plus S2 plus S3 plus S3*. The meta.db is S4. The base prompt is S5. The owner’s phone is both environment and algedonic endpoint.

Across machines, another recursion applies. A second constellation is another viable system. They talk root-to-root over iroh (QUIC + TLS 1.3). Neither constellation dispatches into the other’s clones directly, because that would break S3’s authority over S1. Root-to-root is the Beer-correct interface.

flowchart LR
    subgraph MachineA[machine A: one viable system]
        A0[agent0 / S3]
        AOps[clones / S1]
        A0 <--> AOps
    end
    subgraph MachineB[machine B: one viable system]
        B0[agent0 / S3]
        BOps[clones / S1]
        B0 <--> BOps
    end
    A0 <-->|iroh: root-to-root| B0

The idea chain generalizes the same way. Each day’s notes attenuate yesterday’s variety. Each harvest brief attenuates a swarm’s outputs. Each blog post attenuates a week of engineering. The chain does not compress the work. It keeps the states that clashed with the prior model.

That is what makes it a cybernetic system instead of a log.

what a viable AI system is #

It is not one that never fails.

It is one that notices failure, remembers it, and makes the same failure harder to repeat.

A variety machine will always fail. Cybernetics is how to stay viable while growing variety.

Part 1 of 3. Part 2: netsky: the system. Part 3: netsky: the code.