---
title: "Railblocks ⬩ Why your company needs an Operating System"
description: "The missing Operating System standing between AI and the rest of work"
url: "https://www.railblocks.com/blog/why-your-company-needs-an-operating-system/"
---

Essay 2026.09.08 ⬩ 11 min

# Why your company needs an Operating System

Figure: An operating system as four layers stacked and joined by pegs

Lorenzo Castro Co-founder

I have always sat somewhere between engineering and operations.

I started my career as an operator, but I was always drawn to tools. I signed up for every beta I could find. I tried to build everything I could with no-code tools. But the more I built, the more I ran into the same limits: a workflow I could not build exactly as I wanted, data I could not access, an interface I could not customize, an edge case the tool had never anticipated.

That frustration pushed me to learn how to code.

I became an engineer and, as an engineer, my life completely changed with the arrival of AI. Agents now drive much of my execution. They explore codebases, write code, run tests and fix errors. My role has shifted from producing every line myself to orchestrating the work.

My life as an operator, on the other hand, has barely moved. I still spend a lot of my time on coordination, communication and data entry. Living across both sides, the contrast is hard to ignore: I can watch an agent refactor a codebase in the morning, then spend the afternoon carrying context between tools by hand.

That contrast led me to the question I can’t let go of:

Why hasn’t operational work (i.e. sales, marketing, finance, HR) gone through the same transformation yet? What is the nature of the gap?

Models aren’t the problem, everything around them is.

## 1. Technical vs. operational work

First, let’s take a look at how coding has been transformed by AI.

The first thing to notice is that it did not happen overnight. It was a process and we’re still going through it. I’ve counted 5 stages:

1. **Autocomplete:** AI suggests the next few words or lines while the engineer is writing. The human still does the work, but moves faster.
2. **Chat:** The engineer asks AI questions in a separate window. AI can explain code or generate a solution, but the human still has to connect the answer back to the project.
3. **Agents:** AI can use coding tools more directly. Instead of asking for one answer at a time, the human gives the agent a goal and the agent takes several steps to complete it.
4. **Cloud agents [📍we’re here]:** The agent no longer needs to live inside the old coding interface. It gets its own workspace in the cloud, where it can operate end‑to‑end and come back with finished work.
5. **Self-building products:** AI starts deciding what should be built, not only how to build it. It can plan improvements, make changes, test them and manage parts of the product on its own.

This transformation is not completely finished, but it’s close. We are somewhere around the fourth stage, with the fifth beginning to come into view.

Even though it took a bit of time to get there, coding has (almost surprisingly) been the first job to be fully transformed by AI because it already had an “Operating System” for AI to plug into.

Software either works or it does not, and every change is recorded somewhere. Engineers work inside a relatively unified environment: an IDE, a repo, containers, tests and deployment systems.

Software engineering benefits from decades of infrastructure built to make work legible and delegable. Repositories provide simple, version-controlled workspaces where every change can be inspected and reversed. Types & tests create high-quality automated feedback loops. Documentation is freely available and searchable on the web. And engineering teams have a long history of systematizing work through specs, tickets, sprints and code review.

The environment does not solve every problem. But it gives the agent a place to work, a body of context to work from and multiple ways to tell whether it is making progress.

Operational work is very far from this. It is performed across tools stitched together over time with glue. Some tools are so old, closed or poorly designed that agents can barely access them. Other ones are accessible, but contain only one partial version of reality. Context is scattered across documents, conversations and people’s heads.

The work is also harder to measure: it is not bits moving through a deterministic system. It is humans. Success is often contextual (or even relational & political) rather than objective. A decision can be technically correct and still be wrong for the team, the customer or the moment.

The issue is not that agents are inherently incapable of doing this work. The issue is that they have no equivalent environment in which to do it.

## 2. The Frankenstein stack

To understand why, we need to step back and look at how operational work has been structured over the past few decades.

Operational work is not performed in a collaborative, shared and traceable environment like an IDE & a repository. It is performed inside SaaS tools.

