Products Conversational AI integration and orchestration

chat-api

The layer between a conversation and everything the business knows. chat-api takes a live conversation, gathers context from the systems of record, decides what can be answered or acted on, and hands to a human when that is the right call — with the whole path recorded.

In active development. Demonstrated against Dialpad environments.

See the demo

How it works

From a conversation to a governed action, and back.

The interesting part of a conversational product is not the language. It is everything that has to happen between understanding a question and being allowed to do something about it.

A customer contacts the business through a conversation platform such as Dialpad. chat-api identifies the caller and assembles context. ddash™ orchestration decides what can be answered or acted on, drawing from CRM, ERP, APIs, knowledge sources and models. A workflow or action runs within its permitted scope. A human agent is brought in with full context when appropriate. The conversation, retrievals, approvals and outcome are written to a governance trail.

Dialpad is a current integration focus and the environment we demonstrate against. Naming it here describes our engineering work; it does not imply a partnership, certification or endorsement by Dialpad.

Demo

One call, end to end.

A customer asks about an order, the assistant answers from live systems, the request exceeds what it may do on its own, and a named person approves it. The right-hand pane shows what happened underneath.

chat-api — sandbox session Demo · Simulated data

Conversation

  1. Caller

    Hi — I’m calling about order 4471. It was supposed to ship Tuesday and I haven’t heard anything.

  2. chat-api

    Thanks — I can see order 4471 for Cranebrook Glazing. It’s a tempered unit order, currently in fabrication, scheduled to ship Thursday rather than Tuesday. The delay is on the tempering line.

  3. Caller

    Thursday is too late. Can you split it so the three panels that are ready go out today?

  4. chat-api

    Splitting a confirmed order changes what gets invoiced, so that needs an approval from your account manager. I’ve sent it to Dana Whitfield with the details and flagged it urgent. Would you like me to stay on while she looks?

  5. Dana Whitfield · Account manager

    Approved — ship the three finished panels today, balance Thursday. Caller has been told.

What chat-api did

  1. Conversation received Voice channel · session opened
  2. Caller identified Matched to CRM account · Cranebrook Glazing
  3. Context assembled ERP order 4471 · line status · shipping schedule
  4. Policy checked Read: permitted · Split order: requires approval
  5. Answer grounded Response built from retrieved records, not a guess
  6. Escalated to human Routed to account manager with full context
  7. Action executed Order split written back to ERP after approval
  8. Record written Transcript, retrievals, policy result, approver, outcome
A fictional order enquiry showing context assembly, a policy stop, human approval and the resulting record. Every name, company, order number and system response on this screen is invented for demonstration. No customer data, tenant identifier, credential or production system is represented. The interactive sandbox is not connected yet — this is the shell it will run in.

Planning a live walkthrough in your own environment? We run those against a sandbox tenant with fabricated records — never against your production data or ours.

What it does

Eight things that have to be true at once.

Conversational AI integration

Connects a live conversation channel to the systems that actually hold the answers, instead of to a static knowledge base that went stale last quarter.

Multi-system context

A single question often needs the CRM account, the ERP order and the shipping schedule at once. chat-api assembles that view per conversation rather than per integration.

Agent and workflow orchestration

Routing, sequencing and state handled through ddash™, so a conversation can trigger real multi-step work rather than just producing text.

Business-data lookup

Answers are grounded in retrieved records. Where a value came from is part of the record, so an answer can be checked afterwards.

Human escalation

Thresholds you set decide what stops for a person. The human receives the full context, not a transcript they have to re-read.

Retained context and history

The conversation, what was retrieved, what was decided and who approved it are kept together, so the next conversation starts informed.

Governed actions

Every write is enumerated in advance and scoped. The same governance model as every other RPR deployment — nothing special-cased for conversation.

Reusable deployment architecture

The same shape redeploys against a different channel, a different CRM or a different industry. The channel is configuration, not a rebuild.

What changes operationally.

Stated qualitatively on purpose. We have not published timing or volume figures for chat-api because we have not measured them across enough deployments to stand behind a number.

The assistant can answer from documentation but cannot see a live order.
Answers are grounded in the current state of the systems of record.
Escalation means the customer repeats everything to a person.
The human opens the conversation already holding the full context.
What an automated assistant told a customer is not recoverable later.
The conversation, retrievals, approvals and outcome are one record.
Adding a channel means rebuilding the integration work.
The channel is configuration against an architecture that already exists.

Start with the customer journey

See it against a channel you already run.

The useful demo is not a scripted conversation — it is us showing what context assembly looks like against the kind of systems you actually have.