Brutor AI Control Plane Architecture
Three views — every component that makes up the platform, what each one is responsible for, and how a single request travels through them end to end. Nothing here is aspirational: this is what ships in the deployment bundle.
What’s in the platform
Eight Brutor services, seven stores you own, one way out. The Gateway Core is the only component on the request path — everything else either configures it, runs alongside it, or stores what it produces. Ports shown are the bundle defaults.
What each service actually does
The request path, and the only component on it. Proxies LLM, MCP, A2A, Skills and batch traffic; enforces auth, access, quotas, run-level ceilings, guardrails, semantic and argument policy and residency; runs cache lookup and store; writes the proxy log that becomes the run ledger; and serves the end-user Portal API. Read-only with respect to configuration.
Every configuration write, and the backend for the Admin Console. Owns tenants, users, RBAC, providers and models, the MCP catalog, guardrail policy, resource groups and limits, policy-as-code, AI System contracts, assurance reports and the EU AI Act register. It also owns the database schema and runs the Alembic migrations on startup.
Executes skill scripts in a separate, isolated container — never inside the proxy. No network exposure, read-only rootfs, and a hard timeout (30s sandboxed, 120s trusted). The Core calls it with a signed token; the agent receives script output, never the code.
Turns documents into retrievable knowledge. Parses PDF, Word, Excel, PowerPoint, markdown, HTML and CSV, chunks the text, calls the Core for embeddings, and writes vectors into Qdrant under the tenant’s own key. Source files land in object storage.
Keeps knowledgebases current from the tools you already use: Confluence, Notion, Google Drive, Slack, GitHub, Jira, SharePoint and a web crawler. Scheduled incremental sync, with each document’s source permissions preserved so they still apply at retrieval time.
A standalone registry on the official MCP registry specification (server.json 2025-12-11, /v0.1 REST API). Federate public servers, publish your own, attach governance metadata to every record, and import an entry straight into your MCP catalog.
The end-user chat client: workspaces, batch processing, knowledgebase-grounded answers with citations, and usage and guardrail alerts. It talks only to the Core’s Portal API — never to the Control Plane.
The management surface: configure models, MCP servers, skills and guardrails; build the resource-group tree; set limits and policies; and read Mission Control, proxy logs, the AI Systems fleet board and assurance reports. Backed by the Control Plane.
A ninth surface ships with it: the MCP Registry UI (:3003). Everything else in the diagram — PostgreSQL, Redis, Qdrant, object storage, Vault, Presidio and the observability stack — is standard infrastructure you deploy and own. Brutor stores no customer data outside them.
A single prompt, end to end
Every call — chat completion, MCP tool invocation, skill execution, knowledgebase retrieval or A2A delegation — takes the same governed path through the Rust proxy. Each stage is policy-enforced, observable and tenant-scoped.
Client
Portal, agent, backend or A2A peer
Identify
JWT & tenant resolved
Authorize
Policy & guardrails
Cache
Semantic lookup
Route
LLM · MCP · Skill · KB · A2A
Provider
Stream & record
Step 1
- OpenAI, MCP or A2A request
- Bearer token or API key
X-Tenant-IDor A2A path
Step 2
- Verify JWT signature
- Resolve tenant + agent card
- Hydrate user / peer context
Step 3
- Model entitlement check
- Quota, budget, run ceilings
- Guardrails & policy
Step 4
- Embed & search Qdrant
- Skip when tools attached
- HIT → return early
Step 5
- Pick provider & deployment
- Inject creds from the vault
- Apply request transforms
Step 6
- Stream tokens or tool result
- Store cache entry
- Emit traces & metrics
Step 5 routes to one of five targets
Each branch reuses the same auth, policy, cache and audit layers.LLM completion OpenAI-compatible
Routes to OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, Mistral or a self-hosted model — directly, or through a routing group that picks one by weight, load, latency or cost. Streaming preserved end to end.
MCP tool call JSON-RPC
Resolves the configured MCP server for the tenant, attaches user-delegated OAuth tokens held encrypted at the gateway, and streams the result back — after argument policy, guardrails and any approval gate have cleared.
Skill execution Composed
Progressive disclosure over the system MCP server: list → load → act. Scripts run in the external Skill Runner (isolated container, read-only rootfs, JWT-authed); every step is independently governed and audited.
Knowledgebase retrieval RAG
Hybrid search over the group’s Qdrant collection — semantic vectors plus keyword, fused. Content is indexed by the KB Uploader and kept fresh by KB Connector Sync; source permissions still apply at retrieval, and every answer carries citations.
A2A delegation A2A v1.0
Calls a Brutor-hosted Agent Card or a peer A2A agent. Adds signed root, parent and depth headers and enforces the policy-defined max delegation depth.