Beyond Coding Agents: Why Enterprises Need a Vendor-Agnostic Agentic Software Factory
Every other post on this blog describes a factory I actually run: one operator, one primary coding agent, a set of hooks and gates, watching real production systems. This post is different. It describes an architecture I am designing and exploring, not a finished platform. Pieces of it already run in my own factory; most of the enterprise-scale version here, spanning multiple agents, vendors and teams, is still on the drawing board. I am writing it down because the problem it answers is becoming visible faster than the tooling to solve it.
The problem no one is naming yet
The question that mattered a year or two ago was whether an AI could write working code inside a real repository. That question is becoming increasingly settled. Claude Code, Codex, Gemini's coding tools, Copilot, Cursor, OpenCode and a growing list of local models can all do it, several of them well.
What happens next inside a real organization is less discussed. Enterprises rarely adopt one coding agent by decision. They accumulate several, one team at a time: Copilot in one team's IDE, Claude Code from a senior engineer's terminal, a local model for anything that cannot leave the network, Cursor because a contractor brought it. That is simply how tool adoption happens.
Each tool arrives with its own credentials, its own idea of a permission, its own cost meter, and its own audit trail, or none at all. Multiply that by the number of teams and active projects, and the real question stops being "how do we get an AI to write code." It becomes:
How do we safely govern many AI agents, from many vendors, across many teams and projects, under one security posture and one audit trail?
That is a governance and platform question, not a model question. A platform tied to one coding-agent vendor cannot fully solve the vendor-neutral governance problem.
A control plane, not another agent
The proposal here is not a better coding agent. It is a layer that sits above all of them: a vendor-neutral engineering control plane. Model and agent requests are brokered through the enterprise control plane rather than directly carrying provider credentials from the developer workstation. A request passes through identity, authorization, a gateway and an orchestrator, and only then reaches whichever coding agent and model are approved for that role on that project.
Developer / Engineer
v
Enterprise SSO (fail-closed: no session, no access)
v
RBAC + Project Authorization
v
Central AI Gateway <---- Admin-controlled Model-to-Role Policy
v
Agentic Orchestrator
v
Phase -> Wave -> Task planning
v
Parallel isolated workers (Claude Code / Codex / Gemini / Copilot / Cursor / OpenCode / local LLM)
v
Testing + independent review + evidence gates
v
Deployment
v
Production monitoring
v
Incident feedback ---> Learning ---> back into orchestrator policy
Two details in that diagram carry most of the weight. SSO here is fail-closed: no valid session means no access, not degraded access. And the gateway is the only place that ever holds a real provider API key. A developer's laptop should never hold one. If it does, the control plane has already failed, regardless of how good the dashboard looks.
The orchestrator turns a requirement into a plan, breaks that plan into phases, each phase into waves, and each wave into tasks small enough for a single agent run to be verified on its own. Parallel workers, which may be different coding agents from different vendors, execute those tasks in isolation. Testing, independent review and evidence gates stand between a worker's output and anything shipping.
Nine ways of working, chosen and not forced
Not every task needs the same shape of workflow. A one-file bug fix does not need the same structure as a cross-cutting refactor, and a production incident investigation looks nothing like either. The architecture assumes nine governed agentic patterns, and lets the orchestrator choose or combine them based on the shape of the task, instead of forcing every problem through whichever workflow a given tool happens to ship by default.
- Tool Use — a defined tool via a typed contract, not open shell access.
- ReAct — reason, act, observe, repeat, inside a bounded loop.
- Reflection — a draft is critiqued before it is accepted.
- Planning — a requirement becomes an explicit, ordered plan before any code is written.
- Orchestrator — one process coordinates several agents without implementing anything itself.
- Sequential Chain — one stage's output becomes the next stage's input, in order.
- Fan-Out / Fan-In — a task splits into parallel workers, then results are merged.
- Hierarchical — an orchestrator supervises team leads, who supervise workers.
- Controlled P2P Mesh — a few agents negotiate directly, inside a loop limit and timeout.
None of these is "the" pattern. A one-file bug fix is Tool Use and nothing else. A cross-cutting refactor across a dozen files fits Fan-Out / Fan-In. A production incident investigation looks like ReAct with a tight loop limit. Choosing the pattern, or combining two of them, is the orchestrator's job on a per-task basis, not a decision baked once into the tool.
What "enterprise-grade" actually requires
Once several agents from several vendors are operating under one control plane, a long list of capabilities stops being optional. Grouped by concern, rather than listed flat, they look like this.
Identity and access. Fail-closed SSO, RBAC and project authorization, no provider API keys on developer laptops, and a central AI gateway that is the only holder of real credentials.
Model and vendor governance. An admin-controlled model-to-role mapping, so generation and independent-review roles are explicitly separated and governed, plus a fallback policy so a role keeps working when a provider is degraded or deprecated. Vendor independence is the principle underneath both.
Execution and scale. A central MCP toolshed so tools are governed once, not once per agent, tool and network allowlisting, isolated project and worktree execution so one project's agents cannot see another's code or secrets, one common factory state plus isolated state per project, and parallel projects and agents that do not interfere with each other.
Reliability and control. Task budgets and token or cost controls, a session heartbeat with ghost-work prevention so a process that looks busy but has silently died is never trusted, emergency pause, resume and abort, and wave-based orchestrator rotation, so a single long-running coordinator never accumulates enough context to start deciding worse.
Handoffs and context. Compressed, structured handoffs between waves instead of full transcripts, on-demand context retrieval instead of loading everything up front, governed ReAct with a real loop limit, and controlled peer-to-peer collaboration with explicit limits, so two agents cannot talk indefinitely without producing anything.
Quality and evidence. Architecture constraint validation, secret and privacy protection, independent reviewer separation so the agent that wrote a change never approves it, build, test, lint and security gates, and evidence-driven completion: a task is done because a real test or log proves it, not because an agent says so.
Consistency and memory. A standard frontend component registry, durable task states with retries and idempotency, reusable skills and playbooks, and one canonical event and audit trail spanning every agent and vendor.
Visibility and learning. An engineering and management command-center dashboard, production monitoring in the same spirit as the Pehredaar-style sentinel described elsewhere on this blog, an incident-to-repair-to-verify-to-redeploy loop, learning from verified production outcomes, and controlled factory updates with rollback, including, eventually, admin-governed self-improvement, where the factory can propose a change to its own rules but a human still approves it.
Vendor independence is the point, not a feature
Use any approved model. Use any approved coding agent. Keep one governance system.
That line is the organizing idea, not a marketing line. It matters commercially for reasons that have little to do with which model writes better code this quarter:
- Avoids strategic lock-in to one vendor's roadmap, pricing and outages.
- Centralizes security and compliance instead of a separate review per tool.
- Produces one audit trail across a heterogeneous set of agents.
- Allows cost optimization by routing each role to a model suited to it.
- Lets an organization change providers without redesigning how teams work.
- Gives management one place to see what is happening across every project.
- Makes autonomous engineering safer, because safety controls live in the control plane, not inside whichever vendor's product a developer is using that week.
Two different shapes of work
Traditional AI coding: Prompt -> Code -> PR Governed Agentic Engineering: Requirement -> Plan -> Phase -> Wave -> Task -> Agents -> Verify -> Evidence -> Deploy -> Monitor -> Learn
The first is a reasonable way for an individual developer to move faster. The second is closer to what "govern this safely across an enterprise" requires, because it carries verification and evidence through the change, and does not stop at the point of merge.
Most coding-agent workflows are still optimized around code and pull requests
Most tools in this category treat a merged PR as the finish line. That is a reasonable scope for a coding assistant. It is not enough for something calling itself a software factory, because most of what an organization learns about a change happens after production: the incident it causes or avoids, the slow query nobody caught in review, the finding from a post-deploy scanner, the bug report from an actual user.
A factory that stops at the PR has already discarded most of what it could learn. Closing that loop means production monitoring feeds verified incidents back into the same task and evidence pipeline that built the change, so a repair goes through the same review discipline as the original code, and the lesson is available next time a similar task arrives.
What I would build first
Everything above is a target architecture, not a build order. If I were building this for a real organization tomorrow, I would not start with the orchestrator, the nine patterns, or wave-based execution. I would start with the layer between a developer and a model: SSO, RBAC and project authorization, the central AI gateway, and an admin-controlled model-to-role policy.
That slice alone removes the sharpest risk already sitting in most organizations today — provider credentials scattered across laptops, no shared audit trail, no single place to turn a vendor off — for whatever coding agents are already in use, without asking any team to change how it works. Orchestration, phase and wave planning, and the nine governed patterns are what get layered on once that governance foundation is in place and trusted, not before it.
Trade-offs and risks
None of this is free, and it would be dishonest to present it as free.
Complexity is real. A control plane is infrastructure to build and operate, not a plugin to install. Governance overhead is real too: every gate, review step and audit hook costs latency and engineering time. A team shipping throwaway prototypes does not need any of this. A regulated enterprise running production systems probably does.
Agent reliability gets harder, not easier, as the number of agents and patterns grows. Fan-Out / Fan-In and Controlled P2P Mesh especially need real loop limits and timeouts, or they degrade into agents talking past each other. Cost control needs the same discipline: parallel agents across parallel projects can burn budget fast if nothing meters task and token spend per role.
The largest risk is excessive autonomy, and it deserves to be named directly. The more autonomous the execution inside a task becomes, the more important it is that a human still owns the boundaries around it: what gets built, and what gets released. Autonomy inside a boundary is a productivity question, and this architecture is built to make it safe and auditable. Autonomy over the boundary itself, deciding intent or deciding what ships, is a different and much bigger risk that I do not think belongs to the software yet. A human should own intent and release, even when everything between those two points runs without a person watching every step.
None of this replaces good coding agents. It assumes there will be several good ones, from several vendors, and that organizations will need to govern all of them at once without permanently betting on one. I am designing this because that need is arriving faster than most organizations are planning for it.
The next competitive advantage may not be having the best coding agent. It may be having the best system for governing all of them.
