HostContext and the card protocol.

HostContext — the payload in

HostContext is the references-only description of where the user is right now. It carries entity references, the current view, and identity references — never raw record content. This is what lets the model reason about the user's situation while the actual data stays behind governed tools.

• References and ids, not record bodies.
• The current view or screen the user is on.
• Enough for the agent to resolve context through getContext, no more.

The card protocol — the payload out

Everything an agent renders is a card. The card protocol defines twelve typed cards spanning interaction (plan, approval, progress, result, comparison, detail, context-request, save-output) and presentation (markdown, code, mermaid, table). Because the protocol is fixed and typed, there is no front-end coding to render an agent's output — the panel already knows every card type.

Contracts are additive

Contracts evolve additively so that a host built against an earlier version keeps working. New optional fields and new capabilities are added without breaking existing adapters or embeds — the two seams stay stable as the platform grows.

Zod ↔ JSON-Schema parity

Contracts are defined once and validated everywhere. The TypeScript Zod schemas and the JSON-Schema used across the language boundary are kept in parity, so a payload that validates on one side validates on the other — the same shape enforced whether it is checked in Node or in the Python runtime.

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.