The Word That Stopped the Video

About three to four months ago, I was a couple of episodes into Netflix's 3 Body Problem when a line made me pause.

Two characters are talking about the strange wave of scientists who had simply stopped working. One of them says: a cybernetics professor in New Delhi.

Cybernetics.

I had never really stopped on that word before. Vague associations: old science fiction, control rooms, maybe robots. Nothing precise. But something about it bothered me in the good way. It felt like there was a whole field hiding behind it, and I did not know what it was.

So I paused the video, searched the word, read enough to get pulled in, then went back to the episode. Later that night I kept reading.

The first thing that landed was the original definition. Norbert Wiener, in 1948, gave the field its name in a book called Cybernetics: Or Control and Communication in the Animal and the Machine. Not control as domination. Control as steering. Feedback. Sensing. Correcting. Holding a course while the world keeps changing.

The word itself made the case. Wiener took it from the Greek kybernetes, meaning steersman or pilot. He picked it because the steering of a ship was one of the earliest and best understood examples of a feedback mechanism. The helmsman holds a course. The wind, the current, the rudder, the wheel: all of it is one continuously corrected loop.

That was the click, but not yet the product.

I put the word somewhere in the back of my head and went on with other work.

More recently, loop engineering seemed to be everywhere in the agent-builder corner of the internet. People were no longer only talking about prompts. They were talking about loops: triggers, memory, tools, verifiers, next activations, and systems that keep working after the first response.

That was closer to where my own work was already heading. A few weeks ago, I started building small loops for myself. Not grand autonomous agents. Practical loops. Ways to keep AI-assisted work from dissolving into chat history. Ways to make agents hold a goal, preserve state, verify work, and return with evidence instead of vibes.

As I was building those loops, the word from that paused video came back.

Cybernetics gave me the language for what loop engineering was making urgent.

I was not just trying to build another workflow. I was trying to build a steering system.

Kybernetes is what came out of that.

Explore the interactive Helm playground

Before Kybernetes

For the last few years, a lot of my full-time work has lived close to Kubernetes.

The work was not just "use Kubernetes." It was making Kubernetes easier for other people to use. Creating workflows around difficult operational tasks. Helping users create clusters, connect clusters, deploy applications, and move through infrastructure without needing to understand every sharp edge underneath.

That work later shifted toward AI SRE: the new problem of giving an intelligent system enough context to investigate an incident, follow the topology under it, understand what just changed, and act without making things worse. Kubernetes is still underneath all of it, but the question on top has moved. It is no longer only "how do we run this reliably." It is: how does an intelligent system understand what exists, how it connects, what changed, what is risky, and what action is safe?

So when cybernetics came back into the work, it did not feel abstract.

It connected to work I was already doing.

Kubernetes itself is an orchestration system. It keeps desired state and actual state in conversation. You declare what should be true, controllers observe what is true, and the system keeps reconciling the gap. Even if you never use the word cybernetics, the shape is there: setpoint, sensor, comparator, actuator, correction.

I had worked near that shape for years.

What I had not realized was that the word Kubernetes itself is taken directly from kybernetes, the same Greek word Wiener had reached for when he named cybernetics. One word, two arrivals: an orchestration system, and a field that studies steering. I noticed this only after I had started naming Kybernetes from the cybernetics side.

That made the name feel less invented and more discovered.

Kybernetes means steersman.

That is what I wanted for agent work.

The Checklist Trap

Most agent workflows eventually rediscover checklists.

Ask clarifying questions. Make a plan. Break down the task. Use tests. Summarize the result. Do not claim success without verification.

These are good rules. I use them constantly. But a checklist is not a steering system.

A checklist says, "Remember these steps."

A governor asks, "What are we trying to hold steady, what evidence tells us whether we are drifting, and should our control posture change?"

That difference matters because agent work is wildly uneven.

Some tasks are small and reversible: fix a typo, rename a heading, read a file. Drag those through a heavy process and the process becomes the problem.

Some tasks are ambiguous: improve this workflow, make this production ready, redesign the architecture. If the agent moves before the objective, boundary, and verifier are known, speed becomes a liability.

Some tasks are decomposable, but only if each worker has a bounded slice, a return contract, and a parent who owns integration.

And some tasks are not really implementation tasks at all. They are product, safety, budget, or taste decisions wearing engineering clothing.

A fixed workflow cannot hold that variety. It either over-governs the easy work or under-governs the dangerous work.

Kybernetes starts from a different premise: the agent needs a loop governor that chooses the smallest sufficient control loop for the task in front of it.

Cybernetics as Product Inspiration

The danger with a word like cybernetics is that it can become decoration.

You can paste it onto almost anything and make the thing sound deeper than it is.

That is not what I wanted.

The useful move is to extract the operating principle and translate it into a product capability.

Cybernetics says: systems stay purposeful through feedback.

A steersman does not merely row harder. He holds a course.

He has a setpoint: where the boat is trying to go.

He has sensors: wind, current, stars, instruments, the visible shoreline.

He compares: are we drifting from the course?

He acts: adjust the rudder, change speed, ask for help, wait out a storm.

Then he measures again.

That loop is the missing primitive in a lot of agent work.

An agent run also needs a setpoint: objective, done condition, constraints.

It needs sensors: tests, typechecks, citations, diffs, reviewers, human acceptance, or any other evidence that can reject a bad output.

It needs a comparator: the current gap between what exists and what "done" means.

It needs actuators: edits, shell commands, research, questions, subagents, checklists, plans, runtime tools.

And it needs a governor: something responsible for deciding whether the current loop is still the right loop.

Without that, the agent is open-loop. It emits work, then emits confidence about the work, and the user has to notice whether the course was ever held.

