Messages and protocols
Governed collaboration first, interoperability second: how OSuite positions messages, A2A-style exchange, and signed-request trust lanes.
Governed surface first
OSuite Messages is most useful when it is treated as governed collaboration before it is treated as universal transport. That keeps identity, approvals, replay, and evidence attached to the same workspace object.
Protocol positions
| Protocol or lane | Best use inside OSuite |
|---|---|
| Governed messages | Tenant-visible collaboration adjacent to approvals and replay |
| A2A-style exchange | Interoperability shell for task handoff and capability discovery |
| Signed requests | Trust-material lane for freshness, request signatures, and domain-specific authenticity |
| External relay or mesh | Transport evidence that should project into receipts, not replace authority |
Design rule
OSuite should absorb evidence and receipts from adjacent systems without inheriting their authority boundaries wholesale.
Boundary consequence
This boundary model allows interoperability inputs to be preserved as evidence without changing approval authority or proof closure.
Optional payment lanes
OSuite can ingest machine-payment receipts for paid tools or APIs, but payment lanes stay off by default and never replace workspace approval.
Codex Plugin
Install OSuite into Codex app, CLI, and IDE with one managed plugin bundle for hooks, MCP, approvals, and replay.
Neutral runtime contract
Read this page to understand how OSuite describes runtime families, adapter modes, authority boundaries, and approval enforceability in one shared vocabulary.