Architecture at a glance

⤢ Expand

One message, end to end

1. A contact writes. The channel gateway receives the message from WhatsApp, the web chat or your own app.
2. The conversation is found. The conversation layer finds the contact’s conversation, or starts one and asks your adapter who the contact is and what it should know about them.
3. An agent takes the turn. The agent runtime reads your Domain Pack at the version the Partner is pinned to, picks the agent for this turn, and builds its prompt.
4. Tools run in your systems. When the agent calls a tool, the tool gateway sends the call to your adapter, which answers with the tool envelope.
5. The reply is checked, then sent. The runtime checks the drafted reply against your rules before the channel gateway delivers it.

What you own, what the platform owns

You	The platform
Your Domain Pack: agents, intents, rules, tools, golden cases	Storing it as versioned data, and running the version each Partner is pinned to
Your Domain Adapter and the business systems behind it	Calling your adapter with your adapter secret, and handling a failed call
Your channel accounts, such as a WhatsApp number	Receiving and delivering messages, and handing a conversation to a person
Deciding when a version is good enough to release	Running golden cases and showing each version’s pass rate

Two credentials, one per direction

Direction	Credential	Used for
Your systems → platform	Your DomainKey, as x-api-key	The Domain API: runs and keys
Platform → your adapter	Your adapter secret, as x-api-key	Every call to your seven adapter endpoints

Single-turn runs take a shorter path

A single-turn run has no channel and no conversation. Your system calls the Domain API with a job and a query. The platform runs the agent that fills the job and answers with an answer and, when the agent declares one, structured data. A run in the background posts its result to your adapter instead. See Single-turn runs and the Runs API.