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:

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

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.

1. Start the engine

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`

curl http://localhost:18080/health
curl http://localhost:19090/readyz
curl http://localhost:19091/readyz

2. Point the product app at the engine

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:

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:

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.

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

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:

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

{
  "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

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.

6. Validate and activate

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:

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.

Configuration

The full AutomationConfig and environment reference.

Control plane

Versioned config, progressive migration, DLQ.

Config Connector (MCP)

Edit brand config from Claude.

Operations

Deploy, monitor, and roll back.

Temporal Engine ResponseAutomationV2

Get started

Platform

StateSet One

StateSet Response

StateSet ResponseCX

Temporal Engine

StateSet iCommerce

StateSet Commerce

StateSet EDI

StateSet Mail

StateSet Voice

StateSet NSR

AI Agents

StateSet Sandbox

StateSet ACP

StateSet UCP

StateSet ICP

StateSet Sequencer

StateSet Set L2

StateSet Cloud

Tools

Start Automating Responses

Start Automating Responses

Which repo does what

The minimum mental model

1. Start the engine

2. Point the product app at the engine

3. Bootstrap a brand from a template

4. Sync connectors

5. The minimum working config

Workflow binding

Deterministic config

6. Validate and activate

Onboarding via CLI

Configuration

Control plane

Config Connector (MCP)

Operations

​Start Automating Responses

​Which repo does what

​The minimum mental model

​1. Start the engine

​2. Point the product app at the engine

​3. Bootstrap a brand from a template

​4. Sync connectors

​5. The minimum working config

​Workflow binding

​Deterministic config

​6. Validate and activate

​Onboarding via CLI

​Related

Configuration

Control plane

Config Connector (MCP)

Operations

Start Automating Responses

Which repo does what

The minimum mental model

1. Start the engine

2. Point the product app at the engine

3. Bootstrap a brand from a template

4. Sync connectors

5. The minimum working config

Workflow binding

Deterministic config

6. Validate and activate

Onboarding via CLI

Related