An agent is an LLM agent hosted by the platform: a model, instructions, tools, and the data of its project within reach. It lives in a project like a dataset does, is versioned like a SQL query, and is defined by one file, agent.md.

​
The definition file

ops.agent.md
The YAML frontmatter declares what the agent has, the Markdown body is its instructions. A file named *.agent.md anywhere in a repository the platform scans becomes an agent of the repository’s project, versioned with the code. An agent can also be created and edited from the Atlas interface or POST /agents, with the structured fields or the raw definition text.

​
What a bound resource gives

Each binding becomes tools named <slug>__<capability>, generated from the resource’s kind: The agent’s instructions are completed with a section listing these tools and asking the model to use them before its own knowledge; an ontology, when bound, is queried first. GET /agents/{id}/tools shows the resolved list, and POST /agents/{id}/tools/{name}/invoke calls one by hand, with the caller’s own rights: a tool never gives an agent more than its user may read.

​
Skills and MCP servers

A skill is a SKILL.md file of instructions the agent loads when a task calls for them, from the platform’s library or from the project; an MCP server is a remote server whose tools the agent gets at run time, declared once per project with its credential encrypted. Both are named in the definition and detailed on their own pages: Skills and MCP servers.

​
Sessions

A conversation is a session: the history is kept server-side, only the new input travels, and a session is private to whoever opened it.
The body takes input, stream, and per-turn overrides model, temperature and timeout. The reply is an agent.message with the session_id, the content, the thinking the model produced when it exposes it, the tool calls it made and the token usage. GET /agents/{id}/sessions lists your sessions, GET/DELETE .../sessions/{session_id} read or drop one. With "stream": true the reply is server-sent events, one JSON frame per line, ended by data: [DONE]: answer frames carry content, reasoning frames event: "thinking", and each tool call a tool_started then a tool_completed frame with the tool’s name, arguments and result. Tool traffic never rides the text. Every turn is traced: the model calls, the tool calls and the tokens, filed under the agent’s project. See Telemetry.

​
Klara, the built-in assistant

Klara is an agent the platform ships, reachable by everyone at POST /klara with no setup: a build assistant that creates projects, datasets, ontologies and pipeline code when asked, and that, inside a project, has the project’s data as tools exactly like a bound agent does. Each turn names the organization or project to work in (organization_id, project_id); with several possible and none given, Klara asks rather than picks. The REST API pages list what the gateway exposes today.
These endpoints are served by the platform and used by the Atlas interface; they are being opened on the public gateway progressively, and the Python library does not wrap them yet. The API reference lists what the gateway exposes today.