AI Platform

Roadmap The AI Platform is the conversational runtime the channel runs on: the assistant that reads a message, decides what to do and answers. It is the direction the conversational side of the product is heading in, and none of what is described here is available today. What a Partner can use now is in Webhooks and channels.

What it is

A Partner integrating over the API does not need any of this: a backend calls, an operation runs, a signed webhook comes back. The AI Platform exists for the other shape of the product — the one where a person asks for something in their own words, in a conversation, and the platform has to understand it, ask for what is missing, get an explicit confirmation and only then move money.

That runtime is being rebuilt. The one in use was written around a single model with most of the work happening synchronously, which is enough to prove a flow and not enough to run a Partner's support and payments on.

The properties it is built for

A model is a dependency, not a foundation. Which model answers is configuration per task, with a spending ceiling of its own, so a provider that fails, changes its terms or prices itself out is replaced without touching the assistant.

A conversation is durable. A message being processed when the service dies is picked up again; one already answered is not answered twice; turns of the same conversation are handled in the order they arrived. What could not be delivered after every retry is set aside for review rather than disappearing.

What the assistant may do is declared. Capabilities are a list with arguments, permissions and limits, checked before the call runs. A model cannot reach an operation it was not granted, and every invocation is recorded with what it asked for and what came back.

A person can step in. An operator takes a live conversation over, answers as themselves and hands it back. Whatever was pending resumes exactly once.

Money still goes through the same door

An operation started from a conversation is created through the same public API any other caller uses, under the same idempotency key, the same tenant limits and the same reconciliation. The channel never signs, and never writes to the ledger.

Message
→ Assistant
→ Capability gateway
→ B2B API
→ Operation
→ Signer, adapter, ledger
→ Signed webhook and reply in the same thread

This is what makes the conversational surface safe to add: it is one more caller of a contract that already exists, so asking twice moves the money once, and what happened is visible in the ledger and in the webhooks rather than only in the chat.

Configured, not coded

What belongs to a Partner — prompts, capabilities, flows, knowledge base — lives in that Partner's own configuration, and the runtime operates on the declared shapes. A second Partner is a configuration rather than a fork of the code. ChatterPay's own API is one of the several an assistant can be given, not the one it is written around.

Capabilities in this area

This area covers the capabilities below. The Roadmap states the current availability of each one.

• A model gateway with a policy and a budget per task — Which model answers is configuration of the deployment rather than a constant in the code, chosen per task and with a spending ceiling of its own. A provider that fails or prices itself out is replaced without touching the assistant, and what a conversation cost is a figure the Partner can read.

• Memory in layers, under a token budget — A long conversation keeps what matters instead of the last few messages: recent turns in full, older ones compacted, and durable facts about the person kept apart. The budget bounds what each turn costs, so a conversation that goes on does not get progressively more expensive or start forgetting silently.

• Governed capabilities instead of an open catalogue — What the assistant may do is a declared list with its arguments, its permissions and its limits, checked before the call runs. A model cannot reach an operation that was not granted to it, and every invocation is recorded with what it asked for and what it got back.

• A human operator can take the conversation over — Someone from the Partner steps into a live conversation, answers as themselves and hands it back, with the assistant held while they hold it. What was pending when they took over resumes exactly once when they release it, rather than being dropped or run twice.

• The whole WhatsApp channel — Images, documents and voice notes transcribed to text, the interactive forms the provider offers, the service window that governs when a conversation may be started, and the approved templates for starting one outside it. The parts of the channel a real support conversation runs on.

• Campaigns with a budget, a stop and an opt-out — Reaching many people at once, bounded by a declared budget and by the provider's own limits, with a switch that stops a running campaign at once. Whoever asks to stop receiving them stops receiving them, and that decision outlives the campaign that prompted it.

• Answers drawn from the Partner's own knowledge — The Partner loads its own articles and the assistant answers from them, citing which one it used. A fixed set of questions with their expected answers is run against every change, so a new model or a new prompt cannot quietly make the answers worse.

• A conversation that survives a crash — A message being processed when the service dies is picked up again rather than lost, and one that was already answered is not answered twice. Turns of the same conversation are handled in the order they arrived, and what could not be delivered after every retry is set aside for review instead of disappearing.

• A transfer asked for in the conversation — The assistant creates the operation through the same public API any other caller uses, under the same idempotency key, the same limits and the same reconciliation. Asking twice moves the money once, and what happened is visible in the ledger and in the webhooks, not only in the chat.

• Configured rather than coded — What belongs to a Partner — its prompts, its capabilities, its flows, its knowledge — lives in its own configuration, and the runtime operates on the declared shapes. A second Partner is a configuration rather than a fork, and ChatterPay's own API is one of the several an assistant may be given.