The Work Graph for AI agents: The missing layer in agentic work

Most conversations about AI agents focus on the model, the tools, or the prompts. Far less attention goes to the thing the agent is actually acting on. If the underlying work is scattered across comments, stale updates, loosely named tasks, and undocumented dependencies, even a capable agent starts from shaky ground.

This article explores the operational model beneath agentic work: how structured state and relationships change what an agent can reliably resolve, how that context fits alongside chat, RAG, and memory, and what buyers should look for in a work system built for agents.

Why agents need an operational model beyond conversation

Consider a request to move the remaining authentication work into an upcoming Cycle. A teammate who has been following the project may understand the request immediately. An agent has to resolve several operational details before it can act.

What the agent needs to establish

• Which work items fall within the requested authentication scope
• Which cycle is the source and which upcoming cycle is the intended destination
• Which work items count as remaining based on their current Work Item States
• How cancelled work should be handled if it falls within that scope
• Whether dependencies or parent and sub-work-item hierarchy affect the move
• Whether the acting identity is authorized to make the change

Conversation may contain pieces of that information. A status update might describe a blocker from yesterday, another message may suggest that the blocker is nearly resolved, and ownership may have been discussed informally. Those messages remain useful context, but the underlying work can change after they are written.

For example:

• A work item described as blocked on Monday may be completed by Wednesday.
• A proposed state change may never be applied.
• Ownership can shift in discussion while the Work Item still records a different Assignee.
• Messages written at different points in the lifecycle can describe different versions of the same work.

Language models can interpret those messages and recover useful context from prose. When an agent also has access to the work system, it can resolve operational facts such as current State, Cycle assignment, dependencies, hierarchy, and ownership from the records that exist there.

That leads to a more useful architectural question: which operational facts can the agent inspect directly, and which context still has to come from conversation or other unstructured sources?

Where conversational context creates extra work

Several recurring problems appear when current operational facts have to be reconstructed primarily from discussion:

• Stale status: Earlier updates remain available after the underlying Work Item changes.
• Conflicting updates: Messages written at different times may describe different States or ownership.
• Implicit dependencies: A team may discuss that one Work Item depends on another without recording the dependency.
• Ambiguous references: Phrases such as “the login bug” or “that auth task” may match several Work Items.
• Intent versus recorded action: A team may discuss closing, reassigning, or moving work without that change ever being recorded in the work system.

Longer conversational history can add useful rationale and chronology. For current operational facts, the agent benefits from resolving the relevant Work Items, States, dependencies, assignments, and planning context directly.

What we mean by a Work Graph in Plane

In this article, we use Work Graph to describe the connected model of operational work that agents can resolve against. Work is represented through explicit objects, recorded properties, and connections between those objects, giving an agent a structured view of what exists and how different pieces of work relate.

The core pieces include:

• Projects provide the project context in which work is tracked.
• Work Items represent the fundamental units of work.
• State records where a Work Item sits in the project's workflow.
• Parent and sub-work-item hierarchy connects larger pieces of work with the smaller items beneath them.
• Dependencies express scheduling constraints between Work Items, while relations capture logical connections between them.
• Assignees identify the members responsible for a Work Item.
• Cycles, Modules, Milestones, and Initiatives add planning and broader organizational context.

Availability of some planning and relation capabilities depends on the Plane plan and workspace configuration.

The value for an agent comes from combining these pieces. Suppose a Work Item called “Update login flow” belongs to the authentication Project, is assigned to Cycle 24, has the State In Progress, is blocked by another Work Item, has two sub-work items, and is assigned to Priya. The agent can resolve a much more specific operating context than the title alone provides, including which connected work it may need to inspect before recommending or taking an action.

Why relationships matter as much as the fields

Properties such as State, Priority, Assignees, dates, Cycle, and Modules describe the Work Item itself. Its connections show how that item sits within the surrounding work.

Suppose LOGIN-18 is In Progress and assigned to Priya. That establishes its recorded lifecycle position and ownership. Now add a dependency: LOGIN-18 is blocked by AUTH-42. Before treating LOGIN-18 as ready to proceed, the agent has a reason to inspect AUTH-42 and its current State.

Add hierarchy: Parent: Authentication migration

The agent can now place LOGIN-18 within a larger unit of work.

Each connection carries its own operational meaning. Blocked by represents a prerequisite between Work Items. A parent establishes hierarchy. Assignees record responsibility. Project and Cycle associations place the Work Item within its execution and planning context. Those distinctions help an agent determine which surrounding objects are relevant to the request it is handling.

