What is Wexa

Wexa is the enterprise AI context platform. It gives AI agents governed access to everything an organization knows — its context, knowledge, data and code — without copying any of it into a model.

The important thing to understand first is not a feature. It is a shape.

One platform, four surfaces

Wexa exposes the same set of tools four times over:

• The Wexa MCP server — for an MCP client such as a desktop assistant or an editor
• The REST API — for anything that can make an HTTP request
• The TypeScript SDK — for Node and the browser
• The Python SDK — for everything else

These are four surfaces, not four products. query-context called through the Wexa MCP server and query_context called through the Python SDK reach the same tool, enforce the same policy, write the same audit record and return the same result. The only difference is the syntax you type.

This is why the documentation has one tool reference rather than four. A tool is described once, with its arguments, its errors and what it returns, and each example shows the four call syntaxes side by side. You pick your surface once and read everything else the same way.

The same call, four ways

Two of the four surfaces are packages you install. The other two you call over HTTP, so there is nothing to install for them — which is why this block offers two tabs rather than four. A block only ever shows the surfaces its example actually has.

npm install @wexa-fabric/sdk

pip install wexa

And here is one read of the context graph, written on each of the four. Pick your surface in the tabs below and the rest of the documentation will show you that one, on every page, until you change it.

{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "query-context",
    "arguments": {
      "query": "MATCH (c:Customer) WHERE c.project_id = $project_id RETURN c LIMIT 50"
    }
  }
}

curl -sS https://fabric.wexa.ai/v1/query-context \
  -H "Authorization: Bearer $WEXA_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "MATCH (c:Customer) WHERE c.project_id = $project_id RETURN c LIMIT 50",
    "limit": 50
  }'

import { Fabric } from '@wexa-fabric/sdk'

// Reads WEXA_WORKSPACE and WEXA_API_KEY; pass { workspace, apiKey } instead if
// you would rather be explicit. One of the two is required either way.
const fabric = new Fabric()

const rows = await fabric.queryContext({
  query: 'MATCH (c:Customer) WHERE c.project_id = $project_id RETURN c LIMIT 50',
})

from wexa import Fabric

# Reads WEXA_WORKSPACE and WEXA_API_KEY; pass workspace= and api_key= instead if
# you would rather be explicit. One of the two is required either way.
fabric = Fabric()

rows = fabric.query_context(
    query="MATCH (c:Customer) WHERE c.project_id = $project_id RETURN c LIMIT 50",
)

Four syntaxes, one tool. The same policy decision is taken, the same audit record is written, and the same rows come back.

Not every deployment carries every tool. A tool that is absent is absent on all four surfaces at once, never on some of them, so a call refused as unknown is answered by the deployment rather than by trying another surface. GET /v1/connection-info lists what yours has.

Why the shape matters

Most platforms make you choose a surface early and then live with it. An integration written against a REST API has to be rewritten before an assistant can reach it; an SDK usually lags the API it wraps.

Wexa holds the four surfaces at parity deliberately, and tests that parity rather than trusting it. A tool that exists on one surface exists on all four. That has three consequences worth knowing before you start:

1. Prototype anywhere, ship anywhere. Try something in an editor through the Wexa MCP server, then move the same call into production Python without changing what it does.
2. Governance is not per-surface. Policy decisions, approvals, quota and audit sit underneath all four. There is no surface that is a way around the rules, because the rules are not in the surface.
3. One thing to learn. The concepts below are the same whichever surface you use.

What Wexa holds

A project — the unit of both work and isolation — holds four stores. They are the most common source of confusion for newcomers, so they are worth separating up front:

• The context graph is the nodes and relationships describing your world. It is the only one of the four that is a graph, and the only one you query by traversing relationships.
• The knowledge base is documents and passages retrieved by meaning rather than exact match. It is the only one holding unstructured prose.
• The data catalog is the inventory of your data assets and their lineage, quality and ownership. It is the only one describing data that lives outside Wexa.
• The project ontology is your project's vocabulary of node and relationship types. It is the only one that describes the shape of another store rather than holding content of its own.

Underneath a project ontology sits the platform schema — the fixed, platform-wide vocabulary every project shares. You extend your project ontology at runtime; the platform schema you do not touch.

What Wexa runs

An agent is one LLM worker definition: a set of instructions, tools and model configuration. A process flow is a multi-agent orchestration — a manifest naming several agents and the order in which they run. An agent is not a small process flow; they are different kinds of thing, they version separately, and they promote and roll back separately.

Agents reach the outside world through skills, which arrive when you provision a connector. Every run is an execution, with its inputs, outputs and trace kept.

Governance is not a layer you add

Every call through every surface passes a policy decision first. The answer is to allow, to refuse, or to require an approval from a person. What happened is written to the audit record, and what it cost is drawn from quota and credits.

None of this is optional and none of it is bolted on at the edge. It is the reason the four surfaces can be at parity: the rules live below all of them.

Where to go next