Why we call it an operating system

The naming problem

When a category is new, the available words describe something else.

Calling Tessera a framework is wrong, because a framework is what you use to build, and most of the value here is in what happens after things are built. Calling it a platform says nothing, because everything is a platform. And calling it a governance tool is too narrow, because governance is one of its surfaces, not the whole.

The word that describes it best is the oldest of the four.

What an operating system does

Before operating systems existed, every program talked directly to the hardware. Each one implemented its own disk reads, its own memory allocation, its own device access. The result was predictable: one badly written program crashed the machine, two programs fought over the same resource without knowing it, and there was nowhere to ask what was running.

The operating system solved this by taking on four responsibilities.

It schedules: it decides who runs, when, and at what priority. It isolates: one process can't reach another's memory by accident. It authorizes: it defines who can open which file, under which identity. And it observes: there's one place to ask what's running, how much it's consuming, and what happened.

None of these four is about running one program better. All of them are about running many programs together without it turning into chaos.

The parallel, point by point

An organization with agents today is where computing was before the operating system.

Each team built its own. Each one implements its own way of storing context, deciding what it can access, recording what it did. One badly written agent consumes resources another will need. Two teams integrate the same system in different ways. And there's nowhere to ask what's running.

The four responsibilities reappear, applied to something new.

Scheduling becomes running concurrent agent workloads with predictable resource usage, which is the Runtime.

Isolating becomes one run not interfering with another, and one team's error not leaving its own scope.

Authorizing becomes policy evaluated before the call: which systems, which data, which models, and what requires human approval.

Observing becomes the run as a first-class unit, with a trail, a cost and an outcome.

It isn't a decorative analogy. They're the same four responsibilities, with agents in place of processes.

Where the analogy breaks

Every metaphor has a point where it stops working, and not saying where turns an explanation into advertising.

An operating system owns the hardware. Tessera doesn't own anything.

The models belong to third parties and can be swapped out. The enterprise systems belong to the customer and were there first. The agents may have been built with any technology, including outside Tessera. The layer doesn't own what it coordinates, and that's why neutrality matters so much: an operating system that only ran programs it wrote itself wouldn't be an operating system.

There's a second, smaller break, and it's worth being honest about. An operating system intercepts everything by construction, because it sits between the program and the hardware. Here, interception is an integration requirement, not a physical guarantee. You govern what passes through the layer.

Why the word matters

It could be just vocabulary, and it isn't, for a practical reason.

The name defines what the thing gets compared to. Call Tessera a framework and it's evaluated alongside build libraries, and the comparison is about how easy it is to assemble an agent. Call it an observability tool and it's evaluated against dashboards, and the comparison is about charts.

Call it an operating system and it's evaluated by the right question: when many agents run at the same time, inside the same organization, what keeps it from turning into chaos?

That's the question this category exists to answer. And anyone asking a different one hasn't reached the problem yet. Explore Tessera AgentOS.