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

# Quick start

> A working agent in three requests. No signing keys, no connection, nothing to host.

The shortest path to a live agent uses a workspace API key and three HTTP calls. You need no keypair, no JWKS document, no connection, and no endpoint of your own — those arrive later, when the agent needs to call *your* backend.

<Steps>
  <Step title="Get an API key">
    In the dashboard, open **Developers** and copy a secret key (`sk_…`). Keep it server-side.
  </Step>

  <Step title="Publish an agent">
    Follow [Your first agent](/first-agent). You need its public id, which looks like `agent_4f3c…`.

    An agent with no patches wired still works — every agent can ask questions and hand off out of the box.
  </Step>

  <Step title="Make the three calls below" />
</Steps>

## 1. Open a thread

A thread is one conversation, and it belongs to a [subject](/guides/subjects) — an opaque id you choose for whoever the agent is acting for.

```bash theme={null}
curl -X POST https://api.usepatchwork.co/v1/loom/threads \
  -H "Authorization: Bearer sk_live_..." \
  -H "Patchwork-Subject: user_9f2" \
  -H "Content-Type: application/json" \
  -d '{"agent": "agent_4f3c..."}'
```

```json theme={null}
{
  "status": "success",
  "data": {
    "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "agent": { "name": "Support assistant" },
    "subject_ref": "user_9f2"
  }
}
```

## 2. Say something

```bash theme={null}
curl -X POST https://api.usepatchwork.co/v1/loom/threads/3fa85f64-.../messages \
  -H "Authorization: Bearer sk_live_..." \
  -H "Patchwork-Subject: user_9f2" \
  -H "Content-Type: application/json" \
  -d '{"content": "What can you help me with?"}'
```

```json theme={null}
{
  "status": "success",
  "data": {
    "run_id": "7c9e6679-7425-40de-944b-e07fc1f90ae7",
    "thread_id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
    "state": "running"
  }
}
```

`202`. The turn is accepted, not finished — a [run](/guides/runs) is the unit of work, and it is still going.

## 3. Read the reply

```bash theme={null}
curl https://api.usepatchwork.co/v1/loom/runs/7c9e6679-... \
  -H "Authorization: Bearer sk_live_..." \
  -H "Patchwork-Subject: user_9f2"
```

```json theme={null}
{
  "status": "success",
  "data": {
    "state": "closed",
    "terminal": true,
    "cost_credits": 0.08,
    "message": {
      "role": "assistant",
      "content": "I can help you track an order, start a return, or update your details.",
      "created_at": "2026-08-30T12:00:04Z"
    }
  }
}
```

Poll until `terminal` is `true`. That is your agent working.

<Note>
  A run can also stop and wait for you — with a question, or with a write that needs approval. Both show as `awaiting_input`, and both are resumed differently. See [Runs and states](/guides/runs).
</Note>

## Where to go next

You now have a conversation. What you probably want next is an agent that does something in *your* system, and a way to put it in front of real users.

<CardGroup cols={2}>
  <Card title="Choose an integration" icon="route" href="/integration-modes">
    Relay from your backend, or direct from the browser.
  </Card>

  <Card title="Connect your backend" icon="plug" href="/guides/connections">
    Register a host so the agent can call your endpoints.
  </Card>

  <Card title="Patches" icon="puzzle-piece" href="/guides/patches">
    Wrap your endpoints as capabilities the agent can use.
  </Card>

  <Card title="Subjects" icon="fingerprint" href="/guides/subjects">
    Get the isolation boundary right before you have real users.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.