Series · Thirteen parts
Opus, powered by its Work Knowledge Graph and Large Work Models, generates a workflow for a business process and then runs it. This series takes the system apart one piece at a time — the executor underneath it, the agents that fill its steps, what those agents remember, who is allowed to act and on what, how a model is chosen for a task, and how the whole thing is packaged, deployed and released.
One workflow, thirteen ways in
Every part follows the same hypothetical supplier-invoice exception workflow: an Integration node retrieves invoice and purchase-order data, an Agent node extracts and interprets fields, Code nodes check arithmetic and approval thresholds, a Human Task handles the exception, and a final Integration node records the outcome. Holding one example still is what lets each part change only the question being asked of it — how the wait is held, whose permission is exercised, what the reviewer’s correction is allowed to teach. Each summary below links to its own page, and each of those links to the article on Substack.
01
Part 01
Follow one supplier invoice through orchestration, human review, policy controls and a learning loop and see why the joins matter more than the parts.
The map for the series. One invoice turns out to combine five kinds of work — integration, judgement, deterministic checking, human approval, and a write that must not happen twice — and the article names every part it passes through before conceding what assembling best-of-breed tools would cost instead.
Durable state, typed workers and explicit failure policy keep business work moving — even when a reviewer takes the night.
A missing purchase order, a briefly failing finance API and an arithmetic check ready to run, all in the same case. The real question is not whether Opus needed durable execution, but why the team built the executor rather than adopting one.
02
An agent is more than a prompt: it assembles governed context, acts through tools, checks its work and leaves evidence behind.
Two near-identical invoices arrive in two workspaces that must not see each other’s context, and the right behaviour differs because of what lives outside the instruction. The article is candid that the invoice itself is untrusted input.
People and specialist agents can design together only when proposals, conflicts and authoritative state are explicit.
A process specialist proposes a node that reads checked_total while design agents concurrently rename that field to validated_total. Each edit is sensible against the current workflow, and they do not fit together.
03
Useful memory is not the largest context window; it is the smallest relevant, permitted view for this actor and task.
A team’s screen-layout preference, an organization’s connection pattern and another customer’s invoice data are all things an agent could remember. Getting the first wrong annoys a team; getting the third wrong is a data-isolation failure.
A reviewer’s correction becomes reusable only after quality, scope and permission checks not merely because it was observed.
A reviewer notices the extraction agent recorded the service-period start as the invoice date, fixes it and approves the case. Keeping that case is obviously useful; whether it should change the fifth invoice from the same supplier is the interesting question.
04
A permission checked at the front door is not enough when work crosses services, waits overnight and resumes under changed access.
An analyst starts the case on Tuesday afternoon. That evening their access to the workspace is removed. On Wednesday morning the case resumes and writes to the finance system. Whose permission is being exercised?
Stable semantic aliases can hide identities while preserving the relationships an external model needs to reason about.
Spotting a duplicate invoice depends on relationships: same supplier, same account, overlapping service period. Replacing each of them with [REDACTED] destroys exactly the information the task needs.
05
For a known, repeated task, model choice belongs in the versioned design with runtime escalation reserved for the difficult tail.
The extraction node does one thing thousands of times a month against an unchanging task definition and accuracy bar. Deciding on every invocation which model should run it is both wasted work and unpredictable.
Task-specific evidence, uncertainty and the full cost of error turn model selection from a leaderboard guess into an architectural decision.
Two candidates both produce perfectly schema-conforming output. One confuses the service-period start with the invoice date about once in ten cases; the other gets dates right and costs many times more per call.
06
Source control records what changed; the build pipeline identifies the resulting artifact; activation policy decides which workspace may run it.
A better extractor passes evaluation, but three workflows use the current one — and one of them is in a quiet-period freeze while another belongs to a pilot owner who has never heard of the change. Publication and use have to be separate decisions.
The service boundaries stay stable while cloud products change.
Two customers want the same invoice workflow, one on AWS with strict private-subnet rules and one on Azure wanting to self-operate. The workflow does not care; the infrastructure beneath it does, and pretending otherwise is how deployments go wrong.
One release model serves managed and customer-operated estates by changing repository ownership, review authority and promotion control.
One release must reach an estate the Opus team runs and one where the customer’s own engineer must review and promote everything. Both expectations are legitimate; serving them from one process, so the environments do not drift into two products, is the engineering question.
Taken together the thirteen parts describe one claim: that generating a workflow is the easy half. The hard half is everything that has to hold while it runs — an executor that can wait overnight, agents that terminate with output the next node can use, memory scoped to where it is true, authority that is rechecked when the work resumes, identifiers protected without severing the relationships between them, a model chosen on task-specific evidence before the run rather than by reflex during it, components that are published and activated separately, and a release that can be reviewed by the engineer who owns the cluster. None of the parts is unique alone; the value and the obligations both sit in the interfaces. The papers give the formal side of the same work.
—