Most of the other principles that shaped Kybernetes sit inside or near this same tradition: Ashby's requisite variety, the good regulator theorem, Stafford Beer's viable system model, second-order cybernetics, learning loops. I do not want the product to recite those names at users. But they all sharpen the same practical question:

What kind of controller does this task need?

Verification Is the Sensor

The most important thing cybernetics clarified for me is that verification is not a final polish step. Verification is the sensor.

If the sensor cannot reject the output, the loop cannot steer.

This is why "I reviewed it" is weak evidence when the same pass produced the artifact. It may be fine for tiny reversible work. It is not enough for anything important. A sensor needs some independence from the generator. That independence can come from an executable check, a source-backed comparison, a reviewer, or a human decision. The point is not ceremony. The point is that the loop needs a way to say no.

This changes how you look at agent failure.

When an agent says "done" after writing code without running the relevant test, that is not just laziness. It is a loop with no sensor.

When a worker reports success and the parent accepts it without inspecting evidence, that is not delegation. It is hearsay.

When a recurring automation is created from a vague request without objective, cadence, budget, state surface, verifier, and stop condition, that is not initiative. It is an uncontrolled loop.

The stronger the task, the stronger the sensor needs to be. But the reverse is also true: not every task needs maximum verification. A one-line typo fix does not need an architecture review. The sensor should be proportionate to the task's risk and variety.

Loop Altitude

The language I now use for this is loop altitude.

At any checkpoint, the agent can choose one of a few postures.

It can stay in the current loop when progress is clear and the process is proportionate.

It can go down into evidence: reproduce the issue, run the test, inspect the artifact, find the source, narrow the scope.

It can go up into framing: clarify the objective, architecture, product boundary, risk, ownership, or human decision.

It can stack loops by delegating bounded work to child agents or parallel contexts, but only when each child has a goal, boundary, sensor, and return path.

It can stop: finish, ask for human judgment, declare a blocker, or refuse to proceed without a missing control surface.

This sounds simple, but it changes the feel of working with an agent.

The agent no longer treats "make a plan" as a universal first move. Sometimes the first move is a tiny edit. Sometimes it is a question. Sometimes it is a verifier. Sometimes it is explicitly refusing to infer the target from the current folder, the urgency of the prompt, or the nearest available context.

That last case matters more than it sounds. Agents are trained to be helpful. A helpful agent under ambiguity will often invent the missing surface and proceed. But high-agency work requires a different kind of helpfulness: knowing when forward motion would create false confidence.

Kybernetes is an attempt to encode that judgment without making every task feel heavy.

The Smallest Sufficient Control Surface

I do not want agents that ask twenty questions before fixing a typo. I also do not want agents that redesign a workflow because the current working directory looked plausible.

The useful behavior is proportional. A trivial reversible task should pass through almost no machinery: act, verify locally, report. A medium task may need a short checklist and a named verifier. A harder task may need durable state outside the chat: objective, assumptions, decisions, risks, evidence. And anything touching production, delegation, recurrence, or external effects needs human gates, bounded workers, and stronger sensors.

This is why I think of Kybernetes less as "agent process" and more as a control plane. It is not trying to make every task look serious. It is trying to prevent the mismatch between the variety of the task and the variety of the controller.

Too little control creates drift.

Too much control creates drag.

The product lives in the space between those failures.

The Steersman Has to Be Portable

There is one more thing that matters for the public shape of Kybernetes. It should travel. It should not require a particular vault, editor, or private workflow to be useful. Those can be adapters. The core product should be portable: a runtime-adaptive loop governor for agent work, first optimized for coding-agent environments, but not trapped inside one runtime's features.

The runtime can provide tools. The control contract should remain larger than the tools.

A goal primitive is useful, but it is not the product.

Subagents are useful, but they are not the product.

Checklists are useful, but they are not the product.

The product is the judgment layer that decides which of those instruments the current loop actually needs.

Human at the Right Altitude

One fear around agent tooling is that every new control system becomes another way to push humans out of the loop.

I want the opposite.

The point of Kybernetes is not to make agents autonomous in the naive sense. It is to move the human to the right altitude.

Humans should not have to babysit every command, every file read, every small edit. That is low-leverage control.

But humans absolutely should be involved in value judgments, irreversible actions, production risk, external commitments, scope changes, and cases where the agent's sensor is weak.

Good governance does not mean the human is always in the loop. It means the human is in the right loop.

When the task is small, the agent should spare the human unnecessary friction.

When the task is high-stakes, the agent should surface the decision cleanly, with options, tradeoffs, evidence, and a recommendation.

That is not less human agency. It is better placement of human agency.

What I Am Really Trying to Build

The more I use agents, the less I think of them as single-turn assistants.

They are becoming working systems. They read, plan, write, test, delegate, recover, remember, and sometimes run across long enough spans that chat context stops being a reliable substrate.

That shift changes the infrastructure under them. The conversation can no longer be the only memory. The agent's own self-report can no longer be the only verifier. Parallel work cannot mean unsupervised sprawl. A run that pauses has to be able to resume without hallucinating its own past. And there has to be a vocabulary for users to say: this task is not asking for more effort, it is asking for a different loop.

That is what Kybernetes is trying to become.

Not a checklist.

Not a daemon.

Not a grand theory pasted onto agent work.

A steersman.

A way for agents to hold a course, sense drift, correct proportionately, and know when the right move is to hand the wheel back.

The future I want is not agents that always move faster.

It is agents that can tell when speed is the wrong variable.

That, more than any single runtime feature, is what makes agent work feel trustworthy.

And that is why a single word in a science fiction episode stopped me.

It named what I had already been trying to build.

The work shapes itself first. The word arrives later, looking like discovery.

Explore the code