Skip to content
x101
Book a demo

An enterprise AI platform, taken apart.

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.

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 2,000 pre-built connectors, with the MCP and A2A standards covering anything outside the catalogue.

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

Six intelligent stages. One conversation.

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

The six stages of an x101 request: ask, analyse, plan, execute, verify and deliver. 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. Stages one and two form the input phase, three and four the orchestration phase, and five and six the output phase.

  1. Ask

    Takes the question in plain words, typed or spoken.

  2. Analyze

    Resolves intent, identity and what they may see.

  3. Plan

    Finalises the tools and agents, and the order they run.

  4. Execute

    Calls agents, tools and systems in parallel.

  5. Verify

    Validates the result against sources and policies.

  6. Deliver

    Returns the answer cited, and logs the run.

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

  1. Draft
  2. Submitted for approval
  3. Active
  4. Published

Active: live inside the platform. Published: callable from outside over A2A, or listed on the marketplace.

  1. Basic information

    • Identity and tags
    • Communication channels (chat, voice or avatar)

  2. Communication style

    • Role, tone and guidelines
    • Reusable prompts
    • Generate with AI

  3. AI configuration

    • Model and provider
    • Memory configuration
    • STT and TTS settings

  4. Tools & integration

    • Tools and APIs
    • Datasets, documents, vector stores
    • Sub-agents and skills
    • MCP and A2A native

  5. Governance & policies

    • Input and output guardrails
    • Tool and agent access policies
    • Data access policies
    • Versioned and reversible

  6. 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.

One question, many agents, one answer

Every question arrives at the orchestrator. It looks for a plan it can reuse, selects from the sub-agents registered to it, and clears permissions before control moves anywhere.

Diagram of x101 agentic orchestration: the orchestrator routes a question to specialist utility agents, applies permissions and policy, and returns one validated answer. Orchestration runs as one sequence between two actors. The orchestrator holds the conversation by default. One: it receives the question, and intent and entities are resolved before the model sees the text. Two: it checks for a stored plan, and a match is re-authorised for whoever is asking now and returns without re-reasoning. Three: it selects the sub-agents from those registered to it, each with its own tools, knowledge, data and documents. Four: it clears permissions before control moves, and a denial comes back as an access message. If one domain can answer, control transfers to that sub-agent; if several domains are needed, the orchestrator keeps control and coordinates them, running independent sub-agents at the same time. The domain sub-agent owns its tools, knowledge and documents. Five: it selects its tools, with retrieval exposing only the relevant ones to the model rather than the whole catalogue. Six: it executes them with policy checks applied on every call, not once at launch. Seven: it brings in a human when an access or data policy needs something only the user can supply. Eight: it validates the response, checking file, chunk and API identifiers before anything reaches the screen. Nine: it presents the result, choosing how to show it and holding the conversation while questions stay in its domain. Control returns to the orchestrator when the sub-agent cannot fulfil the task, never sideways to another sub-agent, and memory is shared so the thread survives the hand-back. Throughout, utility agents are shared services such as entity extraction, query generation and language conversion; either the orchestrator or a sub-agent can call one, and control comes straight back.

  • Multi-level orchestration

    Any agent can own sub-agents. The hierarchy goes as deep as the work needs.

  • Parallel where it can be

    Independent sub-agents run together. Elapsed time is the slowest of them, not the sum.

  • Multi-level caching

    Model responses, validated plans and executed steps are all reusable. One plan serves many entities.

  • Zero-trust agents

    No step inherits the previous step's access. Every run resolves entitlement again.

Retrieval that goes far beyond vector search

x101 retrieves the right evidence, not just similar text. It narrows, searches, evaluates and verifies before generating a cited answer.

Diagram of the x101 retrieval pipeline: ingest from any source, prepare and curate, index across vector, keyword and knowledge-graph, retrieve with verification, secured end to end. How the knowledge base is built and searched. Sources are ingested in many formats: PDF, Word, slides, spreadsheets, HTML, email, scans and images, transcripts and databases. Each is then prepared in four steps: extract, taking text, tables and layout, including from scans; chunk, splitting on meaning rather than on length; enrich, adding author, date, source, tags and entities; and approve, where an administrator publishes it, because nothing publishes itself. Approved content is written to three stores: a vector index of embeddings, a keyword index using BM25, and a knowledge graph of entities and relationships. A question is then answered in four steps: narrow, applying metadata filters and the entities named in the question; search in parallel across all three retrievers, semantic, BM25 and graph; fuse and rerank the results into one ranked set; and return a cited answer, with document, page and version travelling with the claim. Retrieval is a loop rather than a single shot: the agent judges what came back, and thin evidence rewrites the query and runs the retrieval again. Across all of it, entitlement is resolved before retrieval, and every candidate is filtered to what the person asking may read.

Your cloud, your model, and the freedom to change both

One Kubernetes deployment runs on any cloud, in your own data centre, or fully disconnected. Only the DMZ tier is public, and inference can be hosted in-house or called out to any provider.

Deployment architecture of x101: a public DMZ tier, the client premise running application, infrastructure and GPU namespaces on Kubernetes, with external or self-hosted AI inference. The deployment topology. Users reach the platform only through a DMZ public zone holding a load balancer, web application firewall, firewall and TLS termination; nothing else is publicly reachable. Everything else sits on the client premise, in cloud or on-premises, behind an ingress and service mesh that handles internal routing, security and observability. Workloads are separated into namespaces: an application namespace for platform services including orchestration, agents, studio, retrieval, voice and audit; an infrastructure namespace for messaging, logging and monitoring; and a GPU namespace for self-hosted models covering text, embeddings and speech, which exists only when models run in-house. Persistence is tenant-isolated by design, for both data and retrieval. Enterprise applications may run in the same cluster as their own namespace, in a separate cluster, or remain entirely external and be reached through their existing APIs and databases. Dedicated agent runtimes are available for specialised agents while remaining under the same orchestration and governance. External inference providers are reached over controlled egress only. The whole stack runs on Kubernetes and deploys to AWS, Azure, Google Cloud, private or self-managed Kubernetes, or on-premises and disconnected.

Put it against your own stack.

The fastest way to evaluate this is on your systems, with your data and your constraints. Deployments pair with a solutions engineer, and a first production use case goes live in weeks.

Book a demo See it in production Read the FAQ