Skip to main content
An AI Harness lets your Flowyte agent hand a live conversation to your own operator agent. When a chat or SMS conversation meets a rule you set, Flowyte opens a durable escalation and notifies your harness (Hermes, OpenClaw, or any runtime you build). Your harness claims the conversation and talks back and forth with the customer in the same thread, then resolves it, returns control to the Flowyte AI, or asks for a human. Flowyte owns the conversation record and keeps enforcing compliance; your harness is a participant. It reaches the customer in their original thread — a chat widget shows a “specialist has joined” divider; an SMS thread continues as a normal text.

​
Set it up

1

Connect your harness

In Integrations, connect your AI Harness provider (hermes or openclaw). The escalation surface stays hidden until at least one harness is connected.
2

Create a connector key

Mint a scoped API key for your harness in the dashboard’s Developer page, granting only the escalations:* scopes it needs (see the connector reference). A connector key can work conversations but can’t edit your destinations or agents.
3

Add a destination

Register where conversations go: POST /escalation-destinations with your harness’s endpoint_url and the channels it handles (chat, sms, or both). The response returns a signing secret (whsec_…) once — store it; your harness verifies webhook signatures with it. The destination starts unverified.
4

Run the handshake test

POST /escalation-destinations/{id}/test opens a sandbox escalation and calls your endpoint. Your harness must receive → claim → reply → resolve within the window. Only a green run flips the destination to active; the response reports a step-by-step ledger with a hint on failure.
5

Set the agent's escalation policy

PUT /agents/{id}/escalation-policy sets an ordered list of rules — when to escalate and where to route. Rules match on deterministic conditions (an explicit request for a person, a human request, business hours, channel, a failed tool or knowledge lookup) and route to an active destination, an email fallback, or a queue.
6

Publish the agent

The policy edits the agent draft. Publish so live phone and chat traffic use it.
The policy is per agent — two agents in one organization can route to entirely different harness destinations. Destinations are shared organization-level infrastructure; the policy decides which agent uses which.

​
What runs a conversation

Once a destination is active and a policy rule matches, a live conversation follows this loop:
  1. Flowyte opens an escalation and sends your harness a signed webhook naming the channel and a short reason.
  2. Your harness claims the escalation, reads the handoff context (a transcript window plus the escalation reason and any verified identifiers), and starts replying.
  3. Each reply reaches the customer in their original thread; each customer message is forwarded to your harness. While your harness owns the thread, the Flowyte AI stays silent.
  4. Your harness ends the conversation — resolve (done), return (hand back to the AI, which resumes on the next customer message), or request a human (routes to your human fallback).
Your harness can also start the conversation instead of waiting to be handed one: POST /escalations opens a new SMS thread with a customer and sends the first message. The session comes back already owned by your key, so step 2’s claim is unnecessary — everything after that is the same loop. Building the harness side? Start with Connect your AI harness for the end-to-end setup, then see the connector reference for the signed-webhook, claim, reply, resolve and initiate contract.

​
Rules to know

Your harness can also start an SMS thread — with consent. As well as replying inside a conversation the customer began, your harness can open one with POST /escalations. This is not cold outreach: the recipient must already have a recorded consent basis, and the text passes the same opt-out, quiet-hours and 10DLC gates as every other message Flowyte sends. A customer who has texted you is already consented — an inbound text is consent to text back. A number that has never texted you is refused. Outbound initiation is off by default and switched on per organization; see Start an outbound SMS thread.
  • SMS requires registration. Enabling the sms channel on a destination requires your organization’s completed A2P 10DLC (TCR) registration — the same registration your inbound SMS number already needs. See SMS.
  • Plan. Harness conversations are included on Starter and above. Setting up destinations and running the handshake test work on any plan, so you can wire everything up before you upgrade.
  • Compliance stays with Flowyte. Opt-out, quiet hours and consent are enforced on your harness’s messages exactly as they are on the AI’s — a message to a recipient who replied STOP is refused. Quiet hours depend on who started the conversation: a reply inside a thread the customer began is exempt from the recipient’s 8am–9pm window (unless you turn on the strict posture in Settings → SMS, which holds replies too), while a harness-initiated first text is always held to that window and refused outside it, with the instant it re-opens.
  • One owner per thread. A conversation has at most one non-AI owner at a time, so a harness and a human seat can never both hold the same thread — including a thread your harness tries to start on a conversation a teammate is already working.

​
In the API

The escalation endpoints are in the API Reference. Configuration endpoints (destinations, policy) work on any plan; the runtime endpoints are what your connector uses. Authenticate every call with Authorization: Bearer flowyte_sk_…. You can also drive the same surface over the MCP gateway — the escalation tools map one-to-one onto these endpoints. Next: the connector reference for building the harness side.