Plane's next chapter
AI agents can only be as reliable as the systems beneath them. Discover why the future of work infrastructure starts with a shared graph where people, agents, and work operate on the same foundation.
AI agents can only be as reliable as the systems beneath them. Discover why the future of work infrastructure starts with a shared graph where people, agents, and work operate on the same foundation.


A demo goes around every few weeks now. Someone wires the Granola MCP, the Linear MCP, and the Notion MCP behind a single assistant, asks it a question, and it pulls context from all three. The replies fill up with people calling it the end of SaaS.
I've watched a dozen of these, and I keep getting stuck on the same question. What's the system underneath?
Nobody ever demos the second week. Connect ten tools to an agent, and it reads all ten, which also means it sees ten versions of what's true with no shared state to reconcile them. The meeting notes disagree with the tracker, the wiki went stale six months ago, and when a language model hits a gap like that, it does what language models do, which is fill it in. The value falls between the tools, which is where it was already falling for the people using them.
The problem was never a shortage of connectors. It's that the work doesn't live anywhere.
Five records of one bug, sitting in five tools with nothing linking them.
Take the same scenario on Plane.
A customer reports a problem and the request lands in Service. An engineer turns it into a work item in Projects, on the same graph, linked, with one ID carrying the history forward. The work item ships in a cycle. Someone writes the fix up in Knowledge, and that page links back to the work item and to the request that started it.
Three surfaces, one model. Nothing here is a copy of a record in another system with a broken trail behind it. The request, the work item, and the page are nodes on the same graph.
Now ask an agent what happened with this customer. There's nothing to reconcile, so it walks the chain instead: request, work item, cycle, page. One traversal, nothing to guess at, because nothing is missing.
One graph, one traversal
Agent-Human
Reading is the easy half. The test is what happens when the agent writes.
When an agent on Plane updates a state, drafts a resolution page, or files a follow-up, it does that as an actor on the graph with its own identity and its own permissions, under the same rules and the same audit trail as any person. We call the principle Agent-Human: agents and humans as peers on one graph, working the same nodes under one system. The agent is a worker in your org rather than a chat window bolted onto the side of your tools, and the graph treats it accordingly.
That one decision does most of the work. It's what makes agents usable in places where "the AI did something and we're not sure what" ends a career, because every action is attributable, permissioned, and on the record. It's also the only thing an ecosystem can be built on. Once agents are actors on the graph, you stop integrating them one connector at a time. The graph is the interface.
Humans for the judgment
Agent-Human runs both ways, and none of it takes people out of the loop. It moves them to the part of the loop that was always the point.
Agents take the toil, which is the drafting, the executing, the filing, and the chasing. People keep the judgment: what to review, what to approve, what to send back. Both happen on the same graph, so a decision lands as state rather than as a message someone has to remember, and the next cycle starts from what the last one learned instead of from an explanation.
The Agent-Human loop
That compounds cycle over cycle, and we mean cycle literally, because cycles are how work ships in Plane and each one now begins where the last one actually ended. Take the coordination lag out of a company, the syncing and the status-chasing and the archaeology, and the constraint you're left with is human judgment. That's the constraint you want. The gap between deciding something and the system reflecting it goes to almost nothing.
We built the substrate before the agents arrived
None of this came from a pivot. Plane is named after the coordinate plane, where everything has a position and a relationship to everything else, and the bet from the start was a single foundation: projects, knowledge, and service on one model instead of three products stitched together. A five-person team and a hundred-thousand-person org run the same system. What you turn on changes, what you depend on doesn't. Nobody should have to graduate into using their own tools.
For years the payoff was operational, which is why teams in defense, aerospace, and finance run Plane for work that can't go down, can't leak, and can't sit in someone else's region. The other payoff took longer to show up. An agent can't reason over context scattered across five tools and a thousand threads. It needs a substrate underneath it, and we'd been building one the whole time.
What we're building next
The substrate is where this starts. Five things get built on top of it, and all five are moving now.
Five fronts, one destination
Agents first, and aggressively. Prebuilt ones that do a real job on day one, like triage, backlog grooming, follow-ups, and release notes. Tooling for teams that want to write their own, since the agents that understand your business best are the ones you build in-house. Custom work for the teams that want us in the room for it. However they arrive, they arrive as actors on the graph, governed like everyone else on it.
The API gets treated as a product in its own right. If the graph is the interface, the API is the front door, and every capability should land there with the same care it lands in the UI. Developers building on Plane are how an ecosystem happens, not an audience we serve on the side. If you build for a living, Plane should feel like it was made by people who do too, because it was.
Then the surfaces where judgment happens. If human judgment is the bottleneck worth keeping, the screens where people review, decide, and redirect are the most important screens in the company. We'll keep getting better at putting the right decision in front of the right person, with what they need to make it and nothing else.
Underneath those, the primitives: how a person hands work to an agent, how the agent hands it back, and how review, approval, and escalation happen as operations on the graph rather than as etiquette in a chat thread. Both directions get faster and cleaner with every release.
And the substrate itself has to scale. Far more records, heavier workloads, more of the work that can't go down and can't leak. Infrastructure earns the name by behaving like infrastructure under load. It's the least interesting item on this list and probably the one that matters most.
Work infrastructure for humans and AI agent era
Here's where this goes. Work infrastructure is the layer work runs on: one canonical graph, Agent-Human from the ground up, people and agents under the same rules, running wherever you decide to run it.
Work management is a category you compete in. Infrastructure is what everything else quietly assumes. It stays legible to people, machines, and auditors, and it scales without an army of admins keeping it upright. The "wherever you decide" part is the one people read past. Cloud, self-hosted, or air-gapped, it's the same product, the same model, and the same behavior. The choice is about where your work runs, not which version of Plane you get.
Run that out ten years, and you get what we're building toward. Companies on a system that's unified, open, and intelligent, where agents carry the dull work, people make the calls that were always theirs to make, and every cycle starts further along than the last one did. On one graph, and it's yours.
Plane, the work infrastructure for humans and AI agent era
Recommended for you



