The Governance Gap Nobody Talks About
Somewhere around 2019, I started noticing a pattern conveyed by every architect I spoke with, working across a broad swath of industries. They had plenty of systems. More than plenty. They had Jira for planning, GitHub or GitLab for code, ServiceNow for service requests, Confluence or SharePoint for content, and half a dozen automation tools stitched together with varying degrees of duct tape.
Nobody lacked tooling. What they lacked was coherence.
A request would come in through one system, spawn work across three others, require approvals in a fourth, and leave no unified trail of what actually happened or who was accountable. The systems were each doing their local job well enough, but the space between them was a governance vacuum. In addition, there were horrible efficiency losses in the spaces between all of these systems, and in large part the poor integration between the systems was contributing to significant inefficiencies in each of the systems.
I have to say, the vacuum and efficiency gap is getting wider. And AI is only making it worse.
The Problem Isn’t Missing Workflow Tools
Let me be specific about what I mean by the governance gap, because it is not the problem most people think it is.
Large organizations do not suffer from a shortage of workflow platforms. They suffer from a surplus of them, with no shared model for how work moves across boundaries. Planning happens in one system. Execution in another. Review in another. Promotion in another. Audit? Scattered across all of them, if it exists at all.
This was manageable when humans were the primary actors. A person could hold context across systems, chase down an approval, bridge the gap between a ticket in one place and a deployment in another. It was slow and frustrating, but it worked by the standards of the day.
Now enterprises have started introducing AI agents all over the place.
Agents Made the Problem Structural
The first wave of enterprise AI has materialized as local features. A coding assistant here. A triage bot there. An editorial suggestion engine somewhere else. Each tool vendor seems to have added AI capabilities to their own platform, and each improvement has been genuinely useful within its own boundary.
But here is what nobody planned for: agents don’t just help with individual tasks. They change the operational model. When an agent can draft code, summarize a service ticket, generate a content plan, and propose a deployment , all within minutes , the bottleneck is no longer task execution. The bottleneck is coordination and governance across the systems where that work lives.
An AI-assisted developer can produce code faster, but the review, approval, and promotion of that code still depends on handoffs between disconnected platforms. An agent can triage a service request instantly, but routing it to the right team, getting it approved, tracking its resolution, and auditing the outcome still requires human glue across system boundaries.
What enterprises actually got from adding AI to each tool was faster local work and slower cross-system governance. This gap is widening every day that goes by.
Why Current Options Don’t Close the Gap
You would think someone would have solved this already. There is no shortage of integration platforms, orchestration tools, and enterprise middleware. But they tend to solve a different problem.
Integration platforms move data between systems. They are plumbing, not governance. Knowing that a Jira ticket and a GitHub pull request are related does not tell you who approved what, whether the review met policy, or whether the deployment is eligible for promotion.
Workflow automation tools can chain tasks across systems, but they operate at the task level, not the governance level. They can trigger a build when a ticket moves to a certain status, but they do not own the request lifecycle, enforce approval policy, or maintain a unified audit trail for human and agent activity.
Individual platform vendors are adding governance features to their own products, but they can only govern what happens inside their boundary. GitHub can govern code. ServiceNow can govern service workflows. Neither can govern the work that crosses between them.
AI orchestration frameworks are emerging to coordinate multi-agent workflows, but they focus on agent execution, not enterprise governance or workflows that span enterprises. They can chain agents together but have no concept of organizational authority, policy compliance, promotion gates, or cross-system audibility.
The gap persists because it sits between categories. It is not an integration problem. It is not an automation problem. It is not a single-vendor governance problem. It is a cross-system governance problem that becomes urgent once agents enter the picture.
What Agentic Orchestration Actually Requires
Once you accept that agents will be first-class participants in enterprise work and not just assistants, but actual assignees the governance requirements change fundamentally.
You need to know who did what. Not just which human clicked which button, but which agent took which action, under what authority, with what constraints, producing what output.
You need to be able to assign work to an agent the same way you assign work to a person. Not as an afterthought or a side channel, but as a governed, auditable, reviewable assignment with clear boundaries.
You need approval and promotion workflows that work regardless of whether the work was done by a human, an agent, or a team of both. A pull request generated by an AI assistant should go through the same promotion gates as one written by a senior engineer. A service resolution performed by an agent should be reviewed with the same rigor as one handled by a human operator.
And you need all of this to work across systems, because the work itself crosses systems. A request that starts as a planning item, generates code, triggers a deployment, and requires a service change does not live in any single platform. Its governance should not live in a single platform either.
This is what I mean by agentic orchestration at the governance level. It is not about making agents faster. It is about making agent-involved work trustworthy, auditable, and governed across the full lifecycle.
Building a Governance Layer That Actually Sits Above
This is the problem that led me to start working on the Request Governance Platform, which I call RGP.
The thesis is straightforward: the next enterprise platform that matters is not another point solution. It is a governance and orchestration layer that sits above the systems enterprises already depend on: source control, service management, planning tools, content platforms , and provides a single model for how work is defined, assigned, executed, reviewed, promoted, and audited across all of them.
That sounds ambitious, and it is. But the design is deliberately pragmatic.
RGP does not ask an enterprise to abandon Jira, or GitHub, or ServiceNow, or any other system they have invested in. It does not try to replace those tools. Instead, it introduces a governance control plane that can coordinate and govern the work flowing across them.
The core concept is the “Request”. In RGP, a request is the canonical unit of governed work. It is not a ticket. It is not a task. It is a structured, policy-bound lifecycle object that carries its own status, ownership, review state, artifacts, promotion history, and audit trail. Requests can be assigned to humans, agents, mixed teams, or multi-agent workflows. Those assignments are governed from submission through promotion.
What makes this different from another project tracker with integrations is the governance model itself. RGP defines a consistent set of concepts : request, artifact, review, check, promotion, policy, event that apply regardless of domain. The same governance semantics that govern a code change can govern a content publication, a service resolution, or a planning decision.
How It Works in Practice
Let me walk through what this looks like concretely.
An organization has a service management platform handling incident tickets and a source control platform handling code. Today, when an incident requires a code fix, the connection between those two systems is manual. Someone copies context from the incident into a branch description, writes a fix, gets it reviewed in the code platform, and then goes back to the service platform to resolve the incident. The governance of that end-to-end flow exists only in the heads of the people involved.
In RGP, that work starts as a single request. The request is submitted against a template that defines what fields are required, what approvals are needed, what checks must pass before promotion. The request can spawn work in both the service system and the code system, but the governance of who approved what, what policy was applied, whether the review was completed, whether the promotion is eligible lives in RGP.
If an agent is involved, the same governance applies. RGP tracks agent sessions as persistent, auditable interactions not fire-and-forget API calls. An agent assigned to generate a fix operates under bounded permissions, produces artifacts that go through the same review process as human-produced work, and leaves a complete trail of what it did and why.
The promotion workflow is deliberately multi-phase: dry-run to verify readiness, authorization to confirm policy compliance, execution to deploy. Each phase records its own checks, evidence, and decisions. This is not bureaucracy for its own sake. It is the minimum structure needed to make agentic work trustworthy at enterprise scale.
Progressive, Not Prescriptive
One of the design decisions I feel most strongly about is that RGP should be adoptable incrementally. Enterprises are not going to rip out their existing systems overnight, and nobody should ask them to.
The architecture uses what we call domain packs installable verticals for software delivery, service workflows, content management, planning, and so on. An organization can start with one domain, govern that well, and expand over time. The governance model is consistent across domains, so adding a new vertical does not require rethinking the operating model.
Underneath, the platform connects to existing systems through substrate adapters. RGP projects its governance state to external systems and reconciles state changes back. It is a federated model, not a centralized one. The existing tools keep running. RGP provides the governance layer they never had between them.
This is important because the alternative, asking enterprises to consolidate onto a single platform, has been tried many times and has failed many times. The pragmatic path is to govern across the systems that exist, not to pretend you can replace them.
Why Now
The timing matters. Three trends are converging that make this problem both urgent and solvable.
First, AI agents are becoming capable enough to be genuine participants in enterprise work, not just suggestion engines. That makes the governance gap a real operational risk, not a theoretical concern.
Second, enterprises are starting to realize that adding AI features to each tool independently is creating a new kind of fragmentation. They are looking for a way to manage agentic capabilities as an enterprise concern, not a tool-by-tool concern.
Third, the model context protocol and similar standards are making it possible to provide governed context to agents in a structured way. RGP is designed to produce context bundles that give agents the information they need to operate within policy boundaries, rather than having each agent figure out context on its own.
The window is open. The enterprise that figures out how to govern cross-system, agent-involved work at scale will have a structural advantage over those still managing it through human coordination and manual handoffs.
What This Is Not
I want to be clear about what RGP is not, because the positioning matters.
It is not a better Jira. It does not compete with project management tools. It governs work that flows through them.
It is not a better GitHub. It does not replace source control. It governs the lifecycle of changes that pass through source control alongside other systems.
It is not a better ServiceNow. It does not replace service management. It provides governance across service workflows and the other domains they touch.
It is not an AI orchestration framework. It does not compete with LangChain or CrewAI or similar tools. It governs the enterprise context in which agents operate, regardless of what framework they use.
It is a governance operating system. It sits above existing systems, coordinates work across them, and provides the policy enforcement, review workflows, promotion controls, and audit trail that no individual tool can provide on its own.
The Bet
The bet behind RGP is that the enterprises spending the most on AI will be the first to discover they need a governance layer for it. Not a dashboard. Not another chatbot interface. A real governance control plane that treats agentic execution as a first-class concern, governs it with the same rigor as human work, and does so across every system where work actually happens.
That is a hard problem. But it is also, I think, the right problem to address. The alternative fragmented agents operating in fragmented systems with fragmented governance is how enterprises end up with faster chaos.
The goal is not to slow agents down. The goal is to make them trustworthy enough to speed up.
Pragmatism
Its easy to write about an idealized system. It's much harder to create something real. Something well architected, designed and developed in a sustainable manner. AI can make what used to happen in years, now unfold over days. That’s not only head turning, but it also makes the case for why something like this requires solutioning. While I’ve been thinking about this problem for a few years now the opportunity presented itself to materialize the start of such a solution.
RGP is open source and available at [github.com/pauljbernard/rgp](https://github.com/pauljbernard/rgp).