The MergeOn Platform
The enterprise foundation for building, governing and operating AI at scale.
Explore the platform →THEMIS Mission Control NewUnderstand what is changing across your organization and bring the right decisions to the right people at the right time.
Runtime Digital Twin PreviewVisualize every runtime, capability and relationship across your AI operating environment.
Create governed AI activity once, with its knowledge, controls, approvals and execution requirements.
Runtime CenterOperate and observe governed Runtimes, activity, execution, evidence and readiness from one operational surface.
Governed KnowledgeTurn enterprise information into structured, governed context that AI can use without losing source meaning and relationships.
Policy & ProtectionDefine the controls that govern what AI may access, what it may do, what must be protected and when a person must approve.
Data ProtectionProtect sensitive values while preserving the business context AI needs to perform the governed task.
Human ApprovalRequire human authority where governed AI activity should not proceed on AI authority alone.
Golden ThreadReconstruct governed AI execution from request to outcome with connected execution evidence.
AI Evaluation & AssuranceVerify what can be proven, evaluate AI behaviour and establish evidence-backed readiness in context.
AI Model GovernanceGovern which models may participate, where they may be used, what evidence supports them and when their qualification must be reconsidered.
Why MergeOn
Turn the knowledge you already have into governed context AI can use.
Policies, procedures, manuals, regulations and operating documents were written for people — not AI.
MergeOn Document Intelligence transforms them into structured Tier-3 Review Packs, preserving meaning, relationships, dependencies and source context. Accepted knowledge can then be governed in the Knowledge Center and supplied to AI at execution.
Better context. Less repeated processing. More efficient AI execution.
Explore Governed Knowledge →Wherever critical knowledge, policy and AI execution have to work together.
Govern policies, controls, product rules and regulated decisions while keeping AI execution traceable.
Healthcare & Life SciencesTurn clinical, operational and regulatory knowledge into governed context while protecting sensitive information.
Logistics & Supply ChainStructure customs, trade, food, agriculture, transport and supplier requirements so AI can work from the right rules for the activity.
Legal & Professional ServicesTransform contracts, precedents, policies and matter knowledge into governed context with source-level evidence.
Industrial & Critical OperationsGovern procedures, technical documentation, safety requirements and operational knowledge across complex environments.
Public Sector & Defense Supply ChainControl how sensitive policy, procurement, compliance and operational knowledge participates in AI-enabled activity.
Build on MergeOn
The application asks for a business outcome. The Runtime governs how it is produced.
An integration calls a published Business Capability rather than a model endpoint, so knowledge, policy, protection, human authority and evidence stay part of the activity instead of becoming your problem to rebuild.
Everything below describes the contract you build against and the architecture behind it.
Explore the developer platform →Everything you need to integrate, extend and build on the MergeOn platform.
API ReferenceComplete REST APIs, authentication, schemas and integration endpoints.
SDKs & ExamplesAccelerate development with SDKs, sample applications and reference implementations.
Technical documentation covering platform architecture, configuration and deployment.
Integration GuidesStep by step guides for connecting AI providers, enterprise systems and business applications.
Architecture PatternsReference architectures and implementation patterns for enterprise AI deployments.
Know where you stand
Most organizations do not have an AI problem. They have a clarity problem.
Before deciding what to build, it helps to establish what your organization already believes about ownership, governance and decision-making — and where those beliefs disagree with each other.
Start with an honest read of where you are. Everything else follows from it.
Start the free benchmark →Take the free 12-question benchmark and get an immediate view of your organization’s AI readiness.
Start the benchmark Leadership Alignment AssessmentCompare leadership perspectives to reveal where your team is aligned, where views diverge and where that difference matters.
Explore the assessmentMergeOn was created to give organizations a governed foundation solid enough to put real AI-enabled work on.
Read our story →Why MergeOn exists and how we are building the enterprise control plane for governed AI execution.
CareersJoin the team building the control plane for governed enterprise AI.
Contact UsTalk to MergeOn about your organization, implementation or enterprise AI programme.
See how the models, cloud, data and enterprise technologies organizations already use can participate in governed MergeOn execution.
Implementation PartnersBuild a governed AI practice on MergeOn and help enterprises move from AI pilots into controlled production.
Become a MergeOn Implementation PartnerBring MergeOn into client engagements, build repeatable governed AI capability and register for partner enablement and future certification.
What is an enterprise AI control plane?
An enterprise AI control plane is the layer that decides whether a piece of AI-enabled business activity may proceed, under what conditions, and what record it leaves behind. It sits above the individual models, agents and tools doing the work, and holds the decisions an organisation cannot safely delegate to them: who or what is participating, what activity is being attempted, which enterprise knowledge may inform it, which policies apply, what must be protected, whether a person must approve, whether execution is admitted at all, and what evidence survives afterwards.
The defining characteristic is authority rather than capability. A control plane does not make a model better, faster or cheaper. It determines whether that model is permitted to act in a particular business context — and the governance boundary stays in place as participants change, even though the qualification and policy applied to any given participant may legitimately differ. A model approved for one activity is not thereby approved for another.
Three pressures created the need for a governance layer.
The first is proliferation. As organisations adopt AI across functions, they accumulate models, providers, agents, copilots and tools faster than any single team can inventory. Where that adoption happens outside a managed path it is often described as shadow AI; where it happens inside one but without coordination it appears as sprawl. Either way, the enterprise ends up unable to answer a basic question: what AI is operating against our systems and data, on whose authority?
The second is rate of change. Models and providers are replaced far more often than business processes are redesigned. In environments where governance has been implemented inside each application, every model change becomes a governance change, and the cost of switching quietly becomes a reason not to.
The third is the gap between pilot and production. Many enterprises reach working prototypes and stop there. Even where model quality is sufficient for the task, production introduces a different class of requirement: who authorised the activity, which policy applied, what had to be protected, whether a person needed to approve before it proceeded, and whether the operation can be demonstrated afterwards. Those requirements are rarely present in a prototype, and they are what an auditor, a regulator or a risk committee asks about.
A control plane exists to hold those answers in one place, outside the components that change.
Why enterprise scale changes the problem.
A single team running a single AI application can hold these decisions in its own code and keep them coherent. The problem changes shape at enterprise scale, and it changes along several axes at once.
There are multiple teams, each making reasonable local choices that do not compose into a consistent organisational position. There are multiple AI participants and providers, adopted at different times for different reasons and replaced on different schedules. There are multiple governed activities, each with its own context, controls and approvals — which means many governed environments rather than one. There are multiple deployment environments, where what is permitted in a sandbox is not what is permitted in production. And above all of it sits organisational authority: who is actually entitled to decide that a given activity may run, which is a question about the organisation rather than about any system.
A control plane earns its place when those stop being manageable by convention. Below that threshold, governance implemented inside the application is often sufficient and considerably simpler.
What a control plane is not.
Much of the confusion in this category comes from assuming that whichever AI component an organisation adopted first is the governance layer. It usually isn’t, and the distinctions are worth stating plainly. None of these technologies are deficient; they answer different questions.
A model is not the control plane.
A model produces output. It has no view of the business activity it is participating in, the authority under which it was invoked, or the policy that should constrain it.
An agent is not the control plane.
An agent decides how to pursue a goal, often across several tools and steps. That makes it a more capable participant — and a more consequential one — but an agent evaluating its own permission to act is not governance.
A gateway is not the control plane.
A gateway's primary boundary is the connection to the model: routing requests, managing credentials and rate limits, applying transport-level security and often capturing usage. That is real and necessary infrastructure. Its scope is the call rather than the business activity the call belongs to, so questions about which activity was being attempted, whether it was authorised and on whose authority generally sit outside that boundary.
Orchestration is not the control plane.
Orchestration frameworks compose models, tools and steps into workflows. The distinction commonly drawn in the category is between how work is performed and whether it should be performed at all: orchestration governs the former, a control plane the latter. Both are needed, they are not substitutes, and some orchestration products do include governance features — the difference is one of scope and authority, not quality.
Observability is not the control plane.
Observability tells you what happened: traces, latency, drift, spend, sometimes reasoning steps. The limitation is timing. Flagging is not enforcing — a tool that scores a risk after an action has occurred documents the incident rather than deciding whether it was permitted. Both matter. Only one of them is authority.
A governance platform is not automatically a control plane either.
Much of the AI governance market is oriented toward defining policy, cataloguing models and evidencing compliance — oversight functions that sit beside operations. Some of these platforms do enforce at execution, and some control planes do very little policy authoring; the useful test is not the label but whether the system is in the path of the activity at the moment the decision is made.
| Layer | Question it answers | Typically outside its scope |
|---|---|---|
| AI gateway | How does this request reach a model, safely and within limits? | Which business activity the request belongs to; whether it was authorised |
| Orchestration | How should this work be performed, in what order, using which tools? | Whether the work is permitted to occur at all |
| Governance platform | What are our policies, models and obligations, and can we evidence them? | Enforcement in the execution path, where implementations vary |
| Observability | What happened, how did it perform, what changed? | Deciding, before the fact, whether it should happen |
| Agent framework | How does an agent pursue a goal across tools and steps? | Governance that must outlive the framework itself |
| AI control plane | May this activity proceed, under what conditions, and what evidence remains? | Performing the work — it governs participants, it is not one |
What an enterprise AI control plane must decide.
A useful way to evaluate any candidate architecture is to ask which of the following it actually determines, and at what moment.
Not every enterprise needs all ten enforced with equal rigour, and not every vendor implements them the same way. The value of the list is diagnostic: architectures tend to be strong on the first half or the second half, and weak where the two meet.
Control plane and governed Runtime.
Two terms are easy to conflate, and the industry uses them inconsistently.
Much of the market uses runtime governance adverbially, to mean governance applied at execution time rather than at design time. That is a useful corrective to governance that lives only in documents.
Used as a noun, a governed Runtime means something more specific: the bounded environment a given business activity executes inside, carrying that activity’s knowledge, controls, approvals and permitted participants. In that reading the relationship is straightforward. The control plane is the enterprise-wide authority architecture; a governed Runtime is where a particular activity actually runs under it. One organisation, one control plane, many Runtimes.
Both senses of the word are legitimate. They are not interchangeable, and evaluating a product is easier once you know which one a vendor means.
Where AI agents fit.
Agent adoption is what has made this category urgent for many organisations, because an agent can take a sequence of actions across systems rather than returning a single answer.
The architectural point is that models, agents, providers and tools are participants in business activity, not the governance boundary around it. If governance is implemented inside a particular agent framework, it moves when the framework moves, and it does not extend to the second framework another team adopts next quarter. A control plane holds the boundary steady while the participants change — which is what makes it possible to run more than one agent ecosystem without running more than one governance model.
This does not mean agents are required. Plenty of governed AI activity involves no agent at all. It means the boundary should not assume one.
Build once, adapt forever.
The practical consequence of separating governance from participants is that the business activity becomes the durable asset.
When the process logic, controls, knowledge and integrations are bound together inside an implementation, replacing a model means revisiting all of it. When the activity and its controls are defined once and the participants are connected to them, changing a model, provider, agent or tool is a change to a participant rather than a rebuild of the activity.
This is an architectural property, not a guarantee of zero work. A materially different model may still require re-evaluation before it is qualified for a given activity, and a new tool still needs connecting. The claim worth making is narrower and more useful: technology change should not automatically become business-process change.
Evidence, not just logging.
Most AI stacks produce logs. Far fewer produce evidence.
A log records that a call happened, usually from the perspective of the component that made it. Evidence of governed business activity is different in kind: an ordered record formed as the operation proceeds, connecting the request, the context that informed it, the authority under which it proceeded, the controls that applied, any human approval, the execution itself and the outcome. Because the record is ordered and accumulated as part of the operation rather than reassembled afterwards from fragments scattered across several systems, the operation can be reconstructed rather than inferred.
The distinction becomes concrete the first time someone asks why a particular decision was made six months ago. Model telemetry will tell you a call occurred. It will not tell you who authorised the activity or what policy was in force at the time.
Where MergeOn fits.
MergeOn implements an enterprise AI control plane for governed AI execution. The decisions listed earlier map onto its architecture rather than onto a feature list.
Purpose and admission are held by the Runtime. A governed Runtime is the environment an AI-enabled business activity executes inside, carrying that activity’s knowledge, controls, approvals and permitted participants. The activity itself is composed in Runtime Builder rather than assembled inside application code, which is what allows it to outlive the technology serving it.
The context question is answered by Governed Knowledge: enterprise information turned into structured context an activity may use, with meaning, relationships and source preserved and access governed by the organisation that owns it. What the activity may then do is determined by Policy & Protection, bound to the activity and enforced at execution rather than described in a document, while Data Protection decides which values an AI participant actually receives.
Where an activity should not proceed on AI authority alone, Human Approval makes a person’s decision an explicit condition of execution. The participants are qualified separately from the activity: AI Model Governance governs a model’s qualification, permitted use and supporting evidence rather than only the application calling it, and AI Evaluation & Assurance tests the activity through deterministic validation and evaluation before and during operation.
What the operation leaves behind is Golden Thread — ordered execution evidence formed as the operation runs. Read across many executions, that evidence supports the organisational view offered by THEMIS.
What MergeOn is not.
Worth stating plainly, because the category is crowded and the adjacent products are good at what they do.
MergeOn is not an LLM gateway; it does not exist to route traffic to model endpoints. It is not an orchestration framework, and it does not replace the one a team has chosen. It is not a model observability dashboard — it is concerned with whether activity was authorised, not primarily with how the model performed. It is not a single-model platform. And it is not an agent framework: agents participate in governed activity rather than being the thing MergeOn provides.
Two illustrative examples.
Both are constructed to show how the architecture behaves. Neither describes a customer deployment.
Financial services
An analyst initiates a governed activity that reviews a client file and drafts a recommendation. The activity draws on governed knowledge scoped to that client relationship; protection rules mean the model receives the context it needs without unnecessary exposure of identifying values; policy requires that any recommendation above a threshold is approved by a person before it is issued. The approval, the policy in force and the resulting execution are retained as one ordered record.
Public sector supply chain
A programme team runs a governed activity that checks supplier documentation against current requirements. The knowledge is versioned; the applicable rules change over time; the activity must therefore record not only its conclusion but which version of the requirements applied when it ran. A year later, the question asked is not whether the model was accurate — it is what the rules were at the time and who accepted the result.
What should enterprises ask when evaluating an AI control plane?
- Does governance apply consistently across models and providers, or is it re-implemented per integration?
- Can it govern agents as participants, without binding governance to one agent framework?
- Can enterprise knowledge and context be governed — including who may use which information for which activity?
- Is policy enforced at execution, or authored and monitored beside it?
- Can sensitive values be protected before an AI participant receives them, while leaving the activity workable?
- Can human approval be made a condition of specific activities, with the approval recorded as part of the operation?
- Is there an explicit admission decision — can the system decline to proceed?
- Can a specific execution be reconstructed afterwards by someone who was not involved?
- Does it produce evidence of business activity, or telemetry about model calls?
- Can a model, provider, agent or tool change without rebuilding the business activity around it?
- Is the governance boundary stable across more than one AI ecosystem operating in parallel?
- What does the system do when a control cannot be satisfied — fail open, or fail closed?
The last question is often the most revealing, and the least likely to appear in a datasheet.