Architecture

How the platform is put together

Three layers, one core

Requests arrive on any channel. The core builds an optimised plan, runs it, and pulls from the connected systems only the data that plan calls for.

Interface layer
Voice
Chat
Mobile & web
Embedded UI
API · A2A
Triggers
Intelligence layer
Understand Reads intent, context and identity Entity resolution
Recall Reuses answers already approved Exact and template match
Reason Decomposes the goal into a plan Source routing
Act Calls tools and runs workflows Governed execution
Govern across every stage Entitlement before retrieval Role-based access Guardrails Human approvals Audit
Core services Orchestration Memory Explainability Cost tracking
Connected systems
Applications & SaaS
Databases
Documents
Email & comms
Know-how

More than 1,000 pre-built connectors, with MCP and A2A for everything else. Browse the catalogue →

The x101 architecture has three layers. The interface layer is how people and systems reach the platform: voice, chat, mobile and web applications, embedded user-interface components, a programmatic API, and triggers that let automated processes start a request. All route into one intelligence layer, which works in four stages: understand, which reads intent, context and identity and resolves entities before the model sees the text; recall, which reuses answers already approved, by exact match or by template match; reason, which decomposes the goal into a plan and routes each part to a source; and act, which calls tools and runs workflows. Governance runs across all four stages rather than being one of them: entitlement is checked before retrieval, and role-based access, guardrails, human approvals and audit apply at every stage. The layer also provides orchestration, memory, explainability and cost tracking, and the model within it is a replaceable component. The intelligence layer reaches connected systems through one governed path: enterprise applications and software-as-a-service products, databases, document repositories, email and communication tools, and institutional know-how such as tickets, threads and prior resolutions. Those systems are reached through more than 1,000 pre-built connectors, with the MCP and A2A standards covering anything outside the catalogue.

Request pipeline

How a question becomes an answer

Six intelligent stages. One conversation.

From a plain-language question to a verified, traceable result.

Every request runs through six stages, shown here for the question "show me Q2 renewal risk, flagged against open support tickets". One, ask: the question arrives typed or spoken, in plain words. Two, analyse: intent, context and identity are resolved, establishing that the intent is renewal risk, who is asking, and that their access covers CRM and support. Three, plan: a step-by-step plan is built, querying CRM for Q2 renewals, joining open tickets, then scoring and ranking risk. Four, execute: databases are queried, APIs called and documents retrieved in parallel across CRM, support and billing. Five, verify: the output is cross-checked against source data and policy, confirming scope, three sources and a clear personal-data guardrail. Six, deliver: the answer is returned with its sources cited and every step logged for audit. Figures shown are illustrative.

Agent creation

How an agent is built

Agents are composed, not coded

Six guided steps take an agent from a concept to a governed launch. Every step is configuration, and every agent inherits policies and guardrails by default.

LIFECYCLE Draft Submitted for approval Active Published Active: live inside the platform. Published: callable from outside over A2A, or listed on the marketplace.
Basic information
  • Identity and tags
  • Communication channels (chat, voice or avatar)
Communication style
  • Role, tone and guidelines
  • Reusable prompts
  • Generate with AI
AI configuration
  • Model and provider
  • Memory configuration
  • STT and TTS settings
Tools & integration
  • Tools and APIs
  • Datasets, documents, vector stores
  • Sub-agents and skills
  • MCP and A2A native
Governance & policies
  • Input and output guardrails
  • Tool and agent access policies
  • Data access policies
  • Versioned and reversible
Test & validate
  • Playground
  • Repeatable test runs
  • Approval gate

An agent is built in six guided steps, and can be tried live at any of them. One, basic information: the agent’s identity and tags, and the communication channels it is available on, whether chat, voice or avatar. Two, communication style: role, tone and guidelines, reusable prompts, and drafting with AI. Three, AI configuration: the model and its provider, how memory is configured, and the speech-to-text and text-to-speech settings for voice. Four, tools and integration: the tools and APIs it may call, the datasets, documents and vector stores it may read, the sub-agents and skills it may delegate to, and native MCP and A2A. Five, governance and policies: guardrails on what goes in and what comes out, policies governing which tools and agents it may use, policies governing the data it may reach, and every policy versioned and reversible. Six, test and validate: the playground, repeatable test runs, and the approval gate the agent must clear before going live.