Skip to main content
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.

​
Agent

An agent is the unit that answers. It carries:
  • Instructions — composed from ordered 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 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.
See Versions, environments and deploying 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.
  • 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 and Giving an agent a workflow.

​
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.
  • MCP providers — remote MCP servers, whose tools are discovered automatically. See Connecting an MCP server.
  • Connected apps — catalogue toolkits (Gmail, Slack, …) with per-toolkit credential scoping.
  • Platform tools — Sidenet’s own, including the nine rich UI 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.
  • loop_responses — the tool can page, fan out and project fields on its own. See Working with 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.

​
Where to go next

Embed the assistant

Put the chat sidebar in your product with the SDK.

Design a network

Decide how many agents you need and where the boundaries go.

Connect your API

Give agents your endpoints as tools.

Write what they say

Compose instructions from shared, versioned blocks.