Backend integration

Choose your integration

Embed the widget in your frontend, connect your backend to agents, or both — a decision guide with one diagram.

There are two doors into an Agentic Workforce ME agent workforce. Embed puts a governed agent in front of people on your site or in your app — a channel. Backend connects your systems to agents: your events start runs (automation), agents act on your data through tools you host (a connector), agents read what you publish (a knowledge source), humans approve the risky steps, and you are notified when work finishes. Those are the four integration types; the demo portals use all of them.

Three ways to integrate

Embed / inline

People on your site or app should chat with one agent. No changes to your backend.

Browser holds: Publishable key, 15-minute session token, visitor id.
Your server holds: Optionally an identity secret to sign end-user JWTs.
The platform talks to: Nothing of yours — the widget talks to /v1/embed/*.

Widget quickstart

Backend

Your systems should start agents on events and agents should act on your systems, with humans approving the risky steps.

Browser holds: Nothing from the platform.
Your server holds: API key, trigger secret, webhook secret, MCP bearer token.
The platform talks to: Your MCP server (tool calls) and your webhook receiver (events).

Backend overview

Both (the demo portals)

A customer-facing chat plus an automated back office — one agent workforce, two doors.

Browser holds: The widget’s publishable key and session token only.
Your server holds: Everything in the backend mode; the widget’s identity secret if users are signed in.
The platform talks to: Your MCP server and webhook receiver; the widget reaches /v1/embed/*.

See the demo portals

Decide in four questions

Question	If yes…	If no…
Should people type to the agent themselves?	Embed the widget (or build a UI on /v1/embed/*).	Backend only: runs start from your systems, not from a chat.
Should something in your system (an invoice, a ticket, an order) start agent work?	Fire a signed trigger from your backend, or start a run directly with the API.	The widget alone is enough.
Should the agent read or change data that lives in your systems?	Expose those operations as tools on an MCP server you host (a connector); grant them to the agent.	A knowledge source (uploads, SharePoint, Confluence, Google Drive, S3, web) indexed into a knowledge base may already cover read-only questions.
Does anything the agent can do need a human sign-off?	Put an approval policy on that tool and decide requests from the console or your own UI.	Keep tools read-only and let runs complete unattended.

What the backend door gives you

Events in, runs out (automation: triggers). A business event becomes a governed run of a published agent or workflow with one signed HTTP request. Output, cost and every tool call are recorded on the run.
Agents that act (connectors and tools). Tools you expose over MCP let the agent look up a customer, file a case or issue a refund in your system — with your validation, your idempotency and your audit trail. No tool is callable until a grant allows it.
Humans where it matters. Approval policies pause a run before a privileged tool runs; decisions come from the console or from your UI through the approvals API.
Closure (automation: outbound webhooks). Signed webhooks tell your backend when a run completed, failed or is waiting on a person, so your records stay in sync without polling.

Continue with the overview and reference architecture, which shows the whole loop on one page, or jump to the piece you need from the sidebar.