Skip to main content
Use this cookbook to register an Agent, describe what it can do, and preserve the evidence of what it did. Atlan catalogs the Agent and its activity. It does not start or execute the run.
Run Agent workloads in your configured provider or coding harness. Keep runtime credentials and execution controls in that environment.
If you can change the agent’s code, do not build session records by hand. The tracing SDKs report sessions, spans, cost, and scores as the run happens, in Python and TypeScript. For a coding agent, the Claude Code trace plugin captures sessions with no code change at all. Hand-built session records are for the case those cannot cover — a runtime you do not control, or a run reconstructed after the fact.
Every example below assumes ATLAN_GATEWAY_URL and ATLAN_TOKEN in your environment, and a workspace you can write to. Read authentication first.

1. Register an Agent

name and workspace_id are the only required fields. Everything else describes the Agent so a reader — human or agent — can tell what it is for.
Or with the SDK, which is the shorter path if you are already in Python or TypeScript — see Install:
The response carries the Agent’s id. Keep it in your deployment record rather than looking the Agent up by name later. To change any of it later, PATCH /agent/v1/agents/{agent_id}. To retire an Agent, POST /agent/v1/agents/{agent_id}/archive — there is no destructive delete on the public plane. For a Claude workflow, see Claude Managed Agents.

2. Give the Agent its tools

tools declares what the Agent can call. Each entry is one of two shapes:
With the SDK, on an Agent that already exists — agent_patch_agent replaces the whole tools list, so send every tool the Agent should keep:
Find the server and tool values with registry__search or GET /tools/mcp/v1/servers/{server_id}/tools. See the MCP overview for the catalog.
tools is not how Skills attach to an Agent — see Skills and Agents below.

3. Register a provider

A provider records where the Agent runs. Required: name, workspace_id, and provider_type, which is local or custom.
Or with the SDK:
Pass the returned id as agent_provider_id when you create or patch the Agent. Keep provider credentials out of source code, URLs, browser storage, and committed configuration — the provider record is a catalog entry, not a credential store. Environments and frameworks work the same way, at POST /agent/v1/environments and POST /agent/v1/agent-frameworks.

4. Enable tracing

This is what makes the Agent record useful rather than decorative.

Your own agent

Use the tracing SDK. Set service_name to the Agent’s name so its runs attach to this record.

A coding agent

Install the Claude Code trace plugin. No code change; sessions and tool calls are captured locally and exported.

Anything OTel

Point an existing OTLP exporter at /otel/v1/traces with your API key and workspace.
With the tracing submodule, the same service_name you gave the Agent ties its runs to this record. Install it as described in Install — atlanai[tracing] in Python, the ./tracing subpath plus its OpenTelemetry peers in TypeScript.
Tracing uses its own credentials — ATLAN_API_KEY and ATLAN_WORKSPACE_ID — and does not reuse the management bearer token. A process doing both configures both. Verify by reading the Agent’s traces back rather than trusting the export:
Then drill into one trace and its spans with GET /agent/v1/agents/{agent_id}/traces/{trace_id} and .../traces/{trace_id}/spans.

5. Record a completed run by hand

Only for a runtime you cannot instrument. Create the session with the original execution timestamps, not the time you uploaded it.
Then append the transcript. sequence_number fixes the order, so send it explicitly rather than relying on insertion order:
The same two steps with the SDK:
message_role is system, user, assistant, or tool. For a tool call, use message_role: "tool" with tool_name and tool_call_id so the call lines up with the assistant message that requested it.
Session and message creates are not retried automatically, and a retried create can duplicate a record. sequence_number does not deduplicate — it only orders. Retry deliberately and read the transcript back before appending more.
For provider-run Agents, inspect provider-native activity through GET /agent/v1/sessions/{session_id}/events. Use session messages for the transcript records your harness uploads.

6. Attach a file artifact

Uploading is a two-step ticket flow: ask for a ticket, then send the bytes.
The 201 returns an upload ticket: Check is_presigned before sending. When it is true, send the bytes to upload_url as given and do not attach your Atlan token — that URL carries its own authorization. When it is false, send them to the Gateway:
With the SDK both steps are wrapped, so you do not have to branch on is_presigned yourself:
A successful upload returns 204 with no body. Confirm it by listing files:
GET /file/v1/files/{file_id}/content returns the current bytes, and GET /file/v1/files/{file_id}/versions/{version_ordinal}/content a pinned version. Both return the stored media type, not JSON — check the content type before parsing, or you will write a corrupt file. From the CLI, atlanai file upload and atlanai file download do this in one command — see the files guide.

7. Find and inspect Agents

Search and aggregation are POST because the query goes in the body:
With the SDK:
All 79 agent operations are in the agent operations reference. An agent doing this itself should use MCP rather than the API — see registry__search and registry__get_artifact.

Skills and Agents

Skills and Agents are related through the Registry’s artifact graph, and that graph is readable but not publicly writable today. You can read the edges around any artifact:
  • registry__get_related_artifacts returns the exact incoming and outgoing edges for one artifact, each with its relationship type, direction, status, and the artifact at the other end.
  • registry__search with strategy: "group" returns a ranked graph neighbourhood from a query.
  • registry__get_artifact includes relationship context for a known artifact.
There is currently no public endpoint or MCP tool that creates a relationship, so an Agent cannot be linked to a Skill through the public surface. Two things that look like they would, and do not:
  • tools on an Agent takes builtin and MCP tool references only, not Skill ids.
  • atlanai skill link associates a local directory with an existing server-side Skill so later pushes append versions to it. It does not link a Skill to an Agent.
If you need that link, raise it with your Atlan contact rather than constructing an edge another way. To hand a reviewed Skill to an agent runtime in the meantime, see Discover and use a skill and the Skills cookbook.

Verify the result

A 2xx confirms Atlan accepted the record. It does not confirm the record is right. Before you rely on it:
  1. Read the Agent back and confirm the workspace is the one you intended — not another your token can also reach.
  2. Read the session back and compare its timestamps and session_status against the external runtime.
  3. Confirm message sequence_numbers are contiguous and the transcript reads in order.
  4. For traces, confirm they appear under the Agent, not just that the export returned success.

Agents in the product

Lifecycle, sessions, and trace inspection.

Tracing SDK

Report runs as they happen instead of reconstructing them.

Errors and retries

Recover from a failed write without duplicating it.

Skills cookbook

Publish, retrieve, and inspect reusable Skills.