Back to the public landing page · Compatibility matrix · Ecosystem map · Integration guide · Builder quickstart · Skills quickstart · MCP quickstart · API quickstart · Use cases

AI operator, MCP, and API surfaces

CortexPilot already has real AI-facing and integration-facing product surfaces for Codex and Claude Code workflows. This page exists to make those surfaces easier to discover without overstating what they are.

Current boundary: these surfaces are not a hosted operator product, the shipped MCP node remains read-only, and the frontend packages remain a thin client + contract + shared substrate layer instead of a full SDK platform.

1. Explain-only AI operator copilot

CortexPilot already exposes a bounded AI operator brief on the workflow path instead of an unbounded floating chat box. Today it shows up in three major places:

• Flight Plan preview: a pre-run advisory brief before execution starts
• Workflow copilot: a workflow-scoped explainer over queue posture, latest run context, and next action
• Run / compare brief: a run-scoped explainer over deltas, proof, incident context, and next operator step

Read the architecture baseline in the MCP + operator copilot architecture note.

2. Read-only MCP surface

CortexPilot ships a real read-only MCP node for control-plane reads. The current public contract is:

• inspect runs, workflow cases, queue posture, approvals, compare, proof, and incident summaries
• return structured JSON for agent/tool consumption
• do not mutate queue items, approvals, provider state, or workflow truth

This keeps MCP useful for external inspection while staying honest about the current boundary.

If you want the shortest MCP-specific map, go straight to the read-only MCP quickstart.

3. Frontend API and contract entrypoints

CortexPilot also exposes a thin builder edge for frontend consumers that want the same routes and contracts the dashboard and desktop use today.

• @cortexpilot/frontend-api-client: thin JS/TS client helpers for runs, Workflow Cases, approvals, and command-tower reads
• @cortexpilot/frontend-api-contract: contract-facing route/query names, generated types, and the human-readable package guide
• @cortexpilot/frontend-shared: shared copy, locale, and status-presentation substrate for dashboard and desktop

For the machine-facing HTTP boundary, open the public OpenAPI document.

If you want the shortest API-oriented map, use the API and contract quickstart.

4. What we can say truthfully

• Codex: CortexPilot is positioned for Codex workflows as an operator control plane, not as an official Codex product.
• Claude Code: CortexPilot is positioned for Claude Code workflows as the same governed command-tower path, not as an Anthropic-managed surface.
• MCP: the current protocol story is real, but it is read-only only.
• API / builder layer: current packages are useful integration entrypoints, but they are not yet a full SDK platform.
• Queue pilot groundwork: repo-owned HTTP queue preview/cancel plus a confirm-gated, default-off queue-only MCP pilot server can exist internally without changing the public “read-only MCP” contract.

4.5. Integration and skills adoption

If your real question is “How do I plug this into a coding-agent team workflow without making fake plugin claims?”, use the compatibility matrix, the integration guide and the skills quickstart.

• Compatibility matrix: the fastest “which ladder fits my stack?” answer across agents, skills, builders, proof-first cases, and MCP.
• Integration guide: the truthful map for Codex, Claude Code, and OpenClaw usage.
• Skills quickstart: repo-owned playbooks and adoption guidance for repeatable agent behavior.

5. What stays explicitly out of scope

• no hosted operator login surface
• no write-capable MCP claim
• no claim that queue pilot groundwork means general agent-safe mutation is already live
• no official partnership implication with OpenAI or Anthropic
• no claim that the current packages replace the orchestration runtime