Architecture for runtime-orchestration — the portal MCP that lets ChatGPT, Copilot, Gemini, Claude, and other AI clients work with the enterprise through one governed Work interface.
Core message: any approved external AI can provide an interface to governed enterprise work through AI Fabrix without learning each system, vendor API, business workflow, or AI Fabrix internals. The external AI does not become the worker or acquire organisational authority.
Purpose
This page answers one question from the Architecture overview: how a new AI interface reuses the same governed foundation instead of requiring its own governance work — the section's interface independence step.
Product experience: External AI and Enterprise MCP. This page explains what Runtime Orchestration makes possible, then the technical packaging (system key, tools, Python parity) so architects and integrators wire clients correctly.
What Runtime Orchestration gives external AI
Runtime Orchestration gives approved external AI clients one stable interface to governed enterprise work. ChatGPT, Copilot, Gemini, Claude, and other named products are compatibility examples; they are not AI Fabrix components or sources of organisational authority.
The external AI keeps responsibility for the conversation, user experience, and personal context. AI Fabrix provides the organization’s governed reality: current business data, authorized knowledge, validated Evidence, available capabilities, Operational Trust, human decisions, and execution state.
This separation means private AI memory does not become enterprise truth, while enterprise systems do not need to own the user’s conversation.
With the same small Work vocabulary, any supported AI can:
- discover what the user is allowed to do;
- retrieve authorized enterprise information;
- start work from a question or objective;
- continue work across multiple systems and human interactions;
- request missing information or approval;
- explain why work continued, waited, or stopped;
- return validated results with an Evidence trail.
The client does not need to understand whether the underlying systems are Salesforce, SAP, Workday, SharePoint, custom applications, or several systems combined. It does not need vendor-specific workflows, large static skills, polling logic, or its own enterprise query compiler.
User conversation and personal context
→ external AI
→ one universal Work interface
→ governed Enterprise Reality, Knowledge, Evidence and capabilities
→ explainable result or human task
Why this matters
| Without Runtime Orchestration | With Runtime Orchestration |
|---|---|
| Every AI client learns every system separately | Every AI client uses the same Work vocabulary |
| Vendor APIs and workflows leak into prompts and skills | Vendors remain behind governed capabilities |
| The client invents sequencing, polling, and recovery logic | AI Fabrix owns execution state and continuation |
| Private chat context can be mistaken for enterprise truth | Enterprise Reality remains organization-owned |
| Each channel develops a different implementation | Portal and external AI use the same runtime functions |
| Approvals and failures are platform-specific | Ask, Approval, Why, and Result are consistent |
| Changing an underlying system requires client changes | Capability contracts remain stable |
| Auditability depends on the external AI | Work retains Operational Trust and Evidence |
This is the actual architectural value:
AI platforms keep the conversation. AI Fabrix supplies the organization’s reality and governs the work.
Responsibility boundary
| Owner | Owns |
|---|---|
| External AI | Conversation, personal memory, phrasing, UX |
| AI Fabrix | Authorized Reality, Knowledge, Evidence, capabilities, Operational Trust, human tasks, execution state, business results |
MCP access is not a bypass of role scope, certification, or Evidence. See Capability gateway and Role Assistant Runtime.
One Python library — MCP is the public version
Role Assistants call the same Python Work library in-process on every operation. Runtime Orchestration MCP is the public adapter over those functions — so ChatGPT, Copilot, and peers can build the same kind of experiences without a second Work stack.
| Caller | Path |
|---|---|
| Role Assistant / Enterprise Runtime | Python library in-process |
| ChatGPT, Copilot, other MCP clients | Portal MCP → same handlers |
| REST / portal / channels | OpenAPI → same handlers |
Proof of non-drift: one implementation, multiple entry surfaces — not a ChatGPT-only side API.
Two MCP layers (do not confuse them)
External AI clients need two different kinds of access to the enterprise: direct calls to certified business capabilities, and a way to start, continue, and check on longer conversation-state work. AI Fabrix keeps these as two clearly labeled layers instead of merging them into one undifferentiated tool list, so a client (and a reader of this page) always knows whether a call is a direct capability request or part of governed Work continuation:
| Layer | Surface | Purpose |
|---|---|---|
| A — Enterprise MCP | Capability tools on certified Enterprise Knowledge / Connected System keys | Governed record and knowledge work (customer.list, …) |
| B — Runtime Orchestration MCP | runtime-orchestration |
Small universal Work vocabulary for conversation-state work |
External platforms receive both under one governance model: role-filtered Layer A tools plus Layer B Work tools. Vendors underneath stay hidden. Layer B is not a second product stack and not a replacement for Layer A.
| Fact | Detail |
|---|---|
| System key | runtime-orchestration |
| Discovery | Sole external-agent MCP discovery for Work tools is portal MCP on this system key |
| Packaging | CIP Python handlers → generated MCP + REST docs |
Work tool catalog
Stable tool names (product vocabulary). Availability follows your deployed dataplane version — verify online after upload.
| Tool | Role |
|---|---|
assistant.describe |
Stable communication method and responsibility boundary |
work.caller |
Current user identity, catalog roles, and groups (not enterprise record search) |
work.roles |
Assigned Role Assistants; caller supplies roleRef on later calls |
work.skills |
Compact authorized capability index for roleRef (request-time detail; not a stored plan) |
work.search |
Role-scoped typed retrieval over Enterprise MCP (not a parallel search engine) |
work.list |
Governed work inbox / list |
work.start |
Begin governed work from a natural-language objective or question |
work.status |
User-safe status (may include presentation envelope) |
work.continue |
Continue when the work permits it |
work.why |
Why? explanation for allow / deny / wait |
work.result |
Validated business result for completed or safely stopped work |
work.logs |
Business activity logs (debug detail only when policy allows) |
human.respond |
Answer a pending Ask, choice, or Approval |
A successful write reported by a capability call is not automatically completed work — see Process Execution Output for how status, time, what changed, and human questions must agree before work.result reports a Task complete.
work.search = retrieve authorized enterprise information
work.start = pursue a governed objective, judgment, decision, or change
work.skills discloses current authority progressively. Omit detail, or send summary, for a compact index: role meaning plus unordered operation classes (retrieve, analyze, work). Request resource or operation for one business object or one capability. full is compatibility for the executable search grammar. The selector is request-time only — the platform does not persist a discovery cursor.
| Class | Used through |
|---|---|
retrieve / analyze |
work.search |
work (writes) |
Listed for discovery only — mutation enters through work.start |
work.search always binds the internal full search grammar, not the compact payload. Calculated (analyze) capabilities are listed under the subject business object they calculate over — the same catalog type as the authority table, not a generic report bucket. Provenance is omitted when no certified mapping facts exist. An analyze answer that cannot be certified exact is not advertised as currently invokable.
Governed search graph
work.skills advertises which related hops exist for a business object. work.search with graph depth 1 returns one master record plus bounded related pages. It does not invent reverse joins and does not walk further than one hop.
| Related key | What returns |
|---|---|
| Other business types | Related records on a declared relationship |
document |
Files from a document library that shares the same business object type (the library is document storage; the type stays the business type) |
knowledge |
Existing governed Knowledge summaries for that subject, the active role, and Keys admitted on the request |
Missing Knowledge stays on the hop and returns explicit missing. It is not filled from document chunks or transcripts. Optional query ranks supporting document materials through the Document Search Service after authorization, and only when a document hop exists. Derive, create, and mutate stay on work.start.
What this shows: Role Assistant search as one master subject plus one level of declared related records, documents, and Knowledge.
What this is not: a generic graph database, a dump of every Knowledge summary the role could access, or using ranked documents as a substitute for Knowledge.
Configure next: Records search integration
There is no separate Q&A tool. Questions are work.start (or informational retrieval via work.search). Ask vs Approval stays visible on human.respond — see Human tasks.
Packaging and verification
Python Work library (SSOT)
→ CIP engine=python on runtime-orchestration (platform package)
→ generateMcpContract → portal MCP + OpenAPI (public version for external AI)
runtime-orchestration is a platform package, not a vendor Connected System customers author and climb through repair / upload --probe. The dataplane onboards it with the platform. Prefer portal MCP on this system key for agent discovery. Interim private MCP path aliases for Work are retired — do not reconnect them.
What delivery teams promote is the Role Assistant package (settings + Evidence per environment) — not a republish of the Role Assistant as a Connected System, and not a customer upload of Runtime Orchestration. For Role Assistants, upload and deploy share one dataplane path (--env selects the role-assistant.yaml section) — full validate/promote steps: Manage Role Assistant packages. Layer A capability catalogs still use Connected System certify/upload — see Configure Enterprise MCP (build).
Limits
- Tool set and schemas follow the deployed platform version.
- Authorization, role scope, Operational Trust, and Evidence requirements still apply.
- Clients must not invent enterprise Reality from private chat memory.
- Layer A capability catalogs remain on Enterprise Knowledge system keys — Runtime Orchestration does not replace them.
- Which capabilities appear in
work.skillsdepends on the active role and what is currently certified in this tenant. Uncertified exact answers are omitted, not listed as ready. - The search graph is one hop. Document ranking requires a declared document hop. Knowledge discovery does not require assets to already exist; retrieve is still request-bounded and identity-bound.
Related
- External AI and Enterprise MCP — product experience
- Enterprise MCP reference — capability keys and Role Assistant MCP packaging
- Role Assistant Runtime
- Capability gateway
- Process Execution Output
- Configure Enterprise MCP (build)