Enterprises spent the better part of two decades digging out of silos. Data warehouses, then data lakes. Single sign-on. Master data. One risk and compliance program instead of one per department. It was slow, expensive work, and it paid off: one view of the customer, one identity, one set of controls.
Solving it also built some of the most valuable companies in enterprise software. Snowflake and Databricks are the modern data warehouse and the modern data lake, the successors to the warehouses and Hadoop clusters of the 2000s. A generation of other platforms grew by joining up data that sat in separate systems so that decisions could draw on all of it. Enterprises paid for (and still pay for) silos twice: once to build them, and again to dig out.
AI agents are quietly rebuilding the silos.
Every major software vendor now ships its own agents. Each one sees the data inside its own application, follows the rules configured in that application, and records what it did in that application's log. So the CRM's agents are governed one way, the HR system's another, the service desk's a third. The same policy gets written several times, in several consoles, by several teams.
It's the old architecture again, with one difference: this time the silos can act. Siloed data slowed decisions down. Siloed agents make decisions that no one can see whole. And the problem shows up the moment a piece of work crosses more than one of them.
Who governs a workflow that crosses three AI platforms?
Consider an agent asked to prepare a supplier update. It retrieves contract terms from the warehouse, asks a model to summarize what changed, and proposes an edit in the procurement system. A second agent notifies the account owner.
One business task. Several systems. Multiple points where software acts on someone's behalf.
Each platform in that chain has permissions, logs and governance features of its own. The team accountable for the whole process still has to answer a different question: what authorized the work as it moved between them?
Start with the business task, not the tool inventory
An inventory of tools does not describe a workflow. Start with what the organization wants to accomplish, who owns the outcome, and which actions are permitted.
In the supplier example, reading a contract, drafting a recommendation, changing a record and sending a notification are four different actions. Authority to perform one does not imply authority to perform the others.
That distinction has to survive every handoff. When it disappears between systems, the workflow quietly becomes more powerful than the task its owner meant to delegate.
So draw the workflow first. At each step, name the owner, the execution identity, the data access, the tool permissions and the point of human review. Anything you cannot name is the first thing to fix.
Test the boundary, not the happy path
A successful demo shows that a workflow can finish. It says little about what happens when the work steps outside its scope.
Suppose the agent proposes changing a field it was only authorized to read. What prevents the dispatch? What does the reviewer see? If permission is granted, how long does it last, and which action does it cover?
Now pause the workflow after one system has accepted a write and before the next has acknowledged it. What has committed? What can be retried safely? Does resuming repeat an action?
A kill switch cannot answer those questions. Transaction boundaries can. Governed intervention means halting new dispatch at the right scope, letting in-flight work settle at a known boundary, placing what follows behind human approval, and recording all of it.
Open the record of one action
For every consequential action, it should be possible to connect the request, the execution identity, the authority, the policy decision and the result in one record.
If a person approved an exception, the record shows what they were shown and what they approved. If an action was refused, the record shows the refusal: evidence that the control fired, not merely that nothing happened.
Then ask where that record lives. Can the organization query it without the vendor's dashboard? Does it survive a change of model or agent platform? Evidence that only exists inside one vendor's interface is evidence the enterprise does not fully own.
Decide where governance should sit
If every agent, dataset and workflow lives inside one vendor's estate, that vendor's native governance is often the simplest answer.
Most enterprises are not built that way. Their workflows cross clouds, warehouses, SaaS platforms and custom code. There, governance has to sit at the level of the work itself: one identity and authority model, policy checked before dispatch, and one execution record that follows the transaction across every boundary it touches.
It's the same lesson the last twenty years taught about data and identity: let each application do what it's good at, and keep the controls that span them in a layer the enterprise owns.
That layer also has to be independent in three separate senses: where it is deployed, which vendors it depends on, and what format the evidence is kept in.
Where Operon fits
Operon Studio was built for exactly this layer. It brings building, running and governing agent work into one system: authoring across visual, natural-language and code surfaces; a runtime that spans models and environments; and a control plane that checks policy before every action, routes exceptions to people, and records every governed decision in an Evidence Data Trace.
It governs the agents an enterprise already has, imported or wrapped where they run, and deploys wherever the boundary needs to be: managed cloud, a customer VPC, a data-platform Native App, or fully air-gapped.
The useful next step is concrete: bring one workflow, name the systems it touches, and work through where authority, enforcement and evidence sit today.