Inside Opus · Part 1 of 13
Start here. This is the map for the series. Each later article follows one part of the system in detail and refers back to this one. The full list of articles is at the end.
The invoice that stops being a document
A supplier invoice arrives. On paper it is a document-processing request: read the PDF, pull out the fields, post the result. Then the purchase order number on the invoice does not match anything in the finance system. The supplier name is “Northwind Ltd” on the invoice and “Northwind Limited (UK)” in the vendor master. The total is above the threshold that requires a named approver. And when all of that is settled, the finance system has to be updated, once, with the right record.
None of these steps is hard by itself. The difficulty is that they are different kinds of work. Retrieving data is an integration problem. Interpreting an ambiguous supplier name is a judgement problem. Checking arithmetic and thresholds is a deterministic problem. Approving an exception is a human problem. Recording the outcome is an integration problem again, with the added requirement that it must not happen twice.
I will use this invoice throughout the series. It is hypothetical, and I will keep it that way, but it gives every article the same set of situations to examine: parallel checks, a missing purchase order, a reviewer’s correction and, later, a component update.
What the system has to provide
The requirement I would set for any system that handles this work is simple to state. It has to give the work an explicit structure, execute each part with the right kind of resource, keep the whole thing under one set of access rules, and produce evidence that can improve the next case. Most tools do one or two of those well. The argument of this series is that the value comes from how the parts connect, so this first article is about the connections.
The unit of work
In Opus, the invoice work is a workflow: a graph of task nodes with defined inputs and outputs. Each node has a type that determines which kind of worker executes it.
An Integration node retrieves the invoice and looks up purchase-order data in the finance system.
An Agent node extracts the fields and interprets the ambiguous references, using a language model under a task contract.
A Code node checks arithmetic and applies approval thresholds. It is deterministic and needs no model.
A Human node puts the exception in front of a reviewer when the purchase order is missing or the checks disagree.
A final Integration node records the approved outcome in the finance system.
One run of this workflow for one invoice is a case, or an execution. The workflow is the design. The case is the instance. That distinction matters for everything that follows, because the design is versioned and shared, while each case carries its own state, permissions and trace.
The shared representation
Opus keeps a documented, versioned representation of workflows, their tasks, the variables that flow between them and the context around them. We call it the Work Knowledge Graph, or WKG. The name invites two misreadings, so I want to introduce it carefully.
The WKG is a representation of work, not a particular database. Opus runs a graph data store, a vector retrieval service and a search index as separate storage components. The WKG is the model of what a workflow means; those services are among the places where parts of it live and are looked up.
It is also not a memory store. The relationships in the WKG say things like “this Agent node extracts fields from the output of that Integration node, into this schema, for this task class.” That is structural knowledge about the work. What an agent learned from previous cases is a different kind of knowledge, and I will treat it separately in Part 5 and Part 6.
Why does the structure matter? Because later decisions depend on it. When Opus decides which model should run the extraction node, it uses the node’s task definition and schemas from this representation. When a design agent proposes an edit, it reads the same structure. When a reviewer’s correction is evaluated, it is attached to a specific task in a specific workflow version. A shared, explicit description of the work is what lets the design, execution and improvement parts of the system talk about the same thing.
One case, end to end
Here is the lifecycle for one invoice. Treat it as a conceptual sequence rather than an exact trace of internal service calls.
Entry. The case starts through the web application, the API, or the Model Context Protocol (MCP) server that lets external agents invoke Opus. Other consumers such as chat, email and schedulers can start cases too.
Coordination. An execution manager works out which nodes are ready. The first Integration node runs. When it returns, the Agent node and any independent checks can be dispatched. Dispatch goes through an event stream to pools of workers, one pool per node type.
Waiting. If the purchase order is missing, the Human node is dispatched and the case waits. It keeps its state without holding an active worker while the reviewer takes their time.
Completion. The reviewer resolves the exception, the remaining checks finish, and the final Integration node writes to the finance system. The case has an output and execution evidence recorded under the applicable capture configuration.
The evidence comes back
Completing the case also produces execution evidence. That brings us to the idea that will recur most often in this series: capturing evidence is not the same as learning from it.
Execution traces support audit and diagnosis, with their recorded content and availability governed by the applicable capture, audit, access and retention configuration. Separately, some retained evidence may become reusable knowledge. A reviewer’s correction to a misread invoice date, for example, can be scored, reviewed and, if it qualifies, promoted so that later cases and later design sessions can use it. The decision to promote depends on quality, on where the knowledge is allowed to be used, and on who is permitted to see it. We call the decision point the promotion gate, and Part 6 is about it.
The same evidence informs model choice. If the extraction node repeatedly needs a reviewer to fix the same field, that is a signal about whether the assigned model is right for the task. Part 9 and Part 10 follow that thread.
The responsibilities around the edge
A few things apply to every step rather than to any one node.
Identity and authorization. Users arrive through the customer’s identity provider. In the design described here, authorization checks the requesting actor, resource and action at entry and during execution, including when a worker retrieves a file after an overnight wait. Part 7.
Data boundaries. Model inference goes through a model gateway, and the platform decides what data may leave the trust boundary and in what form. Part 8.
Versions. The workflow, its agents, its code and its integrations are versioned components with a delivery path from source control to activation in a workspace. Part 11.
Operational visibility. Traces, telemetry and cost signals are collected throughout.
The existing finance system. It stays where it is. Opus reads from it at the start and writes to it at the end. The workflow coordinates the work around it rather than replacing it.
Opus also includes Process Discovery, a Digital Twin and a Rewire Canvas. They belong to the design side of the lifecycle: understanding existing work before a workflow exists, and modelling alternative arrangements of it. I will locate them on the map and leave their internals for later articles.
What this series does not cover
Some questions an architect will rightly ask are out of scope here, because each deserves its own treatment rather than a paragraph: the threat model for agents that read untrusted documents and call tools, the isolation of customer-authored code, encryption, backup and recovery, and data residency. Where they touch the lifecycle I will say so, and they are subjects for later articles.
The map
The choice, and what it costs
The alternative to this arrangement is a composition of independent tools: an orchestration engine, an agent framework, a review queue, an evaluation service and a memory store, each good at its job. That composition is flexible and may be the right choice for a narrower task or a team that wants to pick each part. Its cost is that the integrating team has to maintain the links: which workflow version produced which trace, which permissions applied to which worker, which evaluation result belongs to which task definition.
Opus takes on that integration responsibility, and with it the complexity. Each of the following articles is about one of those links: what each subsystem does, and what obligation it passes to the next.
Next: the case above waited overnight for a reviewer while an integration was temporarily unavailable. What has to happen for a workflow to survive failures and a human wait? That is Part 2.