What AI did to code, it will do to operations

I’ve spent my career on both sides of the fence: building systems, and keeping the business running.

I came up in operations, but I was never content to stay inside the tools I was given. I chased every early product I could get into. I pushed no-code as far as it would go. Every time, I hit the same ceiling: the workflow wouldn’t bend, the data sat behind a wall, the UI refused to flex, or some rare case the vendor had never planned for broke the whole flow.

So I learned to write software.

On the engineering side, AI rewired how I work. Agents now handle a large share of the execution. They dig through repos, draft changes, run checks, and patch what breaks. I spend less time typing every line and more time directing the work.

On the operations side, the day still looks familiar. I coordinate. I message. I copy numbers from one system into another. I can hand a codebase to an agent before lunch, then spend the afternoon ferrying context between apps by hand.

Living in both worlds makes the gap obvious.

Sales, marketing, finance, and HR still wait for the same leap coding already took. Why? What is actually missing?

It is not that the models are too weak. It is that the workplace around them is not ready.

1. Why software work moved first

Engineering’s shift with AI was gradual, not a switch flip. Roughly, it looked like this:

1. Autocomplete: the model finishes a line while you type. You still own the work; you just move faster.
2. Chat: you ask in a side window. The model explains or drafts. You still paste and adapt the answer into the real project.
3. Agents: you state a goal. The model can drive tools and take multiple steps toward it.
4. Cloud agents (where we are now): the agent works in its own remote workspace, end to end, and returns finished output instead of living only inside your editor.
5. Self-building products: the model starts choosing what to change, not only how — planning, shipping, testing, and tending parts of the product without a person driving every move.

We are not done, but we are near the end of that runway: deep into stage four, with stage five showing up at the edges.

Coding got there early because the craft already ran on infrastructure AI could inhabit.

A program either passes or fails. Changes leave a trail. Engineers share a fairly coherent setup: editor, repository, containers, tests, deploy pipelines. Years of tooling made the work readable and hand-offable. Version control lets anyone inspect or undo a change. Types and tests give tight feedback. Docs live on the public web. Teams already break work into specs, tickets, sprints, and reviews.

None of that magically solves hard problems. It does give an agent a desk, a memory of the project, and signals that say “this helped” or “this broke.”

Operations has almost none of that. Day-to-day work spans a patchwork of products bought over years. Some are locked down or brittle enough that an agent can barely touch them. Others are open, but each holds only a slice of what is true. The rest of the story sits in docs, chat threads, and people’s heads.

Outcomes are messier too. You are not flipping bits in a deterministic machine. You are dealing with people. “Good” often depends on relationships, timing, and politics, not a green checkmark. The right answer on paper can still be the wrong move for the team, the customer, or that week.

Agents are not barred from this work by nature. They are barred by the missing workplace.

2. How companies accidentally built a Frankenstein stack

Step back from agents for a moment. Look at how ops work got organized over the last few decades.

There is no shared, inspectable workspace like a repo. There is a catalog of SaaS apps. That layout was not drawn on a whiteboard as the ideal company design. It accreted as the SaaS market grew, and the pattern repeats almost everywhere.

a. Silos

Early on, each function buys the product that kills its immediate pain. Marketing lands in HubSpot. Finance in QuickBooks. Support in Zendesk. People pick what they already know, because that is how they know how to do the job.

Every app becomes its own tower: its own records, its own rules, its own screens. A line of sealed boxes, each sure of its own truth, none of them looking at the others. At scale, that can mean hundreds of tools under one roof.

b. Glue

Departments still have to hand work to each other. Finance pulls from sales. HR pulls from finance. Sales needs a read on support.

Two common fixes:

• Built-in integrations. Quick to turn on, but aimed at the average customer. The moment your process is specific, you hit a hard stop with no escape hatch.
• Automation platforms like Zapier, Make, or n8n. More room to customize, and also another set of flows to wire, watch, and keep alive.

What you get is not one system. You get blocks stuck together with tape.

c. Data extraction

Even after the pipes are in, trust stays low.

