> Source: https://wexa.ai/docs/what-is-wexa

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

**Install an SDK**

**TypeScript SDK**

```bash
npm install @wexa-fabric/sdk
```

**Python SDK**

```bash
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.

**Query the context graph**

**Wexa MCP server**

```json
{
  "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"
    }
  }
}
```

**REST API**

```bash
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
  }'
```

**TypeScript SDK**

```typescript
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',
})
```

**Python SDK**

```python
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

**Get started — Choosing a surface**
Pick the surface your code already lives in, then make your first successful call.

**Concepts — Where your data goes**
The four stores, told apart: context graph, knowledge base, data catalog and project ontology.

**Reference — Tool reference**
Every tool, with its arguments, its errors and all four call syntaxes.

**Governance — Policy and approvals**
How a call is allowed, refused, or held until a person answers for it.