Skip to main content

ResponseCX Platform

The AI Workforce platform. Outcome-priced AI agents that resolve customer work end to end across commerce and CX — cancel orders, process returns, update subscriptions, issue refunds — with audit trails and human escalation. The platform ships as a multi-tenant Next.js app hosted on GKE. ResponseCX is the customer-facing product surface; StateSet is the company and category brand.

Architecture

Node 22.x is required and enforced on preinstall, predev, and prebuild.

Primary surfaces

Outcome model

The platform sells outcomes, not seats. Each outcome is a verified, end-to-end resolution priced against BPO labor. The canonical contract is the SKU catalog in lib/outcomes/sku-catalog.js. Two SKUs are live today — Triage Outcome (0.50)andResolvedCustomerContact(0.50) and Resolved Customer Contact (2.00) — with the rest in development. See StateSet Billing for the catalog. High-Value Actions, by default anything at or above $100, require human approval before the engine executes them. This is configured per brand in Workflow Studio’s Review Gate phase. Disputes are persisted in Stripe customer balance transactions, where a negative amount is a credit on the next invoice. Customers can flag an outcome within 14 days from the Outcome Accounting Dashboard.

Workflow Studio

The Studio configures a 15-phase Temporal pipeline per brand. New brands can start from a template that pre-fills 14+ phases: The editor supports a List ↔ Graph view toggle, a ⌘K phase jumper, ⌘S save, per-phase ? explainers, and a pending-changes diff against the last saved config — so you can see what you’re about to change before saving.

Org provisioning

Creating an org runs all of this in one request:
  1. WorkOS org created, creator set as org:admin
  2. Hasura organizations and access_tokens rows created
  3. Qdrant KB collection created ({slug}_customer_support)
  4. Default AI agent created
  5. Stripe customer created
  6. Workflow engine tenant registered
  7. Default workflow brand created, from a template if one is specified
  8. All IDs written back to access_tokens

API conventions

There are roughly 600 API routes, all behind applyApiGuards. Every route follows the same shape:
The guard provides rate limiting, method validation, WorkOS auth, body-size limits, request timing, a structured logger, and request-id propagation. Auth options: auth: true (user required), auth: { requireOrg: true }, auth: { requireAdmin: true } (implies requireOrg), and auth: { allowInternal: true }.

Security rules

These are enforced project-wide:
  • Never return error.message to clients. Use respondError(res, status, 'Safe message') and log the detail server-side.
  • Validate external URLs with assertSafeUrl() from lib/security/ssrf.js, or pass ssrfCheck: true to fetchWithTimeout.
  • All MCP tool schemas need bounded .max() on arrays.
  • Admin-only routes use auth: { requireAdmin: true } — the guard enforces it, so the handler must not re-check.

Deployment

Auto-deploys on push to master. The workflow builds via Cloud Build, runs kubectl set image, watches the rollout, smoke-checks /api/health, then commits the new tag back to the deployment manifest so git tracks live state. Required GitHub secrets: GCP_SA_KEY, GCP_PROJECT_ID, GKE_CLUSTER, GKE_REGION, GKE_NAMESPACE, GKE_DEPLOYMENT, GAR_IMAGE_PATH.

Public API (v1)

Build and tune agents programmatically.

MCP servers

Agent-building and analytics over MCP.

Onsite chat

Embed the chat widget.

Billing

Outcome SKUs, plans, and disputes.