Inside Opus · Part 6 of 13
This series follows a hypothetical supplier-invoice exception workflow. Part 3 separated an agent’s output from what the system later learns from it. Part 5 explained where learned knowledge may be used. This article is about how an observation qualifies to become knowledge at all. Part 1, “A piece of work through Opus”, is the map.
One correction
A reviewer opens an exception case. The extraction agent has recorded 3 March as the invoice date. The reviewer sees that 3 March is the start of the service period printed in a table, and the actual invoice date, 28 March, is in the header. She corrects the field and approves the case.
Two things could be true about this correction. It could be a one-off: an unusual layout, a single misread. Or it could be the fourth time this month that this supplier’s invoices have produced the same confusion, in which case there is a repeatable extraction problem worth doing something about.
Keeping the corrected case is obviously useful; the finance record is now right. The more interesting question is whether, and how, the correction should change what happens to the fifth invoice.
The requirement
The system has to capture what happened, identify which observations point to a repeatable pattern, evaluate whether acting on the pattern would help, decide where the resulting knowledge may be used and by whom, and then make it available to later agents in a form they can act on. And it has to do this without letting a single bad correction, or an unreviewed output, teach every future agent something wrong.
Evidence from both sides
The evidence does not come only from execution. Under the applicable capture and audit configuration, the intelligence stack can draw on events from across the platform: agent executions and their outputs, human reviews and their decisions, workflow edits and design-session interactions, scoring outcomes, failures, cost and latency, integration usage and marketplace activity.
For the invoice case, recorded runtime evidence can include the agent’s output, the reviewer’s correction, the time the review took and the cost of the invocation. The design side contributes something too: if a designer later adds a date-disambiguation step to the workflow, the accepted edit and recorded discussion around it are evidence about how the team responded to the problem.
Having both sides in one place helps assess whether a recurring correction became less frequent after a design change.
Capture is not learning
What is recorded, who can access it and how long it remains available depend on the applicable capture, access, audit and retention configuration. For retained cases, the available traces can support audit and diagnosis, including questions such as “what did the agent see, and what did it produce?”
But storage does not make an output an approved example. The agent’s original output, with the wrong date, is in the trace. So is the reviewer’s correction. If the trace as a whole fed straight into future behaviour, the system would be learning from its own mistake alongside the fix. The trace has to be interpreted before it can teach anything.
Scoring and review
Interpretation happens through several workers that consume the captured events.
Agent scoring grades each execution against precision, accuracy, completeness, speed, cost and the human-review outcome. The invoice extraction gets a lower accuracy score because a reviewer changed a field.
Human-review analysis compares reviewer decisions across users and time, within what the customer’s configuration permits. If several reviewers have corrected the same field on the same supplier’s invoices, that is consensus about a repeatable error. If reviewers disagree about how to treat a field, that is a contradiction worth surfacing rather than a pattern to learn.
Workflow insights evaluate workflow versions against an evaluation framework, organizational policy and historical execution performance. This is how a later design change can be assessed for whether it helped.
Together these produce candidate patterns and evaluation signals. A candidate pattern for our example might read: on this supplier’s invoices, the invoice date is in the header and the service period is in the line-item table.
The promotion gate
A candidate pattern is not yet knowledge. It has to pass the promotion gate, which every article so far has mentioned and this one can describe.
The gate asks three questions. Is the pattern good enough? That is a quality assessment based on the scores and review evidence above, and it can be made by a human or by an evaluating agent. Where may it be used? That is the scope question from Part 5: is this a workspace pattern, an organizational one, or something abstract enough for the platform? Who may see it? That is a permission question, and the answer constrains the scope.
Only reviewed traces, corrected outputs and evaluated patterns pass. The agent’s original wrong output does not become an approved answer to imitate. A reviewed failure can still be useful negative evidence under the same quality, scope and permission requirements. The reviewer’s correction, confirmed by the consensus across reviewers, can become a positive example.
For the invoice date pattern, the likely answer is a workspace-scoped agent learning: it concerns one supplier’s documents in one team’s workflow. If the same supplier’s invoices turn up in other workspaces, promotion to the organization scope becomes a question, under the organization’s permission rules.
Back to design and runtime
Once promoted, the pattern has to reach the agents that can use it.
Promoted learnings are indexed alongside workflows, agents, code, integrations, human tasks and previous decisions, so that semantic search can retrieve them at design time and at run time. The Work Knowledge Graph supplies the structural context: which task, in which workflow version, the pattern relates to. The two are different roles. The graph says where the pattern belongs in the work; the index makes it findable by meaning; the learning process described here is what put it there.
At run time, the extraction agent’s cognitive layer (Part 3) can now select the pattern when it processes this supplier’s next invoice. At design time, a prompt-engineering agent in the workflow room (Part 4) can recommend a guideline or a skill based on it.
Did it help?
The measure of success is not the number of events captured or patterns promoted. It is whether the fifth invoice from this supplier is extracted correctly, and whether the reviewer spends less time on cases like it. Repeat-error rate and reviewer effort are the signals that matter: how often the same correction recurs, whether accuracy on the task improves, and how long reviews take. Those are the measurements that assess the mechanism. This article describes the mechanism; it does not report results.
The alternative, and the cost
Independent logs, manual prompt changes and a separate evaluation system can work well, especially at small scale. A team that notices the date problem in its logs, edits the prompt, and checks the next week’s results has closed the loop by hand. Many teams should start that way.
Connecting the evidence inside Opus supports a common improvement process across many workflows and many teams, with the promotion gate as the shared discipline. The costs are review effort, indexing and retention, and the risk of mistaken generalization: a pattern true of one supplier being promoted as if it were true of all. The gate reduces that risk; it does not remove it.
Next
A promoted learning is reusable context. Reusable context is useful only if every later action that uses it still respects access permissions, including actions that happen after a long wait, on another service, for a user whose access has changed. Part 7 is about authorization that follows the work.