The way operational work got structured inside companies was not designed from first principles. It emerged gradually, as a consequence of how the SaaS industry developed. And it tends to happen the same way, in the same order, in almost every company.

### a. Silos

Figure: Three tools as separate vertical silos, HubSpot, QuickBooks and Asana, each with its own UI, logic and data layer.

As a company begins its adventure, each team chooses the tool that best addresses its immediate needs. Marketing buys HubSpot. Finance gets QuickBooks. Support lands in Zendesk. People pick the tools they know, because they don’t know how to do the work without them.

Each tool becomes a vertical silo with its own data, its own logic and its own interface: a row of self-contained blocks, each holding its own version of the truth, none of them aware of the others. Some companies end up with hundreds of tools spread across the organization.

### b. Glue

Figure: The same three silos, their data layers joined by a native integration between HubSpot and QuickBooks and by Zapier between QuickBooks and Asana.

But companies are not made of isolated departments. The work has to flow between teams. Finance needs data from sales. HR needs data from finance. Sales needs to know what is happening in support.

Companies tried to connect those blocks in two ways:

1. **Native integrations** built by the tools themselves. These are often easy to set up initially, but they are designed for the lowest common denominator. As soon as the company’s workflows become more specific, the integration reaches its limits, and there’s no way around them.
2. **Automation tools** such as Zapier, Make and n8n. They provide more flexibility, but every new automation creates another dependency to configure, monitor and maintain.

The result is not a unified system. It is a collection of poorly glued blocks that were never designed to work together.

### c. Data extraction

Figure: The glued silos with ETL pipelines copying the data of each tool into Snowflake and Tableau below them.

Even when data flows between tools, nobody fully trusts the picture.

To fix that problem, companies build a data layer on top to create an artificial source of truth. Data is siphoned out of the tools through ETL pipelines, copied into a warehouse and exposed through BI tools: a read-only reconstruction of what the systems underneath are actually doing.

That is the Frankenstein stack: vertical tools, stitched together by integrations and automations, with a data warehouse built on top to reconstruct what is happening underneath. A body assembled from parts that were never meant to form one organism.

No company sat down and deliberately designed this as the best possible way to structure its tools, data, operations, and therefore, work.

It emerged from the strengths and constraints of the SaaS model. SaaS companies were incentivized to own a verticazl, build a moat and expand into adjacent categories. Businesses were incentivized to buy the best tool for each team and connect the pieces later.

That suboptimal structure was already barely tolerable when the goal was simply to help humans use software. It becomes a serious limitation when the goal is to have agents understand and execute work across the company.

An agent cannot reliably operate a company if the company itself has no coherent environment in which work takes place.

## 3. Single-player vs. multiplayer

The reason why agents need an environment for operational work is because this work is multiplayer: efforts need to be coordinated both between teams and between people.

Building one functional agent is relatively easy for one (motivated) person. Building a fleet of agents that works safely and reliably across an entire team or company is a different problem altogether.

One person can supply the context, connect the tools, explain the exceptions and review the result. They notice when something looks wrong. They approve consequential actions. When the agent gets stuck, they help it find its way again.

In that situation, we could almost say that the human is the system. Building one functional agent is relatively easy for one (motivated) person. The missing infrastructure is being supplied manually.

Once multiple people and multiple agents need to work together, those contributions have to become part of a shared system. There’s just no other choice. The context cannot live only in one person’s head. The permissions cannot be improvised each time. The work cannot depend on one AI champion watching every step.

For agents to operate as part of a multiplayer environment, they need at least three things:

### a. Context - the ability to know

An agent needs to know what is true for this company, this team, this person and this task. That includes live data from systems of record, organizational memory, internal terminology, operating instructions and the history of the work so far.

It also has to be unified. If each employee has to recreate their own version of the company’s context, agents will make inconsistent decisions and this will lead to unreliable outputs.

A company needs centralized context that is not only available, but up-to-date, relevant and accessible at the right level of permission.

### b. Agency - the ability to act

An agent needs to know what it can do and what it cannot do.