This is where the graph framing becomes useful. A Work Item's meaning comes partly from its own recorded properties and partly from its position relative to other work. The term describes this connected domain model and stays agnostic about the database technology underneath Plane.

Three requests that show why structured work matters to agents

The value of structured work becomes clearer when an agent has to make an operational decision or change the system.

“Can we start this work now?”

Imagine LOGIN-18 was blocked earlier in the week.

• The conversation contains: “LOGIN-18 is waiting on AUTH-42.”
• Later: “The auth changes look good.”
• Then: “We should be able to start login tomorrow.”

Those messages provide useful context, but the recorded work may have changed since they were written. An agent can inspect LOGIN-18's current State, its Blocked by dependency on AUTH-42, AUTH-42's current State, and the relevant ownership and Project context.

If AUTH-42 is now in a State within the Completed group, the recorded prerequisite for LOGIN-18 has cleared. Capacity, release timing, and competing priorities may still affect whether the team should begin the work. The dependency establishes one operational fact that the agent can resolve before reasoning about those wider trade-offs.

“What will be affected if this slips?”

Suppose someone asks: If the API migration slips by a week, what else is affected?

Conversation and retrieved documents may contain useful evidence about downstream work. A structured work model can also expose recorded connections such as:

• API migration blocks mobile login
• Mobile login belongs to a broader authentication effort
• Related Work Items contribute to a Milestone
• Work Items across different Projects sit within the same Initiative

The agent can follow those recorded connections and inspect the current State of the affected work. This turns impact analysis into a traversal of known operational relationships alongside any supporting context retrieved from comments, Pages, or conversations.

The quality of that analysis still depends on what teams record. An untracked dependency remains invisible to the structured model, which makes work hygiene part of agent readiness.

“Move the unfinished work to the next Cycle”

Bulk changes make precise targeting especially important. Suppose the request is: Move the unfinished authentication work from this Cycle into the next one.

Plane can provide the source Project, source Cycle, Work Items assigned to that Cycle, their recorded States, the intended upcoming Cycle, and any relevant hierarchy or dependencies.

From there, the agent can identify the Work Items that match the request. If “unfinished” is ambiguous, it may also need to clarify how Cancelled work should be handled before building the final set.

For this type of bulk change, Plane AI's Build mode plans the actions and shows them as action cards for review before execution. The user can inspect, edit, cancel, or confirm individual actions before anything changes in the workspace.

Structured state gives the agent a clearer target set and gives the user a stronger basis for reviewing the proposed change.

How an agent can read and act on structured work in Plane

The requests above follow a similar operating pattern: resolve the intended work, inspect its current state and relationships, evaluate the constraints around the action, make the change through the appropriate Plane surface, and verify the result. How those steps are handled depends on whether the interaction uses Plane AI, the MCP server, the Plane API, or Plane Agents.

1. Interpret the request

For a request to move unfinished authentication work into an upcoming Cycle, the first task is understanding the intended outcome and identifying which Plane objects need to be resolved.

Ambiguity matters here. “Authentication work” may refer to a Project, a group of Work Items, or work spread across several Projects. “Unfinished” also needs a clear interpretation before anything changes.

2. Resolve the relevant Plane objects

The request may require the agent to identify:

• The authentication Project or relevant scope
• The source Cycle
• The intended upcoming Cycle
• The Work Items that match the request

Plane AI can retrieve workspace data including Work Items, Projects, Cycles, Modules, Pages, members, and other supported entities. When a user mentions a supported Plane entity directly, Plane AI resolves it in real time and includes its current data in the request context.

External AI tools can access Plane through the MCP server, which exposes Plane capabilities to MCP-compatible clients and reads or writes through Plane's API. Developers can also work directly with the Plane API, which provides programmatic access to Plane resources without going through Plane AI.

3. Inspect recorded state

Once the relevant objects are resolved, the next step is to inspect the properties needed for the decision. Depending on the request, those may include State, Assignees, Priority, dates, Cycle membership, Modules, comments, or history.

Plane AI retrieves current workspace information when workspace context is enabled. For supported entities added through @mentions, it fetches fresh data when the request runs.

For MCP-connected clients and direct API integrations, the application retrieves the corresponding Plane resources through the MCP tools or API endpoints available to it.

4. Inspect relevant relationships

Properties alone may leave important questions unanswered. The request could also depend on hierarchy, dependencies, or relations between Work Items.

