Inside Opus · Part 3 of 13
This series follows a hypothetical supplier-invoice exception workflow. This article is about the Agent node that extracts fields from the invoice and interprets ambiguous references, such as a supplier name that does not quite match the vendor master. Part 1, “A piece of work through Opus”, is the map; Part 2 explained how the executor dispatches this node.
Two invoices, two workspaces
Two invoices arrive in different workspaces. Their text is similar: same layout, same supplier, similar amounts. But one workspace belongs to a team that has told Opus, through past corrections, that “service period” and “invoice date” are frequently confused on this supplier’s documents. The other workspace has an organizational guideline that supplier names must be resolved against the vendor master before any downstream step. And the two workspaces are not permitted to see each other’s context at all.
The task instruction is the same in both cases: extract these fields into this schema. But the right behaviour differs, and the difference lives outside the instruction. That is the problem an agent runtime has to solve: the prompt is only part of what the agent needs.
The requirement
An agent invocation must assemble the context that is relevant to this task and permitted for this actor in this workspace, do the work, check the result against the task’s requirements, return output the next node can consume, and leave evidence that can be reviewed later. Each of those clauses is a design decision, and I will take them in order.
The task contract
Every Agent node has a static definition: an input schema, an output schema, a task definition and execution settings. The executor supplies an input payload that conforms to the input schema and expects an output payload that conforms to the output schema. For the extraction node, the input is the retrieved invoice content and the results of the purchase-order lookup; the output is a structured record with fields such as supplier, invoice number, invoice date, service period, line items and totals.
The contract is what lets the rest of the workflow treat the agent as a node rather than a conversation. The Code node that checks arithmetic consumes schema-defined fields without depending on how they were extracted.
Building permitted, relevant context
Between the input payload and the first model call sits what we call the cognitive layer. Its job is to assemble the context the agent will work with, drawing from several sources:
the agent definition itself;
applicable guidelines, which are behavioural rules and constraints from platform, organization, workspace and agent-level governance;
relevant skills, which are structured methods for a task category;
prior learnings, which are patterns extracted from reviewed executions;
organizational and workspace context;
the workflow’s structure and ancestry from the Work Knowledge Graph, so the agent knows where its task sits;
the model assignment for this node, which comes from the routing settings covered in Part 9.
The important word is permitted. In the design described here, the cognitive layer selects context for relevance, current scope and actor permission. In this example, that means using the first workspace’s learning about service periods for its own invoice without sharing it with the second workspace. Part 5 is entirely about how that scoping works, so here I will only say that the selection is a filter on relevance and permission together, not a search over everything the platform knows.
The loop
With context built, the invocation proceeds through a loop rather than a single call.
Context construction. The cognitive layer assembles the material above, with retrieval from memory and prompt-cache optimization where the settings allow.
Completion. The assigned model is invoked.
Tools. If the task calls for it, the agent uses tools. For the extraction node, that might be a lookup against the vendor master to resolve “Northwind Ltd” to a vendor identifier.
Temporary state. Intermediate results are held for the duration of the invocation.
Judging. The output is checked against guidelines and for accuracy against the task’s requirements. If it fails, the loop can iterate.
Output formation. The result is shaped to the output schema and returned to the executor.
The judge step is what turns a model response into a node output. It can catch a schema violation, a guideline breach, or an extraction that contradicts the input. What it cannot do is guarantee correctness. It is a check against specified conditions, and its value depends on how well those conditions are specified.
The document is untrusted input
The invoice itself deserves a word. It is content from outside the organization, and an agent that reads it and then calls tools is acting on that content. Two of the mechanisms above bear on this. In the described authorization design, tool calls are checked as actions by a subject on resources (Part 7). Permission to look up the vendor master comes from the actor’s scope, not from instructions in the document. And the judge checks the output against the guidelines, so a response that breaches them can be caught before the next node consumes it. Neither makes a model immune to instructions embedded in a document. That threat model deserves an article of its own.
Four things that are easy to conflate
Four terms describe the knowledge an agent draws on, and they have different lifecycles. They are worth keeping apart.
Term: Memory
What it is: Persistent context from prior executions, states and reviews
How it changes: Continuously, under retention policies
Term: Skill
What it is: A structured method for a task category: steps, reasoning patterns, tools
How it changes: Deliberately, through engineering or training
Term: Guideline
What it is: A rule or constraint governing how executions are conducted
How it changes: Rarely, through governance or policy change
Term: Learning
What it is: A generalized pattern extracted from evaluated executions and feedback
How it changes: Continuously, from evaluation and review
Caching is different again. It reuses computation, such as a previous retrieval or a cached prompt prefix, under its own conditions. It is a performance mechanism, not a form of knowledge.
The distinction matters when something goes wrong. If the extraction agent keeps confusing two date fields, the fix might be a learning (this supplier’s invoice date is in the header and its service period is in the line-item table), a skill (a method for date disambiguation on invoices), or a guideline (never infer a date that is not printed). Each has a different owner and a different rate of change.
The output is not the lesson
The invocation ends when the output payload goes back to the executor. Its observable inputs, selected context, tool actions, checks and outputs can be recorded in a raw trace, subject to the applicable capture and audit configuration.
Recorded traces are available for observability and audit under the applicable access and retention configuration. A trace is not, on its own, a learning asset. Learning requires a further step: a human or agent review that confirms or corrects the output, and an evaluation that decides whether the pattern is worth keeping and where it may be used. We call this the promotion gate, introduced in Part 1 and followed in detail in Part 6.
The separation is deliberate. If raw traces fed directly into future behaviour, a bad extraction could reinforce the same error in later cases. Review, correction and evaluation provide the evidence for deciding what may pass the promotion gate.
Agent evaluation sits alongside the loop. It compares outputs against task requirements, reviewer feedback, policy expectations and historical performance, and its signals feed later routing, prompting, skills and guidelines.
The alternative, and the cost
A stateless prompt, or a straightforward retrieval-augmented call, is sufficient for many bounded operations. If the task is “classify this text into one of five labels” and the labels never change, the loop above is overhead.
The richer loop earns its place when context has to be selected under permission, when tools are needed, when the output has to be checked before the next node consumes it, and when the invocation has to leave evidence that review can act on. The cost is latency from context construction and judging, evaluation effort to keep the checks meaningful, and more moving parts to operate.
One limitation is worth stating. Everything described here is observable from outside the model: the inputs selected, the tools called, the checks applied, the output returned. None of it depends on seeing the model’s private reasoning, and a description of the agent should not rely on that.
Next
The runtime agent needs a well-defined task to execute. Someone has to write that task definition, choose the schemas and place the node in the workflow. In Opus, that is done by people and design agents working on the same canvas at the same time. Part 4 is about how they avoid overwriting each other.