Broad access without meaningful boundaries is dangerous. An agent may read something it should not see, change the wrong record or confidently complete an action on behalf of the wrong person.

The goal is useful agency: enough freedom to get meaningful work done, within guardrails the company can understand and trust. Those guardrails include permissions, roles, sandboxes, review flows and clear ownership.

These constraints are not the opposite of agency. They are the conditions that allow agency to scale.

### c. Continuity - the ability to finish

A model does not naturally remember that it asked someone a question yesterday, that a decision is still waiting for approval or that a consequential action has already been completed. The system has to provide that continuity.

It needs to survive interruptions, wait for human decisions and resume when the answer arrives. It needs to be able to know when it canretry safely and when it should avoid taking the same consequential action twice.

Most importantly, it needs to carry work through to an outcome. Not just an answer.

## 4. The Operating System

Figure: The Operating System as four stacked layers. Interfaces: a single control panel alongside purpose-built, ephemeral and malleable interfaces. Logic: LLMs for decision-making and code for execution. Knowledge: a self-refining knowledge graph for facts and decisions. Records: centralized storage for raw data, traces and events.

The Frankenstein stack and the multiplayer problem point in the same direction: Companies need to build and own an Operating System for operational work.

Let me define what I mean, because “Operating System” is a loaded term.

An Operating System is a proprietary infrastructure for internal tooling: unified data layer, logic the company controls, interfaces that show up wherever work happens, and guardrails around it all.

This conclusion does not come only from the needs of agents. It comes from the needs of the company itself. If we started from first principles, what would a company want its stack to look like if it had zero constraints? It would want specialized layers that stack on top of one another:

1. **Data in one place.** A central and unified data layer, rather than fragmented and partially-overlapping copies spread across dozens of tools.
2. **Unlimited automation capability.** To define logic, streamline processes and build workflows at will and in natural language, without being constrained by the narrow assumptions of a single vendor.
3. **Zero interface constraint.** It would want to interact with data wherever the work already happens: in a dashboard, a chat, an email, Slack or an internal tool. The interface should adapt to the work, not force every workflow into the interface of the system that happens to own the data.
4. **Guardrails.** It would want to know who can do what, why an action happened, what changed, when something went wrong and where a human needs to review the work.

Today, tons of companies sell “Operating Systems”. But an Operating System cannot be bought off the shelf. It needs to be molded around the company’s needs. Building everything from scratch, however, is slow and expensive. It means reinventing the wheel instead of benefiting from what others have learned. The middle ground is to assemble it from building blocks: combining the speed of buying with the flexibility and control of building.

The important thing is that the company owns its core operational infrastructure and can shape the layers around the work it actually does.

This is also the most natural environment for agents.

Agents want a single source of truth because they cannot reason reliably across contradictory versions of reality. They want programmable logic because their value comes from being able to execute work, not just describe it. They only want interfaces whenever they need human input. They need guardrails, permissions and continuity in order to operate safely.

What is good for agents is good for the company.
What is good for the company is good for the agents.

The party that loses is the monolith vendor: horizontal SaaS companies that try to swallow you whole, that want to be your one-stop shop for everything, and end up being the best version of nothing.

As an engineer, AI has given me an environment in which I can delegate execution and become an orchestrator of work. As an operator, I still spend too much time carrying context between tools, gluing systems together, and holding the operating model in my head.

That difference lies in the environment. Software engineering had an Operating System ready for AI to plug into. Operational work does not.

The next internal AI transformation will not come from giving agents more intelligence alone. It will come from giving companies an environment in which that intelligence can become useful, reliable, and shared.

That is what an Operating System for operational work needs to do.

But although it makes conceptual sense to build a proprietary Operating System, it can be difficult in practice to understand what that means and where it should live.

This is where Cloudflare comes in.

We will explore that in the next article: ***The Cloudflare bet***.

[ Newsletter ]

## The secrets behind the best-run teams

Discover the tools, systems and strategies top companies use to streamline their entire operations with AI.