An agent should inspect the connections relevant to the action it is considering. For example, moving a Work Item may require checking whether it is blocked by another item or belongs beneath a larger parent.

Selective traversal keeps the context focused on relationships that can affect the requested action.

5. Evaluate action constraints

Before writing to Plane, the acting surface needs to operate within the access and process controls that apply to it.

• Plane AI works with Plane data that the user's account can access. Workspace configuration and plan availability also determine which Plane AI capabilities are available.
• MCP-connected clients read and write as the Plane user connected to the MCP server. That user's workspace and Project roles apply to every operation.
• Direct API integrations authenticate with a Plane credential, and Plane evaluates API operations using the access associated with that credential.
• Plane Agents use a separate execution and access model from Plane AI and MCP-connected clients, so teams should evaluate the permissions that apply to Agents independently.

Configured Workflows and Approvals may add further controls to supported work transitions. The relevant authorization and workflow checks should be understood before an agent is given permission to change production work.

6. Execute through the appropriate surface

Execution behavior differs significantly across Plane's AI and developer surfaces.

• With Plane AI Build, Plane AI plans the requested changes and presents them as action cards before execution. The user can review, edit, cancel, or confirm individual actions. Auto mode follows the same planning process and executes the actions without the Build review step.
• An external AI tool using the Plane MCP server operates through its own client experience. The MCP server sends reads and writes to Plane's API, while confirmation behavior is controlled by the MCP client or surrounding agent system.
• A direct Plane API integration follows the application's own execution and approval logic while Plane authenticates and authorizes the requested operations.
• Plane Agents follow their configured playbooks, triggers, context, and Agent settings. Their execution model is separate from Plane AI's Build and Auto modes.

7. Verify the resulting state

After the action runs, the affected Plane objects should be checked again so the response reflects what the system now records.

For a Cycle move, verification can confirm:

• which Work Items changed
• their resulting Cycle assignment
• whether any requested changes failed
• whether the final state matches the intended action

Plane AI Build provides an execution summary showing which planned actions succeeded or failed. MCP-connected clients and direct API integrations can perform a fresh read of the affected resources before reporting completion.

This final check closes the gap between requesting an action and confirming what actually changed in Plane.

What to look for in a work system before letting agents act

The Work Graph becomes especially useful as an evaluation framework. If agents will operate on project or product work, the underlying system needs enough structure for them to resolve the relevant objects, inspect their current state and relationships, and determine which actions are allowed.

Feature availability varies by plan. Milestones and Initiatives are available on Pro and above. Workflows are available on Business and above, while approval flows, transition conditions, and multiple Workflows scoped to specific Work Item Types are Enterprise Grid capabilities.

For a buyer, the practical test is whether the system gives an agent enough recorded state, relationships, planning context, and access controls to resolve an action before it runs. Rich fields alone leave gaps when relationships are missing, while relationships provide limited protection when authorization and workflow controls are weak. Agent readiness comes from how these pieces work together.

How chat, RAG, memory, and the Work Graph work together

Agents often need several kinds of context to understand operational work. The Work Graph, conversation, retrieval, and memory each contribute something different:

• Chat carries intent, discussion, clarification, and negotiation.
• Agent memory preserves useful context from earlier interactions when the agent system supports it.
• RAG retrieves relevant documents, comments, discussions, policies, and other available evidence.
• The Work Graph provides addressable work objects, their recorded state, and explicit relationships.

Consider a Work Item blocked by a security review. Plane can record the Blocked by dependency and the current State of the security review Work Item. A Page or Work Item comment may explain why the review was required, which exception is being considered, or what risk the team is willing to accept. An external conversation can add further context when that source is available to the agent.

Together, these sources give the agent both the operational facts recorded in the work system and the surrounding context needed to interpret them. Which sources matter depends on the decision the agent is being asked to make.

Where the Work Graph stops

The Work Graph gives agents a stronger operational foundation, but its usefulness still depends on the quality of the recorded work, the agent's reasoning, and the controls around its actions.

1. Structured data can still be wrong

A Work Item can remain in a State within the Started group even after the work is finished in practice. An Assignee may be outdated, or a date may remain unchanged after the team agrees to move it.

An agent can retrieve that record accurately and still start from stale information. Data freshness and consistent work hygiene therefore matter to agent reliability.

2. Missing relationships remain missing

