CUSTOMER FACING

Customer support automation

Most support automation fails in one of two ways: it answers from a stale knowledge base, or it takes an action nobody sanctioned. An agent with read access to your real systems and a hard stop before every write avoids both.

Start building See the demo

The problem

Your agents spend the first two minutes of every ticket gathering context from four systems, and the risk of letting AI close that gap is that it replies with something wrong to a customer.

How it is built

Give the agent read access to the systems that hold the answer
Import your helpdesk, billing and order APIs. Publish only the read actions to begin with. The agent can now see the ticket, the invoice and the order in one place.
Let it prepare the reply, not send it
The agent drafts the response with the specific figures it read. The run pauses at the approval checkpoint with that exact text shown.
A human approves, edits or denies
Approval is bound to the proposal that was shown. If the draft is edited, the old approval no longer applies — the change goes back through the gate.
Widen scope once the traces look right
After a few weeks of runs you will know which actions are safe to publish without confirmation. That decision is made from evidence rather than optimism.

What you get

First response drafted from live data instead of a template.
No customer-visible action taken without a recorded human decision.
A trace per run showing what was read, what was proposed and who approved it.

What keeps it safe

Every write action is confirmation-gated by default.
Each run is bound to one host tenant, isolated at the database level.
Credentials are resolved from your vault inside the execution layer, never in the prompt.

Start read-only

Publish the read actions, run it for a few weeks, and read the traces. Deciding which writes to publish from evidence is both safer and a much easier internal conversation than deciding from a roadmap.

Questions

Will this replace our support agents?

It removes the context-gathering, not the judgement. The design deliberately keeps a person on every customer-visible action, which is a staffing model, not a replacement one.

What if the model gets the figures wrong?

The figures come from your API responses, not the model’s memory, and the approval screen shows the proposal before it goes anywhere. That is the check.

Build beyond the expected.

Create a workspace, register an application, and import your first API.

Create your workspace Read the docs

How it is built

Give the agent read access to the systems that hold the answer

Import your helpdesk, billing and order APIs. Publish only the read actions to begin with. The agent can now see the ticket, the invoice and the order in one place.

Let it prepare the reply, not send it

The agent drafts the response with the specific figures it read. The run pauses at the approval checkpoint with that exact text shown.

A human approves, edits or denies

Approval is bound to the proposal that was shown. If the draft is edited, the old approval no longer applies — the change goes back through the gate.

Widen scope once the traces look right

After a few weeks of runs you will know which actions are safe to publish without confirmation. That decision is made from evidence rather than optimism.