What is Work Infrastructure

The current state of work

Every organization has someone like Marta in engineering. When something breaks in production, the on-call rotation will diagnose the symptom correctly, but someone will still ask, "Did you run this by Marta first?" Nothing in any system says this. It isn't in the runbook. New engineers learn it during their second or third incident, watching everyone else do it.

That tacit knowledge is the current infrastructure. So is knowing which issues can wait until Monday, and whose approval is real. Software records the work. People carry the context.

Someone misses a design review. They come back later, open their project management tool, and find the issue marked On Hold.

"Hey, why was this put on hold?"

"We discussed it in the review. Other issues came first."

Nothing in the ticket had that information. The status changed; the reason stayed in the room, in the conversation, in the heads of the people who were there. Anyone who wasn't has to go and ask, and someone always does, dozens of times a day, so routinely that the asking never registers as work.

None of this was wrong though; the people filled in the gaps and the system worked.

The second operator changes this

The arrangement depended on one thing: the next operator was always human.

For decades it was. People were the only operators acting on work. That has changed. Agents no longer just summarize meetings or draft emails; they open pull requests, update CRM records, triage support tickets, move work forward.

And they inherit the same work people do. The same ticket, the same Slack thread. But they can't ask why the ticket was put on hold, or whether anyone ran it by Marta. They act on what the system tells them, and the system was never the whole story.

When every operator was human, the missing half of the story got filled in continuously, by whoever picked up the work next. The cost was real. Nobody ever saw a bill for it, because the people paying it were already there for other reasons. An agent handed a half-complete item doesn't go and ask around. It proceeds, confidently, on whatever the record happens to say, and the mistake surfaces later, if anyone is watching closely enough to catch it.

Consider where an organization's work actually lives. Requirements in one system, conversation in another, execution in a third, approvals somewhere else, customer context in the CRM. Nobody designed it this way on purpose. It held together because people held the seams, carrying context across the gaps between tools as part of the job, unnoticed. The scattered systems were never really connected. They were being connected, all day, by people.

A second operator can't do that. Hand it work spread across five systems and it has no way to know the five refer to one thing.

The familiar complaint mistakes a symptom for the cause. Too many tools is real, but consolidation alone doesn't reach what's underneath it. Move all of work into a single application and an agent still can't say why the ticket was put on hold. Fewer systems is not the same as work that's complete. The work itself, in any one of them, was never held completely enough to be acted on without a person.

The omission is older than any of the tools now blamed for it. For decades, enterprise software got extraordinarily good at building applications for work, and never built infrastructure for work itself. Those applications didn't fail. They solved the problems they were designed to solve, and solved them well. They were solving a different layer. Work has never had infrastructure of its own; it had people standing in for it, and the difference didn't matter until something other than a person tried to act.

The missing piece was not another integration, or fewer tools. It was a layer that made work complete enough for any operator, human or agent to act on correctly.

Work infrastructure, defined

The layer itself is not new. Organizations have always had it. For decades, people carried it from one conversation, meeting, and decision to the next, because the systems they used never had to.

It is purpose-built: the system manages the work itself, not a project, conversation, document, or workflow built around it.

It is agent-native: humans and agents operate on the same work, with the same permissions, rules, state, and history. An agent should not need a separate version of the work or a human to reconstruct what the system left out.

And it is deployable anywhere: the infrastructure can operate wherever the organization needs its work to live, whether in the cloud, self-hosted, or air-gapped.

The standard is simple: the work should be complete enough that the next authorized operator can take the next correct action without reconstructing the missing context.

Enterprise systems have always held pieces of work. Tools holds tickets. Slack holds conversations. Some more tools hold documentation. Each captures part of the work. Work infrastructure is purpose-built to hold the work itself, so that the next operator can act from the record rather than reconstructing what happened somewhere else.

What makes work infrastructure different

A definition says what something is. Properties say what makes it work.

Not every system that stores work is work infrastructure, and not every system an operator can use qualifies either. Four properties make that definition concrete. Remove one, and another operator can no longer reliably act on the work.

Structured

Work needs to be represented as something an operator can reliably act on. Every work item needs an owner, relationships, permissions, history, and state, and each has to be legible to another operator without explanation.

Structure isn't about how information is presented. It's about whether the work itself is addressable, related to the things it depends on, and represented in a form another operator can reliably act on.

Operable

Seeing work isn't the same as moving it. An operator needs to be able to change the state of the work within clear boundaries: scoped to what it may touch, stopped at transitions that require human approval, and recorded as itself rather than through someone else's credentials.

An operator that can read but cannot act still leaves the work dependent on a person. An operator that can act without constraints is one an organization cannot safely trust.

Durable

Every action becomes part of the work. Long after the moment has passed, an organization needs to know what changed, who changed it, when, and why.

That history is what makes delegation possible. An organization can only trust an operator to act when it can trust the record of what that operator did. A layer that cannot be audited backwards will not be trusted forward.

Deployable anywhere

Work has to live where an organisation needs it to live. Jurisdiction, contracts, and regulatory requirements often determine that location, not preference. Infrastructure has to operate within those constraints, whether the work lives in the cloud, a self-hosted environment, or an air-gapped network.

What work infrastructure is not

New categories are easiest to understand against familiar ones. Work infrastructure shares traits with systems of record, collaboration tools, automation platforms, and work management software, and it will usually exist alongside them. That makes it easy to mistake one for another. It replaces none of them. It solves a different problem, on a different layer of the stack.

A traditional system of record

Traditional systems of record capture a domain of work. They hold the state of that work, but still depend on people to interpret what happens next. Work infrastructure is purpose-built around the work itself, so the record carries enough context for the next authorized operator to act.

A chat application with memory

Remembering conversations isn't the same as making work operable. A transcript explains what happened. It doesn't turn what happened into something another operator can act on, any more than the Slack thread about the on-hold ticket moved the ticket.

An automation platform

Automation platforms and agent frameworks act on work. They don't hold it. They run above work infrastructure and depend on it being there, the way applications depend on a database they didn't build.

A project management tool

Project management tools solve the problems they were built to solve. Work infrastructure solves a different one: it makes work complete enough for any authorized operator to take the next correct action.

When work becomes infrastructure

For decades, every application modeled work in its own way, and people connected those models by carrying the missing context from one to the next. It worked because people were the only operators. Human attention was the layer holding the whole arrangement together.

Move that context into the work itself, and the limits change. What follows isn't more automation of the processes we already have. Processes stop being designed around what people can be trusted to remember and carry between systems.

Humans and agents stop working from different versions of the work. They work from the same one, with the same permissions, history, and understanding. No operator has to infer what happened somewhere else because the work carries it. Applications stop solving the same coordination problem over and over because the layer beneath them already has.

That responsibility used to fall to people. Work infrastructure moves it into the work itself.

What we built Plane to be

Plane puts the work itself at the center. Its context, permissions, boundaries, and history remain connected to the work, so the next operator can act from the same understanding rather than reconstructing what came before.

A decision recorded in the Wiki remains connected to the work it affects. A change made by an agent is part of the same history a person sees. The work stays intact as it moves from understanding to action, without requiring a separate agent layer or another system to fill in the gaps.

That is the harder thing to build, and the thing that matters. Holding work completely enough for anyone to act on it is not a feature added to a project tool. It is at the heart of how we built Plane.

And because the system is built around the work, not above it, Plane runs wherever the work has to live: in the cloud, self-hosted, or air-gapped. The same work, the same operators, the same rules, inside whatever boundary an organization is held to.

This is what work infrastructure looks like when it's built: one system, holding the work, for everyone and everything that acts on it.