Embedded Agents

What it is

Most companies that put AI on a customer-facing surface today bolt on a generic chatbot — a third-party widget with a fixed persona, a knowledge base that drifts from the rest of the company, and a way of breaking quietly when the vendor releases a model update. Embedded Agents replaces that with an AI agent that lives inside your website, mobile app, in-product UI, or voice line, with the persona, the knowledge sources, and the tool surface you approve. It reads from the same data substrate as the rest of your AI stack. It calls the same governed tools. It writes its conversations to the same governed table. And when it cannot fully resolve a question, it routes the outcome through a path you defined — create a ticket, email a team, post to Slack, hand off to a human — and confirms back to the customer that something is happening.

Why it matters

The chatbot is the AI surface most customers actually see, and the one most often built on rented infrastructure nobody on the team controls. The cost shows up three ways. The persona drifts: every model update by the vendor is a chance for the tone to change without anyone noticing. The knowledge stays generic: the vendor's 'AI' does not see your product docs, your order history, your support patterns, your live inventory. And the failure mode is awkward: when the bot cannot answer, it shrugs, and the conversation ends — no ticket, no email, no follow-up, no record that the customer ever asked. Embedded Agents removes all three. Persona is a tested invariant. Knowledge comes from your governed substrate. Every conversation has an explicit outcome.

What we build

A customizable widget — chat, voice, or multi-channel — that embeds into your website, app, or voice line through a one-line script tag, an npm package (React, Vue, Svelte), a Web Component, or a sandboxed iframe. A persona console where you define tone, refusal patterns, scope, and language variants. A knowledge ingestion pipeline that connects uploaded documents, Notion, Drive, Confluence, your public website, and any source the Data Foundations service governs. Live MCP tool connections to your business systems (Shopify, Stripe, Zendesk, Salesforce, internal APIs, ticketing tools). A capability inference pipeline that reads everything you connected and proposes the subjects the agent could speak about and the actions it could take — for you to approve, reject, or edit before anything goes live. Outcome routing rules that decide what happens at the end of every conversation: ticket creation with full context, internal email, Slack or Teams notification, live human handoff with the conversation already loaded for the agent picking it up. Identity propagation so the agent knows who the visitor is when they are logged in, with scoped capabilities for authenticated versus anonymous visitors. The whole thing runs through GroupemediaAI's gateway, so the model under each step is a routing decision — never a rewrite.

• Embeddable widget — chat, voice, mobile SDK, Web Component
• Persona charter with behavioral test suite, stable across model swaps
• Knowledge ingestion (docs, live sources, web crawl) into governed tables
• Live MCP tool connections with approval-gated activation
• Capability inference — the system proposes, you approve
• Outcome routing: tickets, email, Slack, live human handoff
• Identity propagation with two-tier (authenticated / anonymous) scope
• LLM-agnostic via the GroupemediaAI gateway
• Multi-language with per-language tone variants
• PII redaction at capture, configurable retention (Law 25, GDPR, HIPAA)
• Per-session cost telemetry and budgets
• Admin console, kill switch, and full trace replay

How it actually works

Step one, you connect knowledge sources and tool servers. Step two, an inference pass reads everything and proposes a list of subjects the agent could discuss and tool functions it could call — each clustered, named, and described. Step three, you review the proposal in the admin console: accept, reject, or edit each item; set confidence thresholds; declare refusal language for the things the agent should never do. Step four, approved capabilities go live behind a versioned persona charter, which is itself tested with behavioral probes on every prompt or model change. Step five, the agent operates: every conversation traced, every outcome routed, every unresolved question becoming a ticket-with-context or an email-with-context that closes the loop by emailing the customer a confirmation. Step six, the conversation table feeds Conversation Intelligence, which clusters failures and proposes knowledge updates that go back into the agent's substrate. Step seven, when sources change materially the inference pipeline re-proposes additions for your approval. The result is an agent that gets quietly better, with a clear human in the loop deciding what better means.

What it works with

Sits on top of the AI Platform — every model call routes through the gateway with per-step routing, fallback chains, and cost attribution per session, per tenant, per workflow. Reads from Data Foundations — the knowledge base lives in governed tables with permissions that propagate through retrieval; the agent cannot return content the requesting user is not allowed to see. Calls tools through the MCP Tool Registry — same scopes, same audit trails, same governance as any other agent in the system. Writes conversations to the same governed table that Conversation Intelligence reads from, so the embedded agent's failures cluster alongside every other channel's. Inherits the Synthetic Personality discipline — the persona charter is a versioned, tested artifact, not a prompt that drifts. Routes outcomes through Human Approval when handoff or high-impact action is required. Closes the improvement loop through Closed-Loop Knowledge.

What this is not

Not another rented chatbot widget — the infrastructure belongs to you; the model provider is a routing decision. Not an unsupervised autonomous agent — every capability is approved before activation, every high-risk action is gated, every conversation is traced. Not a generic FAQ bot — the agent is grounded in your live data, your live tools, and your brand voice. Not vendor lock-in — the widget is yours, the LLM is swappable, the knowledge sources are governed in your data foundations. Not a black box — every conversation has a full trace of retrieved evidence, tool calls, decisions, and the outcome route taken. Not a replacement for human support — it is the layer that resolves what should be self-serve and routes everything else to the right human with the context already loaded.

When you should start

Signals: an existing chatbot vendor whose tone has drifted off-brand since the last model update; a customer-facing AI surface on the roadmap and a desire not to ship a generic widget; multi-channel support sprawling across web, app, WhatsApp, voice, with each channel a separate integration; an internal team paged daily for questions a properly-scoped agent could answer; rich product documentation, structured order data, and a ticketing system that no AI surface currently uses together. Common starting points: a single high-traffic page (pricing, returns, support landing) embedded with a narrowly-scoped agent that does FAQ plus ticket creation; a logged-in product surface where the agent gains identity-scoped capabilities like order lookup and account changes; or a voice line where the same persona handles inbound calls with the same approval-gated capabilities as the web widget.