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

# Start Automating Responses

> The shortest cross-repo path from a running engine to a brand that automates ticket responses.

# Start Automating Responses

The shortest path to turning on automated support responses — which repo to change first, the
minimum config that actually works, and how to prove the engine is handling responses.

## Which repo does what

| Repo                  | Role                                                                                                                                                                                                   |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **response-one-prod** | The product and control surface. Workflow Studio UI and the activation flow. This is where operators edit workflow behavior and publish it.                                                            |
| **next-temporal-rs**  | The execution engine. Temporal workflows, the control-plane validation and activation APIs, brand manifests, and the onboarding CLIs. This is where published config is validated, activated, and run. |

## The minimum mental model

To automate responses you need **all four** of these working together:

1. An engine instance is running.
2. A brand has an **enabled** `response-automation-v2` workflow binding.
3. That binding has enough deterministic config to read ticket context and draft a reply.
4. The brand has **real connectors** for the context sources and dispatch channel you enabled.

<Warning>
  If any one of those is missing, you do not have real automation yet — you have a brand that
  looks configured. Verify all four before assuming tickets are being handled.
</Warning>

## 1. Start the engine

```bash theme={null}
docker compose -f deploy/local/docker-compose.yml up --build -d
```

You should end up with:

| Service              | URL                             |
| -------------------- | ------------------------------- |
| API                  | `http://localhost:18080`        |
| Worker readiness     | `http://localhost:19090/readyz` |
| Dispatcher readiness | `http://localhost:19091/readyz` |

```bash theme={null}
curl http://localhost:18080/health
curl http://localhost:19090/readyz
curl http://localhost:19091/readyz
```

## 2. Point the product app at the engine

```bash theme={null}
WORKFLOW_ENGINE_URL=http://localhost:18080
WORKFLOW_ENGINE_API_KEY=<engine-api-key-if-auth-is-enabled>
```

This is what makes Workflow Studio talk to the Rust engine for health, brand validation, and
brand activation.

## 3. Bootstrap a brand from a template

List the available starters:

```bash theme={null}
curl -X GET "$WORKFLOW_ENGINE_URL/v1/bootstrap/templates" \
  -H "authorization: Bearer $WORKFLOW_ENGINE_API_KEY" \
  -H "x-tenant-id: $ENGINE_TENANT_ID"
```

Then bootstrap:

```bash theme={null}
curl -X POST "$WORKFLOW_ENGINE_URL/v1/bootstrap/brands" \
  -H 'content-type: application/json' \
  -H "authorization: Bearer $WORKFLOW_ENGINE_API_KEY" \
  -H "x-tenant-id: $ENGINE_TENANT_ID" \
  -d '{
    "tenant_id": "YOUR-TENANT-ID",
    "slug": "acme-support",
    "display_name": "Acme Support",
    "template": "ecommerce",
    "activate": false
  }'
```

That single call creates the brand if it doesn't exist, seeds a usable
`response-automation-v2` binding, and returns a validation report.

<Tip>
  Keep `activate: false` on the first run. Bootstrap, review the validation report, sync
  connectors, then activate deliberately as a separate step.
</Tip>

Copy the returned `brand.id` — that's the engine brand you'll keep using.

## 4. Sync connectors

Sync only the connectors your template actually needs. A Gorgias plus OpenAI setup:

```bash theme={null}
curl -X PUT "$WORKFLOW_ENGINE_URL/v1/brands/$BRAND_ID/connectors" \
  -H 'content-type: application/json' \
  -H "authorization: Bearer $WORKFLOW_ENGINE_API_KEY" \
  -H "x-tenant-id: $ENGINE_TENANT_ID" \
  -d '{
    "connectors": [
      {
        "connector_key": "gorgias-inbound",
        "connector_type": "gorgias",
        "direction": "inbound",
        "target": { "base_url": "https://yourbrand.gorgias.com" },
        "auth": {},
        "enabled": true,
        "metadata": { "role": "webhook-source" }
      },
      {
        "connector_key": "gorgias-outbound",
        "connector_type": "gorgias",
        "direction": "outbound",
        "target": { "base_url": "https://yourbrand.gorgias.com" },
        "auth": { "secret_ref": "env://YOUR_GORGIAS_BASIC_TOKEN" },
        "enabled": true
      },
      {
        "connector_key": "openai-primary",
        "connector_type": "openai",
        "direction": "outbound",
        "target": { "base_url": "https://api.openai.com" },
        "auth": { "secret_ref": "env://OPENAI_API_KEY" },
        "enabled": true
      }
    ]
  }'
```

Credentials are referenced by `secret_ref`, not inlined — the engine resolves them at runtime.

If you need Shopify or Recharge **actions**, add those connectors now, before activation.

## 5. The minimum working config

### Workflow binding

```json theme={null}
{
  "workflow_type": "response-automation-v2",
  "template_key": "ResponseAutomationV2",
  "template_version": 1,
  "task_queue": "stateset-response-automation-v2",
  "enabled": true
}
```

### Deterministic config

The smallest useful `deterministic_config` needs:

* `workflow_name: "ResponseAutomationV2"`
* A model choice — `provider` and `model`
* A brand-specific `system_prompt_template`
* At least one ticket context source
* A dispatch channel

For a Gorgias-first setup:

| Section               | Value                                     |
| --------------------- | ----------------------------------------- |
| `context_sources`     | Include `gorgias_ticket`                  |
| `dispatch.channel`    | The real reply channel, usually `gorgias` |
| `review_gate.enabled` | `true` for the first rollout              |

<Warning>
  Keep `review_gate.enabled: true` until you've watched real traffic. It's the difference between
  a bad config producing a queue of drafts to reject and producing replies your customers have
  already received.
</Warning>

## 6. Validate and activate

```bash theme={null}
curl -X POST "$WORKFLOW_ENGINE_URL/v1/brands/$BRAND_ID/validate" \
  -H "authorization: Bearer $WORKFLOW_ENGINE_API_KEY" \
  -H "x-tenant-id: $ENGINE_TENANT_ID"

curl -X POST "$WORKFLOW_ENGINE_URL/v1/brands/$BRAND_ID/activate" \
  -H "authorization: Bearer $WORKFLOW_ENGINE_API_KEY" \
  -H "x-tenant-id: $ENGINE_TENANT_ID"
```

## Onboarding via CLI

For manifest-driven setup rather than API calls:

```bash theme={null}
cargo run -p engine-control-plane --bin import_brand_manifests -- --tenant-id <uuid>
cargo run -p engine-control-plane --bin onboard_brand -- --tenant-id <uuid> --brand <slug>
```

Brand manifests live under `manifests/brands/*.json`.

## Related

<CardGroup cols={2}>
  <Card title="Configuration" icon="sliders" href="/next-temporal/configuration">
    The full AutomationConfig and environment reference.
  </Card>

  <Card title="Control plane" icon="server" href="/next-temporal/control-plane">
    Versioned config, progressive migration, DLQ.
  </Card>

  <Card title="Config Connector (MCP)" icon="plug" href="/next-temporal/mcp-connector">
    Edit brand config from Claude.
  </Card>

  <Card title="Operations" icon="gauge" href="/next-temporal/operations">
    Deploy, monitor, and roll back.
  </Card>
</CardGroup>