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
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)
| Layer | Surface | Purpose |
|---|---|---|
| A — Enterprise Knowledge 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.roles |
Assigned Role Assistants; caller supplies roleRef on later calls |
work.skills |
Authorized contextual skill projection for the call’s roleRef |
work.search |
Role-scoped typed retrieval over Enterprise Knowledge 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 |
work.search = retrieve authorized enterprise information
work.start = pursue a governed objective, judgment, decision, or change
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:
aifabrix validate <roleKey>
aifabrix upload <roleKey> --env dev
aifabrix upload <roleKey> --env tst
aifabrix upload <roleKey> --env pro
For Role Assistants, upload and deploy share one dataplane path (--env selects the role-assistant.yaml section). See 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.
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)