> ## Documentation Index > Fetch the complete documentation index at: https://sidenet.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > The five objects everything else is built from, how they relate, and which one to reach for. Sidenet is built from five objects. Everything in the Studio and every endpoint in the API is one of them, or a version of one of them. | Object | What it is | Versioned | | ------------ | ------------------------------------------------------------------------------------------------- | ------------------------------------ | | **Agent** | One AI specialist: instructions, tools, memory, a model | Yes | | **Network** | A team of agents (and workflows) plus the routing that picks between them, and the chat UI config | Config, deployed across environments | | **Workflow** | A deterministic graph of steps | Yes | | **Tool** | Something an agent can call: your API, an MCP server, a UI component | No — but references are stable | | **Thread** | One conversation, with its messages, votes and traces | No | ## Agent An agent is the unit that answers. It carries: * **Instructions** — composed from ordered [prompt blocks](/docs/prompt-blocks), which can be shared across agents, carry `{{variables}}` filled per request, and be included conditionally. * **Tools** — chosen individually from your tool catalogue. An agent holds exactly the tools it needs, including which [rich UI components](/docs/components) it may render. * **A model, or a routing policy.** A `policy/…` slug lets the model router pick per request; the trace records which model actually served the turn. * **Memory** — recent messages, active notes (working memory), long-term knowledge (semantic recall) and conversation summary (observational memory), each switchable. * **Limits** — `max_steps` bounds how many model round-trips a turn may take before the agent must write its answer. * **Sub-agents** — optional internal workers, called like tools. A sub-agent is a capability of its parent, not a destination for routing. **Agents are versioned.** There is a mutable draft (v0), immutable published versions (v1, v2, …), and an active pointer. Publishing creates a version; activating makes it the one that serves traffic. A published version renders the same prompt forever, because its block references are pinned at publish time. Rolling back is repointing, not re-editing. ```text theme={null} PATCH /v1/agents/:id/draft # edit POST /v1/agents/:id/publish # freeze as vN POST /v1/agents/:id/activate # make vN live GET /v1/agents/:id?version= # active | 3 | draft | latest | ``` See [Versions, environments and deploying](/docs/versions-and-environments) for the whole lifecycle. ## Network A network is a team of agents that presents as one assistant. It holds: * **The roster** — which agents and workflows are attached. Each resolves to its own active version, so activating a new agent version reaches the network without redeploying it. * **The routing** — a handoff prompt that decides which single agent takes each message. See [Designing a network](/docs/designing-a-network). * **The chat configuration** — `sdk_ui`: greeting, suggestions and theme tokens. Layout and position are SDK init options. * **Tool credential requirements** — reported on the network's read: which providers take per-user credentials, and the fields each expects. A network exists per environment — **Dev, Staging, Prod** — and configuration is promoted from one to another by deploying. Traces are tagged with the environment of the network that served them, so preview traffic and production traffic never mix in your numbers. One agent is a perfectly good network. Don't add a second agent until the first one's tool list is large enough that tool selection starts to degrade. ## Workflow A workflow is what you use when the sequence must not be left to a model's judgement. It is a declarative graph: * **Steps** can be an agent (configured inline on the step), a tool, another workflow, a data mapping, or a JavaScript **code** step for arithmetic and reshaping. * **Flow operators** cover sequencing, branch, foreach, loop, parallel, sleep and `sleep_until`. * **References** between steps are pickable paths (`{{ $.steps.fetch.items[0].id }}`), and renaming a step in the Studio rewrites every reference to it. Workflows use the same draft → publish → activate lifecycle as agents, and can be run three ways: from the Studio, from `POST /v1/workflows/:id/run` (optionally streaming), or **as a tool an agent calls**. When an agent calls one, it always runs the active version — so publishing and activating a new version reaches every agent using it on the next turn, with no republish of the agent. See [Building a workflow](/docs/workflows) and [Giving an agent a workflow](/docs/workflows-as-tools). ## Tool A tool is anything an agent can call. Tools live under a **provider**: * **API providers** — your REST endpoints, imported from an OpenAPI spec or added by hand. See [Connecting your API](/docs/connecting-your-api). * **MCP providers** — remote MCP servers, whose tools are discovered automatically. See [Connecting an MCP server](/docs/connecting-mcp). * **Connected apps** — catalogue toolkits (Gmail, Slack, …) with per-toolkit credential scoping. * **Platform tools** — Sidenet's own, including the nine [rich UI components](/docs/components) an agent uses to answer with a chart or a table instead of markdown. Two per-tool flags change how a tool behaves once an agent holds it: * **`require_approval`** — the run pauses and asks the user before this tool is called. See [Approvals](/docs/approvals). * **`loop_responses`** — the tool can page, fan out and project fields on its own. See [Working with large APIs](/docs/large-apis). An agent's tool references are stable identifiers, so renaming a tool or its provider never detaches it from the agents using it. ## Thread A thread is one conversation. It holds the messages, the votes your users cast, and the traces of every turn — which agent answered, which model served it, which tools ran, what it cost, how long it took. Any thread can be reopened read-only in the Studio, showing exactly what your user saw. ## How they fit together A request arrives at a network. Routing picks one agent. That agent runs, calling tools — possibly including a workflow, possibly pausing for approval — and writes an answer, placing any components inside it. The turn is recorded as a trace against a thread, attributed to a billing group, and its cost is attributed by a sweep that normally lands moments after the answer. See [Traces, cost and billing groups](/docs/observability). ## Where to go next Put the chat sidebar in your product with the SDK. Decide how many agents you need and where the boundaries go. Give agents your endpoints as tools. Compose instructions from shared, versioned blocks.