> ## Documentation Index
> Fetch the complete documentation index at: https://docs.standardagentbuilder.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> Understanding how Standard Agents works under the hood

# Makeup of a Standard Agent

In order to create a Standard Agent, you define the following:

* **Models**: defines an LLM provider (currently supports OpenAI, OpenRouter, Baseten, Cerebras, and Cloudflare Workers AI) and model and fallbacks.
* **Tools**: a typescript function that can be called by an agent. This is where most business integration logic lives.
* **Prompts**: a prompt defines what the LLM will receive on any given turn of a conversation, including the system message, the available tools, the message history, and more.
* **Agents**: an agent defines the structure and behavior of a conversation, including the type of conversation (AI-Human or Dual-AI), the initial prompt to use, limits on the number of turns, and what ends one side's turns and yields the conversation to the other side.

```mermaid theme={null}
graph TD
    A[Agent] --> P1[Prompt]
    P1 --> M1[Model]
    M1 --> M2[Model]
    P1 --> T1

    subgraph T1[Tools]
        direction LR
        F[Function]
        P2[Prompt]
        A2[Agent]
    end
    P2 --> M3[Model]
    M3 --> M4[Model]
    P2 --> T2[Tools...]

    style A fill:#8b5cf6,stroke:#7c3aed,color:#fff
    style P1 fill:#3b82f6,stroke:#2563eb,color:#fff
    style P2 fill:#3b82f6,stroke:#2563eb,color:#fff
    style T1 fill:transparent,stroke:#f59e0b,stroke-dasharray:5 5
    style T2 fill:#f59e0b,stroke:#d97706,color:#fff
    style F fill:#f59e0b,stroke:#d97706,color:#fff
    style M1 fill:#10b981,stroke:#059669,color:#fff
    style M2 fill:#10b981,stroke:#059669,color:#fff
    style M3 fill:#6b7280,stroke:#4b5563,color:#fff
    style M4 fill:#d1d5db,stroke:#9ca3af,color:#6b7280
    style T2 fill:transparent,stroke:#9ca3af,stroke-dasharray:5 5,color:#9ca3af
    style A2 fill:#8b5cf6,stroke:#7c3aed,color:#fff
```

Structurally an agent has a single prompt, a prompt can have many tools (which can be TypeScript functions, prompts, or agents) and a model, and a model can have multiple fallback models.

## Threads

To actually run an agent, you create a new thread specifying which agent you want to use. In other words you can think of a thread as an instance of an agent.

Each thread is backed by a single Cloudflare Durable Object instance. The `builder()` Vite plugin generates the Worker entry, Durable Object bindings, and migrations; each thread gets its own SQLite database that stores message history, execution state, and detailed execution logs.

To create a thread, you can use the '+ New Thread' button in the AgentBuilder UI, or you can submit an HTTP request:

```bash theme={null}
curl -X POST "https://example.com/api/threads" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_id": "weather_agent",
    "tags": ["type:weather", "user:jane"]
  }'
```

If successful the response will be a JSON object containing the threadId:

```json theme={null}
{
  "threadId": "123e4567-e89b-12d3-a456-426614174000",
  "agent_id": "weather_agent",
  "message": "Thread created successfully"
}
```

A thread's `id` is a cryptographically unique identifier for a given conversation. Keeping track of this id in your client code is important as it allows you to communicate directly with the thread's DurableObject instance.

<Warning>
  Depending on your use case this id may need to be treated as an authentication token. Anyone with the `threadId` has full access to the thread's data.
</Warning>

### Parent/Child Threads (Subagents)

When a prompt delegates to a `dual_ai` subagent, AgentBuilder creates a child thread linked to its parent:

* child thread has isolated SQLite/messages/filesystem
* parent tracks child state in a resumable registry
* communication uses queued messages and lifecycle tools
* attachments are copied across filesystems and rewritten to destination-local paths

This lets one orchestrator thread safely compose many worker/reviewer child threads.

Once a thread is created, you can send new messages to the thread via HTTP request:

```bash theme={null}
curl -X POST "https://example.com/api/threads/123e4567-e89b-12d3-a456-426614174000/message" \
  -H "Content-Type: application/json" \
  -d '{
    "content": "What is the weather in Paris today?",
    "role": "user"
  }'
```

## Messages

Both user provided content and model responses are called "messages" and are stored in the DurableThread database. The message history can be retrieved at via HTTP request:

```bash theme={null}
curl -X GET "https://example.com/api/threads/123e4567-e89b-12d3-a456-426614174000/messages" \
  -H "Content-Type: application/json"
```

Additionally live message data can be streamed via WebSocket, however the simplest way to connect to the WebSocket and use live message data is to implement the `@standardagents/react` package.

## Next Steps

<CardGroup cols={2}>
  <Card title="React Package" icon="react" href="/packages/react">
    Build UIs with @standardagents/react
  </Card>

  <Card title="API Reference" icon="code" href="/api-reference/introduction">
    Read the API reference
  </Card>
</CardGroup>