Platform
The SwiftXEO Open Platform lets external AI assistants and your own systems connect to a governed workspace — able to read approved direction and propose work, never to approve it.
An MCP server with OAuth, a workspace-scoped REST API, signed inbound webhooks, and a Gmail connector (beta) form one surface with one contract: externally proposed, internally governed.
Autonomy proposes. Humans authorize. Governance remains active.
Why this matters
Leaders want assistants like Claude and ChatGPT working with real company context — approved strategy, live objectives, reviewed lessons — instead of guessing from a pasted paragraph. What stops them is the risk that an external tool quietly becomes an authority.
SwiftXEO resolves that tension structurally rather than by policy document. Connected assistants read the same approved record your team works from, and everything they send back enters a review queue. Context flows out; authority never does.
The surfaces
Claude and ChatGPT connect to a workspace through a standard MCP connector with OAuth sign-in — the Claude connection is verified working end to end. Config-file clients like Claude Code and Cursor connect with a workspace API key.
Workspace-scoped API keys drive a versioned REST surface: read approved Business DNA, objectives, active learnings, and lineage; submit evidence and proposals from your own systems.
Signed, verified push from external systems. Every payload is checked against a per-source secret and stored as material for human review — never executed, never trusted on arrival.
A read-only beta connector that turns recent inbound email into reviewable workspace evidence. It never sends mail, and like every external source, nothing it captures becomes truth without review.
The propose-only invariant
Every external item — an agent's proposal, a webhook payload, an email — enters the workspace as untrusted context. It can be read by reviewers, weighed as evidence after review, and approved into organizational truth only by a human with the right role. No API scope, MCP tool, or webhook can perform that approval.
There is deliberately no approve, activate, or authorize capability at any scope. The gate is structural: the routes that promote a proposal require a signed-in human workspace admin, and that invariant is covered by a permanent test suite.
External responses are projected, not raw. Reviewer and author identities leave the workspace as role labels — "Workspace administrator" — never as names or internal identifiers. Connected agents learn what was decided and by what role, not by whom.
The trust ladder
Every external item is born untrusted. Each promotion up the ladder — reviewed evidence, approved context, organizational truth — is a human decision that changes what the material is authorized to do.
Questions
Any MCP-capable client. Claude (web, desktop, and mobile) connects over OAuth and is verified working; ChatGPT connects through the same OAuth flow in developer mode. Claude Code, Cursor, and custom agents connect with a workspace API key.
No. External agents can read approved context and submit proposals, but no scope or tool can approve, activate, or publish. Every proposal waits in a review queue until a human workspace admin decides.
It lands as untrusted context in a server-only review area. A reviewer can promote it to evidence, approve it into active guidance, or reject it — rejected items are retained with their lineage but never influence future work.
Not yet — it is a read-only closed beta, enabled per workspace. The MCP server, REST API, and inbound webhooks are generally available.
Go deeper
Create a workspace API key from Settings, or start with a DNA scan — the open platform reads from the same approved record as everything else in the product.