I’ve been arguing that as code generation gets cheaper and orchestration becomes part of the tools we already use, governance is where engineering teams still need to invest. That needs a little more precision. The platforms are bundling governance too.
That’s useful. I’d rather use a well-supported control than spend engineering time maintaining another version of it. But I still want to know what happened and whether it met our standards. I also want that record to survive a change of tools.
Those requirements don’t disappear because the dashboard comes with the subscription.
On October 6, GitLab announced its governed software factory capabilities, connecting agent workflows with security controls and a record of how changes move toward production. Its Impact Analytics, now in early access, reports AI cost and impact by team, task, and model. For a team already delivering through GitLab, that could remove a lot of integration work. I’d take it seriously.
GitHub followed on October 7 with generally available local sandboxing for Copilot, included at no additional cost. Organizations can enforce access restrictions that developers can’t weaken. I’d evaluate that before building my own.
Atlassian and OpenAI are extending that integration into work planning. Their expanded partnership includes plans to explore deeper Jira integration for assigning work to agents and reviewing the results. The announcement describes work still being explored, but the direction is clear enough: more of the delivery process will happen inside the platforms teams already use.
My read is that a separate orchestration product will have to earn its place. Wrapping another interface around the same agents won’t be enough. The useful work is in the gaps between systems and in giving teams control over the standards they apply to all of them.
Consider a change that starts in Jira and runs through an agent on a developer’s machine. It lands in a repository with checks running elsewhere. Each tool can report on its part. Someone still has to connect the requested work to the permissions used and checks performed. The decision to accept the result needs to be traceable too.
A sandbox handles one part of that problem. It limits what a process can do within its configured boundary. Your team still has to decide which permissions a task needs and who can approve an exception. It also needs a way to verify that the intended restrictions were actually in force. Buying the control doesn’t assign that responsibility.
The same applies to analytics. A vendor’s dashboard can contain useful, accurate data. I’d use it. I’d also want to understand how it defines success and whether I can compare those results with work performed outside its platform. A completed agent run and an accepted production change are different outcomes.
The review work is already happening. In Stack Overflow’s 2026 Developer Survey, 76.5% of respondents to the verification question said they run AI-generated answers locally before using them. Another 63.9% compare them against the codebase. About two-thirds of respondents to the tool-switching question had changed AI tools for work in the past year.
That combination matters. Engineers are checking the output while the tools producing it keep changing. If the record of those checks stays inside each tool, the team has to reconstruct it whenever someone needs to understand a decision later.
I’d start with one record per change. It should connect the task to the version of the code the agent worked against. Include the tools and permissions used, with results from the checks that ran. Approvals belong there too, along with exceptions and the changes a human made before accepting the work. Missing information should be visible.
The agent’s summary can be part of that record. Test results should come from the test runner. Approval history should come from the system that recorded the approval. Keeping the source of each claim matters because a confident summary can hide a failed check just as easily as an incomplete log can.
Independent evidence doesn’t mean refusing everything a vendor produces. It means retaining records you can inspect and checking consequential claims against the systems that observed the work. Exporting an agent’s own account into a file you own doesn’t make it independently verified.
There are three things I’d keep under the team’s control:
- Policy that states what agents may do, where approval is required, and who can grant it, with versions retained outside any single tool’s settings.
- Evidence that uses a consistent structure across tools, preserves its sources, and can be exported without losing the links between a task and its outcome.
- Evaluation based on the team’s own work and acceptance criteria, including review effort and rework alongside execution cost.
Owning these doesn’t require inventing a new file format. Use existing formats where they fit. Your team needs to retain the information in a form it can use without depending on one vendor to interpret it.
There is a cost to this. Connecting records across systems takes work, and some controls won’t translate cleanly between tools. I’d accept that cost where it makes a future change manageable. I wouldn’t build a second version of every feature the platform provides just to claim independence.
Owning the evidence won’t make a migration disappear. It does mean you can carry your standards and history into the next decision instead of rebuilding both from memory.
This is also shaping my thinking about CTOsphere and its execution runtime, Sinfonia. The priorities I’m taking from it are adapters for external workflows, an exportable evidence record, and evaluation against a baseline. Those are development priorities, and they should be judged by whether they help a team understand and improve its actual delivery process.
The same standard applies to anything I build. If leaving CTOsphere means losing the history needed to evaluate your engineering work, I’ve created the dependency I’m arguing against.
You can start testing this without adopting another platform. Pick five to ten tasks from your own backlog and run them through two workflows with the same acceptance criteria. Record the review time and fixes needed to get each result accepted. Treat that as an initial comparison; expand it before making claims about the whole organization.
At O’Side Systems, I help teams map these dependencies, define agent execution policies, and set up evidence and evaluation around the tools they already have. If that’s a decision you’re working through, reach out so we can talk about it.
Before committing more of your delivery process to one platform, export the record of a single completed change. Have another engineer explain what happened using that record. What they can’t establish is the first gap to address.