Platform architecture

How Office 168/52 delivers a governed AI front office in the browser—and what is intentionally public vs. in-app.

← Integration guide Proof center Security FAQ

Three surfaces

Customer Portal — Where business operators run the front office: departments, widget setup, knowledge, conversations, billing, and action inbox.
Mission Control — Where platform operators publish, monitor, configure tenants, voice, integrations, and governance.
Public integration — Widget embed, chat data plane, and outbound webhooks documented on the integration guide.

Request flow (simplified)

Visitor on customer website │ ▼ widget.js (tenant bundle) │ ▼ POST /api/widget/chat ──► Unified chat pipeline ──► Approved knowledge + tools │ │ │ ├──► Safe refusal / escalation │ └──► Outbound webhook (optional) │ Customer operator (browser) │ ▼ Customer Portal ──► Session APIs (/api/customer-portal/*) │ (not public integration docs) ▼ Front office OS, knowledge, widget setup Platform operator (browser) │ ▼ Mission Control ──► Publish, audit, telephony, marketplace

Canonical API domain

Widget and cross-origin chat calls are served from office16852.com even when your marketing site uses another brand domain (Ask Bob, FrontOffice247). Brand sites are presentation; the control plane stays canonical for consistent CORS, keys, and governance.

What we do not publish as a public API

Routes that power Customer Portal and Mission Control UIs—front office summaries, macro departments, knowledge CRUD, publish room—require authenticated sessions and tenant RBAC. They are product internals, not a developer platform contract. Integrate via widget, webhooks, and the paths on the integration guide.

Proof & governance

Capability status, certification gates, and regression proof are maintained internally and summarized for buyers on the proof center and security pages. Bob answers from approved sources; refusals and audit trails are first-class product behavior—not optional add-ons.