The pipeline

Six stages, whatever the channel

A pipeline is a declarative graph of steps, and it does not care whether the message came from a mailbox or a chat widget. Every step records what went in and what came out, so a reply is never a black box you have to take on trust.

1 · Ingestion

Email, web chat, text, web forms, mobile apps and API all feed one admission pipeline. Messages are normalized to a channel-neutral shape, de-duplicated, threaded, and anything suspicious is quarantined before it reaches a model.

2 · Classification

Each message is triaged and given an intent — an FAQ, a quote request, an order status query. The intent selects which pipeline runs. Anything the classifier is unsure of goes to a person.

3 · Retrieval

Hybrid retrieval over your indexed corpora: product catalogue, FAQ library, response templates, order records and prior correspondence. Scoped to your tenant, always.

4 · Generation

A reply is drafted from the retrieved facts, using your response templates and your tone rules, then validated before it is allowed to become a draft.

5 · Approval

Your policy decides: send it, or hold it for a person. A held reply enters a queue with a full lifecycle — assignment, review, edit, approve or reject, with SLA and expiry. Set the line per intent, not once for everything.

6 · Delivery

Replies go back down the channel they arrived on, are written back to the originating system where one exists, and their delivery outcome is tracked rather than assumed.

Channels

Seven ways in, one canonical message

Every intake path converges on a single admission gate, and produces a record with a channel-neutral core. Classification, retrieval, generation and approval read that core — a step that reaches for the channel envelope has taken a channel dependency and has to declare it.

Language

The language of a message is detected at admission, carried on the canonical record, and used to select tone rules and to generate the reply. Grounding data is not duplicated per language — the catalogue is read once and the answer is written in the language the customer used.

Detected at admission

Per message, not per correspondent. Nobody maintains a language preference list.

Tone rules per market

Formality, greeting and sign-off vary by language and region from one set of facts.

Unapproved languages escalate

A language a tenant has not enabled routes to a person rather than being attempted.

Adding a channel does not fork the logic. A new intake path is an adapter in front of the same gate and the same pipelines. Your tone rules, your grounding and your approval policy apply to it the day it is switched on.

Tools

What the agent is allowed to reach for

A pipeline step may invoke a tool. Tools are the only way an agent touches your systems, which is what makes the boundary enforceable rather than hoped for.

Product lookup

Specifications, availability and variants from your catalogue.

Order lookup

Status, history and fulfilment detail for a named order.

Pricing

Price at quantity, under the terms that apply to that account.

Template fetch

The approved wording you already use for this kind of reply.

Configuration, not code

New intents and new businesses are settings

The pipeline engine is generic. Onboarding a business, or teaching the platform a new kind of message, does not mean writing a new service.

Versioned
Every configuration change is a version. You can see what was in force at any past moment, which is what makes a historic draft explainable.
Validated and staged
Changes are validated, then published deliberately rather than taking effect the instant they are typed.
Reversible
Roll back to the previous version. A bad prompt or a wrong template is a rollback, not an incident.
Inherited
Workspaces — a brand, a region, a single mailbox — inherit tenant configuration and override only what differs.

The console

Two jobs, one interface

For reviewers

Every channel in one queue, built for someone working it for hours rather than glancing at it once a week. AI-generated content is visually distinct from content a person wrote, and untrusted customer content is rendered so it cannot act on the page.

For administrators

Channels, pipelines, templates, catalogues, approval policies, autonomy thresholds and users. Navigation is derived from your permissions, so you are not shown doors you cannot open.

Autonomy

Three levels, set per intent

Autonomy is per-tenant, per-intent configuration — so order status can answer itself while a pricing dispute always waits for a person.

One rule holds at every level. An ungrounded answer escalates and a failed validation cannot send — by a reviewer or by a policy. Autonomy changes who says yes, never what is allowed through.

Also included

The parts that make it a platform

Identity & access

Tenants, workspaces, memberships and roles, with per-tenant OpenID Connect federation so your people sign in with the identity provider you already run.

Counterparties

A record of who you correspond with — accounts, prospects, the people acting for them, and their contact points.

Metering & budgets

Usage captured per tenant and aggregated into billing periods, with quota and budget enforcement so cost cannot run away unobserved.

Integrates, does not replace. Broa exchanges data with the CRM, ERP, e-commerce, helpdesk and ticketing systems you already run. Replacing them is explicitly not a goal.

Point it at a real message

The useful demo is one of your own emails, and an honest look at what it refuses to answer.