Think about the last piece of software your company bought. However good it is, it shares one trait with every tool that came before it: someone has to operate it. Its output is capped by the hours a human spends with their hands on it. The shift underway now is not a better tool that makes that human faster — it's a change in who, or what, is operating the software at all. This is about what that feels like from the inside, and why it matters more than any feature.
The operator's tax
Every tool carries a hidden cost: it has to be operated. The CRM only reflects reality if someone keeps it current. The dashboard only informs if someone reads it. The analytics suite only produces an insight if an analyst goes looking for one. The copilot, for all its leverage, only helps when a human is sitting there to be helped.
The better the tool, the higher the leverage — but always on a present human. The real output of your software stack is bounded by the headcount you put in front of it and the hours those people are awake. We have accepted this so completely that we stopped counting it as a cost. It is simply what software is.
It is not what software has to be.
What self-operating actually means
This is not automation in the old sense, and the distinction is the whole point. Automation runs a sequence of steps a human specified in advance; it is fast and reliable and completely lost the moment reality does something the script didn't anticipate. A self-operating function exercises judgment — it works out what to do when the situation is novel, which in real operations is most of the time. Automation is a track. A self-operating function is a driver.
A week inside a self-operating function
The clearest way to feel the difference is to watch one run. None of the individual actions below is new — copilots can draft, automations can publish, dashboards can score. What's new is that nobody is driving.
- Marketing. The function plans the content calendar against the quarter's goals, drafts and publishes, watches what converts, and shifts effort toward what's working. On Thursday it notices a campaign underperforming badly enough to warrant a human call, assembles the context, and surfaces it with a recommendation.
- Customer success. Account health is scored continuously, not in a quarterly review. A churn signal lands on a Tuesday night; by the time the human opens their laptop Wednesday morning, the context is gathered, a response is drafted, and the one decision that needs them is waiting — not the forty that don't.
- Finance. Reconciliation happens as transactions arrive instead of in a month-end crunch. Anomalies are flagged the day they appear. The close package assembles itself over the month and arrives for sign-off instead of for assembly.
Read that back and notice what's absent: the person who normally drives each of these. The function is operating. The human is reviewing.
The new job is governing, not operating
If the system operates, what does the person do? They govern — and that is a different job, requiring a different skill.
Governing a function means setting its mandate (what it's for and what it's allowed to touch), setting its autonomy per decision (supervised where the stakes are high, autonomous where they're low and reversible), reviewing the trail of what it did, and making the genuinely hard calls that get escalated upward. This is the work of a manager, not an operator. The scarce skill stops being "can you run the tool" and becomes "can you set a good objective and a good boundary."
That is not a smaller job. It is a higher one. And it's the same move every prior wave of automation made — people moved up from performing the work to directing it — happening one level higher than it ever has before. A self-operating company is not a company without people. It is a company where the people work at the altitude of direction and judgment, and the software works at the altitude of execution: continuously, accountably, inside the lines they drew.
Why this couldn't happen until now
Two things had to become true at the same time, and neither is sufficient alone.
The reasoning had to get good enough that a function run by software is run competently — that a drafted response is a good response, that a flagged anomaly is a real one. That is the part frontier models brought. But a capable model with no structure around it is not a self-operating function; it is a liability with API access. The second thing that had to exist is a structure disciplined enough to let that reasoning act without a human checking every step — authority, memory, coordination, and hard boundaries enforced in code.
Harnyss is that structure, built on Claude for the reasoning. Agents run inside defined mandates, with approval gates where you want them and a full record of every action. The model supplies the judgment; the harness makes the judgment safe to act on. A brilliant model with no rails is a liability, and perfect rails around a weak model are an expensive way to do nothing. You need both at once, which is precisely why this is happening now and not five years ago.
What changes
The question a company asks about a function used to be "how many people do we need to run this." For a self-operating function, the question becomes "what do we want this to do, and where do we want to keep our hands on the wheel." Headcount stops being the lever for output. Direction does.
That is a larger change than it first appears, because it doesn't just make the function cheaper to run — it changes what a small company can attempt. A function that no longer scales with headcount is a function a five-person company can run at the depth that used to require fifty.
This is one of three pieces on that shift. The companion essays make the broader case that this is a new category of software, and look at what happens when the org chart itself becomes software.