The work graph.

Everything a team produces lives on one graph. Tasks, docs, meetings, contracts, contacts, files, decisions: each is a node. The relationship between them, who wrote it, what it's about, what depends on it, is an edge. Read this once and the rest of wrxstack makes sense.

Why a graph

A folder hierarchy makes a strong assumption: every artifact has one parent. That's wrong for knowledge work. A pricing one-pager is "about" Acme, "owned by" Sales, "drafted in" Docs, "referenced in" the closeout deck, and "linked from" three meetings. A folder forces you to pick one. A graph lets each relationship stand on its own.

The practical consequence: when the Acme renewal opens next year, your assistant can pull every doc, meeting, contract, ticket, and email tied to Acme without you having organized them in advance. You wrote the work. The graph organized itself.

Nodes

A node is anything addressable. Twelve types ship in the base platform:

Custom types are available on Business and Enterprise plans. Define one in graph.toml and it gets a stable prefix, a UI, and the full audit pipeline for free.

Edges

Edges are typed. The same two nodes can have multiple edges between them; an account is both about and customer-of a relationship. Common edge types:

• about, the most common. A doc is "about" an account.
• authored-by, links a node to the person who wrote it.
• references, soft link from one node to another it cites.
• depends-on, hard link. A task can't close until the dependency does.
• derived-from, the assistant emits these when it drafts from a source.
• scopes, identity edge. Used by permissions; see below.

Permissions inherit along edges

This is the part most teams find new. When a user can read an account, they can read every node connected to it through an about edge. When you revoke their access to the account, the read implicitly drops on all linked nodes. There's no per-doc ACL drift.

The model is intentionally simple: edges carry permission unless explicitly broken. To keep a doc readable independent of its account, mark the edge private when you create it.

Querying the graph

The SDK exposes a query function that takes a starting node and a traversal spec. The result is a list of nodes with their edges back to the seed. Most useful queries are one or two hops.

from wrxstack import Client

client = Client()

# Everything related to Acme's renewal
nodes = client.graph.query(
    seed="acc_01HQ3K...",
    edges=["about", "references", "derived-from"],
    types=["Document", "Meeting", "Contract", "Task"],
    since="2025-09-01",
    limit=50,
)

for n in nodes:
    print(n.type, n.id, n.title, n.last_modified)

The query is permission-aware. A user who can't see a node won't see it in the result; they also won't see edges that point to it. Audit logs the query, the seed, and the row count returned, never the contents.

Events

Every write to the graph emits an event. Every event is durable, ordered per workspace, and replayable. Your assistant subscribes to events the same way a webhook does, but without leaving the platform. See the webhook docs for the external delivery format.

Next steps

• Assistants, how the runtime acts on the graph.
• Permissions, the full identity model.
• Search API, the query interface for the graph.