So teams stand up a warehouse. ETL copies data out of the apps. BI tools paint a picture on top. You get a read-only mirror of the real activity underneath — useful, but still a reconstruction.

Call that the Frankenstein stack: vertical products, held together by integrations and automations, with a warehouse on top pretending to be the single truth. Parts bolted into a body they were never meant to form.

Nobody chose this as the elegant design for how work should run.

It followed market incentives. Vendors chase a vertical, dig a moat, then sprawl sideways. Buyers grab the best tool per team and promise to “connect it later.”

Humans could limp along in that mess. Agents cannot. If the company has no coherent place where work actually lives, an agent cannot run the company with any reliability.

3. One person and an agent is not a company

Ops is multiplayer. Teams and people have to stay in sync.

A driven individual can stand up a useful agent. A safe, dependable fleet across a whole org is a different challenge.

One person can feed context, wire tools, narrate exceptions, and check the output. They catch weird results. They green-light risky steps. When the agent stalls, they nudge it. In that setup, the person is the missing layer — supplied manually.

Spread that across many people and many agents, and improvisation stops working. Shared context cannot live in one champion’s head. Access rules cannot be invented on the fly. The whole thing cannot depend on one AI-savvy employee babysitting every run.

At company scale, agents need three capabilities the system has to provide:

a. Context — knowing what is true

The agent needs the facts for this company, this team, this person, and this task: live systems of record, institutional memory, local jargon, how work is supposed to run, and what already happened on this thread.

That context has to be shared. If everyone rebuilds their own private picture of the company, agents will contradict each other and the output will drift.

You need one maintained source of truth, kept current, scoped to the right permissions.

b. Agency — acting within bounds

The agent needs a clear map of allowed and forbidden moves.

Wide open access is a liability. It might open the wrong file, edit the wrong record, or act as the wrong person.

Useful agency means room to finish real work inside rules the org can explain and trust: roles, permissions, sandboxes, review steps, and clear owners.

Those limits are not a brake on agency. They are what makes agency safe enough to grow.

c. Continuity — finishing the job

A model will not, on its own, remember yesterday’s open question, a pending approval, or an irreversible step it already took. The surrounding system has to keep that state.

Work has to pause for humans, resume when they answer, retry when it is safe, and refuse to double-fire a consequential action.

Above all, it has to land on an outcome — not a clever reply that goes nowhere.

4. An operating system for how the company runs

The Frankenstein stack and the multiplayer problem land on the same prescription: companies need to own an operating system for operational work.

I mean that literally as internal infrastructure: one data layer, logic you control, surfaces that appear where people already work, and hard rails around what can happen.

Agents are not the only reason. Start from a blank page and ask what a company would want with no vendor constraints. You get stacked layers:

• One place for data. A unified layer, not overlapping copies in twenty apps.
• Automation without a ceiling. Define processes and workflows freely — including in plain language — instead of living inside one vendor’s opinion of how work should look.
• Interfaces that follow the work. Dashboards, chat, email, Slack, internal tools — meet people where they already are, instead of dragging every flow into the UI that happens to own the record.
• Guardrails. Who can do what, why something ran, what changed, what failed, and when a human must review.

Plenty of products market themselves as “the OS.” A real one is shaped around your company. Building every layer from zero is slow and wasteful. Buying a monolith and praying is the other extreme. The practical path is assembling durable blocks: buy for speed, own for control.

What matters is owning the core of how work runs, and bending the layers to match reality.

That environment is also what agents need to thrive.

They need one trustworthy picture of the world. They need logic they can execute, not only describe. They need a human-facing surface only when a person must decide. They need permissions, review, and memory across time so they can act without creating chaos.

Good for agents and good for the company are the same design.

Who loses? The all-in-one vendor that wants every process inside its walls and ends up excellent at none of them.

Engineering already handed me a place where I can delegate execution and steer. Operations still asks me to shuttle context, tape systems together, and keep the real operating model in my head.

The difference is the environment. Software work had a ready home for AI. Operational work still does not.

What it looks like in practice — and where it should live — is a separate conversation.