If one team depends on another and nobody records that dependency in Plane, the Work Graph has no explicit connection for the agent to follow. The same applies to ownership, hierarchy, and planning context that teams leave implicit.

3. Correct retrieval can still lead to poor reasoning

An agent can retrieve the right Work Item, inspect the relevant dependency, and still reach a poor recommendation. Structured state gives the model a better factual basis, while reasoning quality remains a separate part of the agent system.

4. Permissions still matter

Authorization is enforced by the Plane surface through which the agent acts.

• Plane AI works with workspace data available to the user's account.
• The MCP server reads and writes as the connected user within that user's workspace and Project roles.
• Plane Agents use a separate execution and access model that teams should evaluate independently from Plane AI and MCP-connected clients.

Workflow rules, approval requirements, and human review can add further controls where the relevant Plane capability and plan support them. These controls become more important as an agent receives broader write access.

Q5. Some context will always live in prose

Operational records rarely capture every reason behind a decision. A deadline may carry customer or business implications, a team may have made an informal commitment, or a resolved dependency may still leave enough risk to delay downstream work. Pages, Work Item Comments, documents, conversations, and human discussion can provide that surrounding context.

Q6. Human judgment remains part of operational work

Questions such as “Should we ship?” or “Which Project deserves the available capacity?” involve priorities and trade-offs that relationships alone cannot settle. The Work Graph gives people and agents a clearer factual base for those decisions. Judgment still determines what to do with that information.

Bottom line

Workplace AI can do useful work with conversational and documentary context, especially for search, summarization, drafting, and question answering. Operational actions require a firmer base. When an agent changes project data, it needs to resolve the right Work Item, inspect its recorded State and relationships, understand the controls around the action, and confirm what changed. The Work Graph provides that operational layer, while conversation, retrieval, and memory supply the surrounding context needed for interpretation.

For teams evaluating work-management systems for agentic use cases, that underlying model should be part of the buying criteria. Plane represents work through Projects, Work Items, Work Item States, hierarchy, dependencies, ownership, and planning context, with built-in interaction through Plane AI and programmatic access through the Plane API and MCP server. If your team is evaluating how agents could read and act on real project work, talk to sales to see how these capabilities fit your workflows, access model, and deployment requirements.

Frequently asked questions

Q1. What is a Work Graph for AI agents?

A Work Graph for AI agents is a structured model of operational work that connects work objects with their current State, ownership, hierarchy, dependencies, and planning context. It gives an AI agent a defined set of objects and relationships to inspect before making a recommendation or taking an action.

In a project management system, the Work Graph can include Projects, Work Items, Assignees, Cycles, dependencies, parent and sub-work-item relationships, and other planning structures. This helps the agent resolve what the request refers to and understand how that work connects to the rest of the system.

Q2. Why do AI agents need structured project data?

AI agents need structured project data to identify the correct work, read its current State, understand ownership and dependencies, and determine the scope of an action. These recorded facts reduce the amount of operational context the agent has to infer from conversations or documents.

Structured project data is especially useful when an agent can change the system, such as updating a Work Item, moving work between Cycles, changing ownership, or creating follow-up work.

Q3. How is a Work Graph different from RAG?

A Work Graph represents operational objects, their recorded properties, and explicit relationships, while RAG retrieves relevant information from documents, comments, conversations, and other knowledge sources.

An AI agent can use both. The Work Graph helps it resolve the current structure of the work, while RAG can provide supporting context such as decisions, policies, explanations, or historical discussion.

Q4. What should a project management system expose to AI agents?

A project management system should expose addressable work objects, lifecycle State, ownership, hierarchy, dependencies, planning context, machine-readable access, and permission controls if AI agents are expected to read or change operational work.

For actions, the system should also support a way to validate the target, apply the relevant authorization and workflow rules, execute the change, and verify the resulting State afterward.

Q5. Can AI agents safely update project management systems?

AI agents can update project management systems more reliably when they can resolve the exact work object, inspect current State and relationships, operate within defined permissions, and verify the result after execution.

The level of review should match the risk of the action. Teams may choose user confirmation, workflow approvals, or other controls for changes that affect multiple Work Items, ownership, scheduling, or delivery commitments.

6. Why are dependencies and relationships important for AI agents?

Dependencies and relationships show AI agents how one piece of work connects to other work. A Work Item's State can show its current lifecycle position, while a dependency can reveal that progress relies on another Work Item, and hierarchy can place it within a larger effort.

These connections help the agent decide which surrounding objects need to be inspected before it recommends or performs an action.