The past couple of weeks have stirred things up among the major players in frontier AI, and a few who would like to be counted as major players. Those models matter. Make no mistake about that. They are also no longer the only show in town. Open-weight models keep improving, and AI-capable commodity hardware is available to anyone willing to pay for it (admittedly, it is still pricey).
I am not going to get bogged down in the regulation debate on AI safety here. I am not a doomer, and I am not a starry-eyed futurist who sees no downside. Every technology that brings promising change to humankind also has a dark side, so I land somewhere in the middle.
That debate is not the point of this post. The point is lock-in. If your development organization has embraced agentic development, or is seriously considering it, ask what happens when your model vendor changes its pricing, its terms, or what its models are allowed to do because a regulator got overzealous. If the answer is “our whole workflow changes with it,” you have a problem, and it sits in the middle of how your team ships software.
The model should be a configuration choice
Most teams adopt agentic development by adopting a vendor’s tool. The prompts, the habits, the review practices, and the institutional knowledge all grow up inside that tool. Switching later means starting over.
The alternative is to keep the engineering process in your own repository and treat the model as a setting. That has been the focus of my work with clients and at O’Side Systems for a while now, and it is the reason for the relaunch of CTOsphere as a suite of agentic infrastructure tooling. The suite is organized as four planes, and each one can be adopted on its own.
The first is agent orchestration. A runtime watches your issue tracker, isolates each ticket in its own workspace, and runs a coding agent under a workflow contract that lives in the repository it governs. The contract is versioned and reviewed like any other code. It also decides which backend handles which stage of work. A cheap model can triage, a frontier model can implement, and a local open-weight model can take whatever you are not willing to send off premises. Changing any of those is a reviewed change to a file. The agent opens a pull request, and a human merges it. The orchestration core is headed for open source.
The second is decision context. Your standards, policies, and architectural decisions are kept as versioned records beside the code and served to agents at plan time, so an agent about to change a service reads your reasoning instead of guessing at it. Each decision records what you expected to happen, and that expectation gets scored later against what actually happened. This is how organizational intent gets into agent-written code, and it stays yours no matter which model reads it.
The third is fleet configuration. One orchestrator becomes several faster than you would think. The control plane is GitOps for agent fleets: one authoritative registry, reproducible per-instance configuration, and pull-based delivery to runners that accept no inbound connections. It is defined against an open orchestration specification rather than against our codebase, so the neutrality argument applies to us too.
The fourth is observability as code. What ran, what it cost, and whether it did what you expected, with dashboards and alert rules kept as versioned artifacts. Every run leaves a trace you can audit. When the numbers say a standard needs to change, the system proposes the change and a person approves it.
All of it runs in your infrastructure, with your keys and your agreements with whichever vendors you choose.
The adoption gap on your own team
There is a second problem hiding behind the first. AI adoption inside most teams is uneven. Some engineers have fully embraced agentic development. Others still use it as glorified code completion. The result is inconsistent output and a process that depends on who picked up the ticket.
The fix is to put the engineering back into software engineering. Shift the human effort left, into the creative parts of the job: requirements, design, architecture, and the determining the tradeoffs behind them. Then make code generation the consistent part, run the same way for everyone, against the same standards, with the same review gates. A well-written ticket and a recorded decision become the work product that matters most; the parts that need judgment stay human.
This is an organizational change more than a tooling change, which is why CTOsphere is delivered as hands-on implementation. We start with a readiness assessment of how your teams actually build. Then comes a fixed-scope pilot with one team and a defined outcome, measured in merged pull requests. Rollout follows once the pilot has earned it.
Don’t paint yourself into a corner
I use products from Anthropic and OpenAI every day. They are great products, but I still don’t want to be locked into either of them, and I don’t think you do either.
If you want agentic development that is consistent across your team, traceable from ticket to merge, and cost-aware, without being beholden to any single vendor, reach out at ctosphere.com or using the O’Side Systems contact page. We can help you get there.