Skip to main content
A chat is a conversation. An agent is a saved configuration. An agent run is one execution of that configuration—and every run has an associated chat that stores its conversation and output.

​
Four terms that matter

TermWhat it isHow long it lives
ChatAn ad-hoc conversation against a knowledge baseUntil deleted
AgentA saved, versioned goal, instructions, model, KB, and capabilitiesAcross many runs
Agent runOne execution of an agent, with status, usage, output, and a pinned core configurationOne task or continued agent conversation
Agent-run chatThe messages and partial/final output associated with a runStored with the run

​
Choose chat or agent

Use a chat to explore, ask one-off questions, or change Quick/Deep mode per turn. Use an agent run when the work should follow a saved goal and capability set, be attributable to an agent version, appear in run history, or run on a schedule.

Use chat

Exploration, ordinary Q&A, changing topics, or choosing Quick/Deep per message.

Use an agent run

Repeatable jobs, tool use, delegation, scheduling, monitoring, and auditable execution history.

​
What happens during an agent run

1

Start

Sending an agent message creates a run and its associated chat. The run records the agent version and trigger type.
2

Execute

The agent always uses Deep mode and can search its KB, use enabled tools and skills, query data, or delegate.
3

Persist

Messages, sources, usage, tool-aware history, and partial or final output are stored with the chat and run.
4

Finish

The run becomes completed, failed, or cancelled. Queued and active work use queued and running.
Agent configuration
      │
      ▼
Agent run ─────────► status + usage + output
      │
      └────────────► associated chat ─► messages + sources + context

​
Continuing an agent run

The first agent message returns chat_id and run_id. Pass that chat_id on the next agent message to continue the same agent conversation and reuse its run.
Agent-run chats are kept with agent runs rather than mixed into the normal chat list. Open them from the agent’s run history.

​
Version behavior

A run pins the agent’s core goal, instructions, model, and tools when it starts. A later deploy does not rewrite an in-progress run. Skills resolve when the run begins, and delegated agents resolve when called, so a run is attributable to its pinned core configuration without promising identical model output.

​
Build it with the API

Create a normal chat: 
curl -X POST "$AUTOSAGE_URL/chats" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "id": "CHAT_UUID",
    "tenant_id": "TENANT_ID",
    "knowledge_base_id": "KB_ID",
    "model": "MODEL_ID",
    "message": "What changed in the returns policy?",
    "agent_mode": "quick"
  }'
Start an agent run: 
curl -X POST "$AUTOSAGE_URL/agents/AGENT_ID/messages" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "message": "Review the returns policy and identify support risks." }'
Continue it with the returned chat: 
curl -X POST "$AUTOSAGE_URL/agents/AGENT_ID/messages" \
  -H "Authorization: Bearer $AUTOSAGE_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "message": "Turn those risks into an action list.",
    "chat_id": "AGENT_CHAT_ID"
  }'

​
Continue the learning path

Share context between KBs

Let this run ask a specialist agent in another KB.

Agent lifecycle

See versions, schedules, stopping, and terminal states in depth.