Why does the Work Knowledge Graph need gardeners?

A workflow graph needs a way to add new knowledge without losing the evidence and context that make it useful.

The Opus Work Knowledge Graph records reusable tasks, the handoffs between them, and the evidence that explains how they fit together. Its tens of millions of nodes give Opus a structured starting point for building workflows.

That knowledge needs maintenance. Some contexts are well covered; others lack workflows, supporting detail or connections. Opus uses Graph Gardening to investigate those gaps and prepare additions. Autonomous agents called gardeners propose changes, which pass through separate checks and approval before publication.

Following one proposal shows how that separation works.

Choosing a gap worth filling

Opus classifies graph coverage by industry, sub-industry, geography, level of detail and language. Each combination identifies a taxonomy cell: a specific area of process knowledge.

Consider Financial Services / Retail Banking / Saudi Arabia / Level 3 / Arabic. Suppose a gardener finds little coverage of customer onboarding in that cell, while neighbouring cells are well developed. It assesses the gap against other possible improvements by user value, evidence availability, cost and duplication risk, then selects work within a shared budget.

The work might involve enriching a task, resolving a duplicate or investigating a missing handoff. Here, the gardener prepares an Arabic-language onboarding workflow. It starts from a published snapshot, so its proposal has a fixed reference point.

Evidence for the tasks and their order

Before asking a language model to draft the workflow, the gardener gathers sources, removes duplicates and organises the material into evidence packs by industry, geography, language, regulator and process.

The model receives those packs and produces a candidate: tasks and the connections between them. Each task and connection must cite supporting evidence. Supplying evidence does not prevent a model from making unsupported claims, so the candidate still has to be checked.

The connections deserve particular attention. If a process requires identity verification before account activation, evidence that both tasks exist is insufficient. The candidate also needs evidence for that order. Two individually valid tasks can still form an invalid handoff.

How a candidate earns its place

1. Ground the claims. Claims about regulators, laws, required documents and local obligations are checked against the evidence. Unsupported detail can be removed or made less specific only if the workflow remains valid. Grounding does not add, remove or reorder tasks. A correction that requires changing the process structure sends the candidate back for rewriting or rejection.

2. Validate the structure. Deterministic checks confirm that the candidate uses the expected format, connections refer to defined tasks, citations resolve to evidence, and labels use the approved vocabulary. Whether a source actually supports a claim requires a separate judgement, which is recorded and can still be wrong. Structural validity and evidential support are distinct checks.

3. Resolve the entities. The proposed tasks are compared with existing graph content. Close matches can be merged into an existing task; near matches remain separate and can be linked as similar. The similarity thresholds are configurable settings, not guarantees that two tasks are interchangeable. Structural validation runs again after a merge.

4. Apply the approval policy. A candidate that fills a sparse cell can be approved automatically when it passes the checks and policy permits. A new connection between one workflow's output and another's input requires human review because it changes how processes combine.

For our example, adding the onboarding workflow to its cell may qualify for automatic approval. Proposing that its completion should trigger an existing credit-check workflow requires a person to review that connection.

Publishing a version that can be traced

Approved changes enter a new, immutable snapshot. Existing snapshots retain the graph's tasks, connections, vocabulary and evidence, together with their version lineage.

Gardeners work on assigned regions and prepare changes in separate staging areas. Each proposal declares what it intends to add, replace or merge. Compatible changes can be published together. Publication checks for conflicts; proposals based on an outdated snapshot, or conflicting with a newly published change, are rebased and checked again.

Snapshots preserve the starting point and history. Staging, conflict detection and revalidation control how concurrent proposals become the next published version.

If a correction is needed, an operator can restore an earlier graph snapshot or publish a change to specific entities. The recorded history provides the basis for that recovery.

Gardeners share a budget measured in actual spend. Opus records model-call usage and checks recorded daily spend before scheduling more work. Reserving budget for calls already in flight is a proposed extension, so the current check should not be read as a guarantee against overspend.

An enterprise graph has its own history

AppliedAI maintains the master Work Knowledge Graph of general best-practice workflows. An enterprise can start from a copy and extend it using its own gardeners and evidence. Its additions and imports remain private, with separate snapshots, search index, budget and logs. Nothing returns to the master graph without explicit client authorisation.

The location of the graph does not, by itself, determine where model inference runs. A gardener may send evidence to a model hosted elsewhere, depending on the deployment configuration. Both choices matter when deciding how enterprise information is handled.

Knowledge that can be examined and corrected

Graph Gardening gives Opus a repeatable way to extend its knowledge of work while retaining the evidence, approval history and version lineage behind each admitted change. Teams can inspect why a task or handoff entered the graph and use that record when it needs correction.

The checks reduce the risk of unsupported content and help investigate errors. They do not guarantee that every accepted claim is correct. The practical benefit is a growing body of process knowledge whose additions can be reviewed, traced and corrected as it develops.