Before you begin
Before you start, make sure you have:- Credentials:
ATLAN_GATEWAY_URLandATLAN_TOKENin your environment, from an approved secret store. See Send bearer token. - Workspace: A workspace you can write to.
- Runtime: Where the agent runs, such as your own service, a coding harness, or a provider. Runtime credentials and execution controls stay there.
1
Register agent
name and workspace_id are the only required fields. The others describe the agent so a person or another agent can tell what it is for.id. Keep it in your deployment record instead of looking the agent up by name later.To change the label, instructions, model, step ceiling, or provider and framework links later, use
PATCH /agent/v1/agents/{agent_id}. A change to one of those definition fields does not edit the agent in place: it publishes the agent’s next version — the reply’s version_ordinal is one higher, the previous version stays readable at GET /agent/v1/agents/{agent_id}/versions/{version_ordinal}, and the new version ships under the workspace’s release policy, so a released agent changes the same way. List the version history, newest first, with GET /agent/v1/agents/{agent_id}/versions. An edit of only display_name or description stays in place.To label the version, describe it, or hold it unreleased, publish it explicitly with POST /agent/v1/agents/{agent_id}/versions. The body is the same change set as a patch — send only the definition fields that change, and every other field carries over from the current version — plus a version_label such as v1.2.0, a version description, and auto_release. Omit auto_release to follow the workspace policy’s default; false keeps the version unreleased. The 201 returns the new head with its Location:name is fixed at creation: a patch that changes it is refused with 422, and the patch does not accept workspace_id, owner_id, project_id, or repo_id. To retire an agent, use POST /agent/v1/agents/{agent_id}/archive; there is no destructive delete on the public plane. For a Claude workflow, see Record Claude Managed Agents runs.2
Declare tools and runtime
tools declares what the agent can call. Each entry is one of two shapes:client.agents.update replaces the whole tools list, so send every tool the agent should keep:server and tool values with registry__search or GET /mcp/v1/tools (filter by server_id for one server).tools takes builtin and MCP tool references only, not skill IDs. To give an agent skills, send a skills manifest in the create body or a patch: each entry is one pinned skill, {"skill_id": "skill_01example", "version_ordinal": 3}. An agent version may pin at most 64 skills, each once. An entry without version_ordinal pins the skill’s current release; the registry fills in the ordinal and the version’s digest. A pin never moves on its own — a skill publishing a new release changes no agent until you write a new pin, and on this kind that write is a new agent version. The registry derives one uses_skill relationship per pinned skill shortly after the write and archives the rest, so an agent with a manifest gets its skills from the manifest, not from hand-written edges. To create another relationship type, use registry__relate_artifact or POST /registry/v1/artifacts/{artifact_kind}/{artifact_id}/relationships: the target may be in another workspace of your account — asserting the edge takes update on the source and read on the target — and the agent kind must allow the relationship type, which registry__get_kind_schema lists. One of them, uses_knowledge, records the knowledge bundles an agent reads. It names the bundle rather than one of its versions, so it holds as the bundle changes, and asserting it grants the run nothing: the agent reads the bundle through Registry tools under its own identity and permissions. Read existing relationships with registry__get_related_artifacts, which returns both directions, or GET /registry/v1/artifacts/{artifact_kind}/{artifact_id}/relationships, which lists outgoing edges only, including archived ones. An edge may point into a workspace you can’t read: that end is returned with is_readable: false, and following it returns 404.name, workspace_id, and provider_type. local and custom are catalog entries that are never contacted.POST /agent/v1/environments and POST /agent/v1/agent-frameworks.3
Enable tracing
Tracing is what makes the agent record useful. Pick the path that fits the runtime:Tracing uses its own credentials,
- Your own agent: Use the Trace your first agent run with the agent’s own API key, from Settings > Identity on its profile.
- Coding agent: Install the Claude Code trace plugin. It captures sessions and tool calls with no code change.
- Any OpenTelemetry exporter: Point it at
/otel/v1/traceswith the agent’s API key and workspace. See Send and verify traces. - A session on the Atlan runtime: Nothing to install. Every run is traced as the agent, with its model calls, tool calls, and outcome, and the next step reads those traces back.
ATLAN_API_KEY: runs sent with a personal key are filed under that person and do not appear under the agent, whatever the service_name. Install tracing as in Install atlanai SDK: atlanai[tracing] in Python, the ./tracing subpath plus its OpenTelemetry peers in TypeScript.ATLAN_API_KEY and ATLAN_WORKSPACE_ID, and does not reuse the management bearer token. A process that does both configures both.4
Verify agent and traces
A
2xx confirms the record was accepted, not that it is right. Read back what you wrote:- Read the agent back with
GET /agent/v1/agents/{agent_id}and confirm the workspace is the one you intended, not another your token can also reach. - Read its traces back instead of trusting the export:
- Drill into one trace and its spans with
GET /agent/v1/agents/{agent_id}/traces/{trace_id}and.../traces/{trace_id}/spans, and confirm they appear under the agent.
POST because the query goes in the body:Every
client.agents operation is in the Agents. An agent doing this itself should use MCP instead: registry__search and registry__get_artifact.5
Record completed run by hand (optional)
Do this only for a runtime you cannot instrument. Create the session with the original execution timestamps, not the upload time.
Then append the transcript.
sequence_number fixes the order, so send it explicitly: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.Read the session back and compare its timestamps and session_status with the external runtime. Confirm the message sequence_numbers are contiguous and the transcript reads in order. For provider-run agents, read provider-native activity from GET /agent/v1/sessions/{session_id}/events; session messages hold the transcript records your harness uploads.6
Attach file artifact (optional)
Uploading is a two-step ticket flow: ask for a ticket, then send the bytes.The The SDK wraps both steps, so you do not branch on A successful upload returns
201 returns an upload ticket:When
is_presigned is false, send the bytes to the gateway:is_presigned yourself: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, so check the content type before parsing. The SDK wraps the same calls; see Files. aireg does not handle files.Troubleshooting
If a retried create duplicated a session, an upload returns413, or traces appear under a person instead of the agent, see Agent errors. For other API errors, see Errors and retries.
Next steps
- Send and verify traces: Confirm the agent’s runs arrive and are attributed to it.
See also
- Work with agents: Agent profiles, sessions, and usage in the product.
- Publish and retrieve skills through API: Publish, retrieve, and inspect reusable skills.
- Errors and retries: Recover from a failed write without duplicating it.