agentc
GitHubagentc-sh/agentc
agentc
GitHubagentc-sh/agentc
›Introduction
Get started›Concepts in 5 minutes›Build your first agent›Add your first tool›Serve and connect
Concepts›Architecture overview›The manifest›The compilation pipeline›Archetypes›The graph›Tools and capabilities›Runtime libraries›Skills›Agents and prompts›Serving and protocols›Observability
Guides›Author a manifest›Write a tool›Give your agent a filesystem›Control network egress›Connect external tools via MCP›Connect agents via A2A›Use the bash tool›Control tool access with capabilities›Write templated prompts›Manage prompts with Langfuse›Pass context from the client›Configure a model provider›Connect a CopilotKit frontend›Deploy a standalone binary›Deploy with Docker and PostgreSQL›Instrument with OpenTelemetry›Extend code generation with blocks
Reference
Manifest
Runtime
ReAct
HTTP
›Prompt templates›State
›Observability

ReAct

The ReAct graph, its runtime contract, and the reference pages that describe it.

The ReAct (Reason + Act) graph is the graph implementation shipped in this distribution. It runs a reasoning loop: receive input, call the model, the model may request tools, tools execute and return results, the loop repeats until the model produces a final response. Every step is checkpointed so the agent can survive crashes and resume from where it left off.

The graph is selected explicitly in the manifest with graph { type = "react" }. Once selected, ReAct defines the runtime contract for the agent: durable sessions and runs, persisted messages, a client-visible context object, a set of prompt variables, and the event stream that drives the HTTP surface.

Because this contract is specific to the graph, its reference lives here rather than in a shared location. A different graph would expose a different set of endpoints, prompt variables, and state.

Sessions and runs

A session is the durable container for a conversation. A run is one execution of the graph inside a session. The runtime persists both, so a client can return later and inspect history without having to replay the original request immediately. Messages are persisted separately from run state, so a client can read conversation history outside of an active run.

Runs can be started in attached mode, where the starting request streams events until the run finishes, or detached mode, where the server returns the run and session IDs and keeps executing the run in the background. Active runs can also be observed through a live reattach stream. Reattachment does not replay earlier events; persisted run and message history remain available through the read endpoints.

Because every step is checkpointed, a run can also be started from an earlier checkpoint instead of the session's latest state. Doing so creates a new run whose history descends from the chosen checkpoint, so the original run's history is left unchanged. List a session's checkpoints with the checkpoints endpoint to find one to start from.

Reference in this section

  • HTTP reference: the native /v1 endpoints for sessions, messages, runs, and live run event streams.
  • Prompt templates: the variables the ReAct graph injects into the system prompt.
  • State: the run state structure, how tools update it, and what clients can see.

The AG-UI add-on translates the same underlying graph behavior into the AG-UI event schema. It is a protocol wrapper rather than part of the graph, so it is documented separately under AG-UI.

← PreviousJavaScriptNext →HTTP reference

© 2026 pogue.dev. All rights reserved.

Creative CommonsCC BY 4.0
On this pageSessions and runsReference in this section

Search docs

Search the agentc documentation