Inside Opus · Part 11 of 13
This series follows a hypothetical supplier-invoice exception workflow. This article continues with a hypothetical improved invoice extractor, evaluated using the approach in Part 10, and follows how that version reaches the workflows that use it. Part 1, “A piece of work through Opus”, is the map.
Publishing is not deciding
Suppose an engineer improves the invoice extraction agent using a fine-tuned candidate that passes the evaluation described in Part 10. In this hypothetical continuation, the new version handles the header-date and service-period confusion from Part 6 by design rather than by learned correction, and performs better on the held-back cases.
Three workflows currently use the extractor: the exception workflow this series follows, a high-volume straight-through workflow for routine invoices, and a pilot in a different department. Each has a different owner and a different appetite for change. The exception workflow’s team wants the fix now. The straight-through workflow is in a quiet-period freeze. The pilot’s owner has never heard of the change.
If publishing the new version silently replaced the old one everywhere, the freeze would be broken and the pilot owner would be debugging an unexplained behaviour change. Publication and use have to be separate decisions.
The requirement
Components must be versioned, must move from authoring to production through reviewable steps, must be discoverable for reuse without being forced on anyone, and must be usable in a workspace only when someone with authority over that workspace has said so. And the component in question is not just code. It might be a prompt, an integration, a human-review interface or a whole workflow.
The unit of delivery is wider than code
The first adjustment, if you come from application delivery, is to what counts as software. In Opus, workflows, agents, code tasks, integrations, human tasks and review interfaces are all versioned assets with operational effects. A change to the extraction agent’s prompt is a production change. So is a change to the review screen a human task shows, or to the integration that writes to the finance system.
We call the arrangement that treats all of them this way the Open Code Architecture. The name refers to open engineering access and controls, in the sense that components can be built, versioned and governed with ordinary developer tooling outside the platform. It does not mean the platform is open source.
From authoring to source control
There are two ways to author a component. One is inside the Workflow Builder, where a designer or a design agent (Part 4) creates or edits it directly. The other is off-platform: an engineer works locally in an editor such as VS Code, with language-model assistance, and structures the component using a skills file that describes its method. Both paths are legitimate. The off-platform path is what gives engineering teams the controls they already trust.
Those controls are the ordinary ones. The component is committed to a source-control repository (GitHub, GitHub Enterprise or plain Git), reviewed through a pull request, merged, built, and promoted through development, staging and production environments by a continuous-integration pipeline. Each stage records exactly which component revision it runs.
Source control becomes the source of truth for the component’s history. A component created in the builder can be exported to it, and a component managed in it can be synchronized into Opus.
Publication makes it available
Once a version is ready, it is published into the organization’s marketplace. The marketplace is an internal registry of governed, reusable components: agents, code, integrations, human-task patterns and their versions. Publication registers the new extractor version alongside the previous ones. It does not replace them; each marketplace item can hold multiple versions, and the organization controls which are published.
A verified organization, meaning one whose identity the marketplace operator has confirmed, can also publish approved versions into a public marketplace. Another organization can clone a public component into its own marketplace, where it becomes that organization’s asset, subject to its own review, governance and activation controls before any workflow can run it. I mention this for completeness; the invoice extractor is staying internal.
Activation makes it usable
Here is the step that answers the opening problem. A component in the marketplace is available. It is not usable in any workflow until it has been activated into the relevant group or workspace.
Activation is a decision made by whoever has authority over that group, under the access model from Part 7. The exception workflow’s team activates the new extractor version in their workspace and adopts it. The straight-through workflow’s team leaves the previous version active until the freeze lifts. The pilot’s owner, when they next look at their workspace, sees a newer version available in the marketplace and chooses when to evaluate it.
Publication says “this exists and has been approved for the organization.” Activation says “this workspace may run it.” Keeping them separate is what lets creation, review, publication, activation and runtime use have different owners.
Reuse without rebuilding
Once activated, a component version is referenced by the workflows that use it, not copied into them. The same extractor version can be used by several workflows and several workflow versions. When the exception workflow’s designers reference the new version, they are pointing at the marketplace item, and the workflow version records which component version it uses.
That explicit reference is what lets the platform answer the questions that matter later: which workflows are running which version of the extractor, and which cases were processed by which version.
Change management
Connecting tests and release promotion to a shared component’s lifecycle is what manages the risk of changing it. The held-back evaluation from Part 10 is a test gate; the staging environment is another; activation is a third, in the hands of the people who bear the consequences.
Two behaviours follow from explicit version references. A workflow that references a specific component version keeps running that version until someone changes the reference; publication of a newer version changes nothing on its own. And rolling back is a matter of re-activating the previous version and pointing the workflow at it. What happens to cases already in flight at that moment is governed by the workflow’s own settings, and it is worth understanding before relying on a rollback in production.
The alternative, and the cost
Direct edits inside a builder are convenient and appropriate for prototypes, small teams and low-consequence workflows. Nothing about the argument above says a team must run a pipeline to change a prompt.
Source-managed, versioned components pay off when several workflows share a component, when changes need review, or when someone has to answer for what was running when. The costs are release overhead and the need to keep builder edits and source-control changes reconciled, which is real work when both paths are in use.
Next
Activated components run somewhere. Part 12 is about what that somewhere contains, which parts of it stay the same between customers, and which depend on the cloud they run in.