Chat vs. agent runs

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

Term	What it is	How long it lives
Chat	An ad-hoc conversation against a knowledge base	Until deleted
Agent	A saved, versioned goal, instructions, model, KB, and capabilities	Across many runs
Agent run	One execution of an agent, with status, usage, output, and a pinned core configuration	One task or continued agent conversation
Agent-run chat	The messages and partial/final output associated with a run	Stored 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

Start

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

Execute

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

Persist

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

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"
  }'

Get started

Core concepts

Lifecycles

Guides

API reference

Chat vs. agent runs

Four terms that matter

Choose chat or agent

Use chat

Use an agent run

What happens during an agent run

Continuing an agent run

Version behavior

Build it with the API

Continue the learning path

Share context between KBs

Agent lifecycle

​Four terms that matter

​Choose chat or agent

Use chat

Use an agent run

​What happens during an agent run

​Continuing an agent run

​Version behavior

​Build it with the API

​Continue the learning path

Share context between KBs

Agent lifecycle

Four terms that matter

Choose chat or agent

What happens during an agent run

Continuing an agent run

Version behavior

Build it with the API

Continue the learning path