Skip to main content
An assistant is a configured instance of a LangGraph graph. While graphs define the agent logic, assistants let you create multiple configurations of the same graph with different names, metadata, and settings.

Default assistants

When the server starts, Aegra automatically creates a default assistant for each graph defined in aegra.json. Aegra accepts the graph ID directly in run and cron APIs and resolves it to that default assistant for you, so you can use graph IDs without creating assistants manually.
This automatically creates a default assistant for the agent graph that run and cron APIs can target immediately by passing assistant_id="agent".

Creating assistants

Create custom assistants with specific configurations:

Idempotent creation

Use if_exists to avoid errors when the assistant already exists:
An assistant has two uniqueness keys: its assistant_id, which is unique across every user, and its graph_id plus config pair, which is unique per owner. Either match counts as “already exists”, so a second create with the same graph and config returns the first assistant rather than a duplicate. Creation is atomic, so callers racing on the same assistant_id — retries, replays, several replicas booting at once — all converge on one stored assistant instead of one of them failing. With the default if_exists="error", a duplicate answers 409. An assistant_id already taken by another user also answers 409: it is never returned to you, even with if_exists="do_nothing".
A client-provided assistant_id must be 1–255 non-blank characters. Omit the field (or send null) to let the server generate a UUID. Longer or blank values are rejected with 422 before they hit PostgreSQL’s btree key limit (~2704 bytes).
The snippets below assume you are inside an async def function with an initialized client — see the example above.

Listing and searching

Updating assistants

Updates are partial: a field you leave out keeps the value it already has. config and context replace, so sending either one explicitly empty clears it:
metadata is different: it merges into the assistant’s existing metadata rather than replacing it, so metadata={} changes nothing and a stored key cannot be removed through this endpoint — only overwritten. name and graph_id are stored as non-null, so supplying either one empty is a 422 rather than a silent no-op. Omit them to leave them unchanged. description is nullable, so an explicit None clears it.

Versioning

Assistants are versioned. Each update creates a new version while preserving the history:

Graph schemas

Retrieve the schemas for an assistant’s graph:
Every key is always present. A schema the server could not derive from the graph is null, so read the value rather than testing for the key.

Graph visualization

Get the graph structure for visualization:
The response includes nodes and edges that can be rendered by LangGraph Studio or custom visualizers.

Subgraphs

If your graph uses subgraphs, you can inspect them:

Deleting assistants

When authentication is enabled, you can restrict deletion to admin users using authorization handlers. See the authentication guide.