The Foundation for Self-driving Operations

Autonomous organizations sounds farfetched. And in reality, I'm neither convinced nor arguing that organizations become fully autonomous, but over the last couple of months as we've seen trends towards designing agentic loops over one-off jobs and scheduled automations, you can see how the pattern may emerge and scale.

But, this level of organizational scale beyond single-player requires infrastructure.

The pitch you hear most often goes like this:

Your data already exists. It is sitting in your tools, your chats, your transcripts, your docs. Point AI at the pile, do some processing, and you are good to go. There is your 'context layer'. Ask it anything! Get an answer!

But are answers what we need? How much are we relying on real-time inference to piece together context? Are we able to run high-level jobs continuously when what we've built is primarily enterprise search?

There is value in the ability to make the entire corpus of enterprise data queryable, but that doesn't mean it's legible for an agentic system to operate on effectively and efficiently.

The problem we are actually trying to solve

Dotwork focuses on complex strategy and operations inside large organizations. The old names for this work were enterprise strategy and planning, strategic portfolio management, technology business management. Big, scaled, organizational ways of working at the level where the enterprise actually steers itself.

Break that down and you get a familiar set of capabilities. Portfolio management. Managing technology investment, budget, and spend. Dependency management. Risk. Capacity planning and resource allocation. High level roadmaps and delivery coordination. Benefits realization, so you can tell whether the things being delivered actually move the outcomes they were supposed to move. Even the necessity and pain of cost accounting.

None of these problems went away with AI. If anything they got bigger. More work moving faster, more agents in the mix, more surface area to coordinate. AI amplifies the problems. But it also hands us a genuinely new set of tools to solve them, if we are willing to rethink the approach.

The old approach was to build large, rigid tools that said: adopt this system, work this way, and it will all come together for you. That broke. It broke with AI and it broke without it. It broke because organizations do not fit into clean hierarchies or one size fits all schemas. SaaS asked the organization to bend to the tool. Reality does not bend. Every organization is constantly changing, constantly adapting, with its own culture, its own rituals, its own flavor of how the work gets done. That is not a flaw to be standardized away. It is the thing the system has to hold.

That is why we built Dotwork. And in the AI era, we think a real system for autonomous operations comes down to three pillars.

Pillar one: an explicitly modeled operating ontology

This is the pillar everyone forgets, and it is the one that is most human.

Before a system can do anything useful with dependency management or OKRs or portfolio investment, someone has to model what those things are. What artifacts make up the operating model. What their properties are. What they mean. How they relate and interact. This is design work, and it is deliberately human.

The assumption baked into most AI tooling is that the model can be inferred. That an agent can read mountains of unstructured data and reconstruct your operating model from the bottom up. Humans do this naturally. We glance at how a team works and think, ah, this is how they operate. But asking an agent to re extract the ways of working from scratch, every time, from piles of chat and transcripts and half structured data, is not going to happen reliably.

And here is the part that gets missed: there is almost never one right way to model these problems. There are roughly three common ways to model dependency management. There are eight or so common ways to model OKRs. Some fit a given organization. Some do not. That choice is real, and it matters. The job is to make the choice explicit, and to make it queryable by the AI systems that have to reason and operate on top of it. An explicitly modeled operating ontology is what makes that possible. You model the function before you can run the function.

Pillar two: an actively maintained context graph

The second pillar is the data itself, held as an actively maintained context graph. This is context engineering: the active design and management of the system that collects, maintains, curates, and ultimately delivers context to both humans and agents.

Historically, keeping that context alive meant data entry. Someone got a mandate to go fill in the fields so a report could bubble up to an executive somewhere across the org. That is an enormous cost on the organization in exchange for something thin on the other end. People hate data entry, and they are right to.

AI gives us the chance to end data entry as we know it. But the deeper point is that context has a cost and a reward. There is a real cost to collecting it, maintaining it, curating it, and then delivering it efficiently to the people and agents who need it. A context system is the thing that carries that cost on the organization's behalf. It should be graph based. It should be semantic. It should be able to maintain and improve itself. It connects to and processes both structured and unstructured data, works with humans and subject matter experts to fill gaps, and connects the dots into something queryable and meaningful, structured by the ontology layer above it.

Pillar three: autonomous action and proactive insight

If the model is right, and the graph is alive and current and connected, then the point is to go do something with it.

You can still do everything you did before. Reporting on top of the system. Support for the rituals you already run. But there has always been a ceiling on that. Watch the evolution from yearly planning, to quarterly planning, to quarterly operating cadences, and notice how taxing each step is. Even quarterly is expensive. It runs on human glue: people copying, pasting, recontextualizing across docs, decks, and spreadsheets, rebuilding reports, watching them go stale. That is the classic problem of operating an organization today.

AI breaks the human limited barrier. It lets us move past quarterly cycles toward something genuinely continuous. The only way to get there is to run these functions autonomously. Human designed, human in the loop, but autonomous in execution.

Most of the conversation stops at the question. People are excited that they can ask an AI system something and get an answer back. Far fewer are asking the more important question: what can the system actually go and do for you, continuously, on its own?

This is where autonomous action and proactive insight come in. Take dependency management again. Once you have modeled it, and you are actively collecting and curating and delivering context around it, the system can do more than report. It can work to reduce dependencies. It can surface design problems in the organization that create them. It can actively coordinate, give teams a heads up, act before things break, and still feed clean signal up to leadership. That is what a system like Dotwork looks like in the AI era.

The two surfaces that actually matter

The shortcut story, slap AI on top of the context layer and slap the context layer on top of your pile of data, misses both of the things that make this work.

On one side there is the active modeling and design of the system: the ontology, the choices, the explicit operating model. On the other side there is the active design and deployment of the autonomous functions the system performs on your behalf. Skip either one and you get a faster way to ask questions. What you do not get is a system that autonomously runs the organization in the domains where it counts.

That is the difference between adding AI to your tools and building a system of context that can actually operate.