Integrate a governed agent through two seams.

The two seams are the whole surface

Cambiary is the brain; your application is the body. The brain holds zero application-specific code — it never needs to know what your system is. A host app connects through exactly two generic seams, and neither one requires a change to the platform core.

Everything else — governance, planning, approvals, cards, audit — lives inside the layer. Your job is to expose context, identity, permissions, and actions through these two seams.

• HostContext (frontend) — a references-only "where is the user right now" payload you hand to the web component.
• HostAdapter (backend) — five methods that connect the platform to your auth, your data, and your actions.

1. Embed the <agentic-panel> web component

Drop the web component into any modern web stack — Angular, React, Vue, Razor/MVC, or plain HTML — and set its config property with your API base URL, the user's existing host token, and a HostContext describing the current screen. The token is passed through config, never read from localStorage.

<agentic-panel></agentic-panel>

<script>
  const panel = document.querySelector("agentic-panel");
  panel.config = {
    apiBaseUrl: "https://api.your-platform.example",
    hostToken: currentUser.token,   // your existing auth token
    context: {
      entityType: "order",
      entityId: "10473",             // a reference, not raw record data
      view: "order-detail"
    }
  };
</script>

2. Implement the five adapter methods

The adapter is the authority on identity and permissions — the platform issues no identities of its own. Implement it in-process as a TypeScript class, or out-of-process as HTTP endpoints in any language (C#, PHP, Python, and so on).

• validateToken(token) — who is this user? Your existing auth is the real check.
• getContext(ref) — resolve the referenced entity into governed, minimized context.
• getPermissions(user) — what may this user do? Drives the permission intersection.
• executeTool(tool, args) — run an approved action against your services.
• pushNotification(msg) — deliver an update back into the host.

3. Register the host

Register once so the platform knows how to reach your adapter and which origins may talk to it. One tenant can register multiple host apps.

• tenantId — the owning tenant.
• origin — the allowed browser origin (also gates the Socket.IO connection).
• adapterUrl — where the platform reaches your out-of-process adapter.
• authMethod — jwt, apiKey, or oauth2.

4. Author skills and workflow templates

Skills are declarative data, not code. An admin authors a host-neutral skill — instruction body, allowed tool IDs, required context, approval points, plan steps, and card types — and the runtime discovers and loads the right skill on demand by its description. No code deploy is required to add or change a skill.

Name your actions as tools (tool.<verb>_<noun>.execute), assign each a risk level, and the platform knows what auto-approves, what pauses for a human, and what is blocked outright.

The core loop: ask → plan → approve → act

Once the seams are wired, every request follows the same governed loop. The agent resolves references-only context, proposes a plan card, and the run enters waiting_for_approval. On approval, each tool call passes through the single governance gate — read-only steps may run automatically, controlled writes pause, destructive actions are blocked — and results render as interactive cards with provenance.

Every tool call described above is dispatched through the governance gate — permission, policy, approval, audit, and the platform-level controls are set out on the security and data-handling page. For host-specific worked examples, see the integration paths.