Runtime neutrality
Neutral Runtime Contract
OSuite treats runtime governance as one neutral contract: classify the runtime family, declare the adapter mode, preserve the authority split, then attach the right protocol lane and proof path.
Why
Agent ecosystems will keep changing. The governance contract has to stay broader than any single runtime.
OSuite uses a neutral runtime contract so OpenAI-compatible gateways, managed agent platforms, framework SDK runtimes, and observer-only systems can all feed the same PCAA route, review, and prove cycle. The contract is not another transport protocol. It is the shared governance expression that survives runtime churn.
Runtime families
Runtimes that expose chat, response, or tool-call semantics through an OpenAI-shaped API boundary. Hermes-style API servers, hosted gateways, and proxy runtimes that can be governed at the request boundary.
Hosted agent systems that own sessions, tool execution, and state progression inside a managed control surface. Azure AI Foundry Agent Service, managed enterprise agent platforms, and opaque hosted execution harnesses.
Code-first runtimes where governance can attach directly to tools, graph nodes, handoffs, and outcomes. OpenClaw, LangGraph, OpenAI Agents SDK, CrewAI, and self-hosted orchestration frameworks.
Developer-facing runtimes that expose command, tool, or shell hooks before side effects occur. Coding agents, local automation runtimes, CLI copilots, and command-gated agent workflows.
Systems where OSuite can import evidence or outcomes even when it cannot preempt execution inline. Legacy agent deployments, post-hoc audit feeds, and systems that can only provide receipts after execution.
Adapter modes
OSuite is embedded directly inside the runtime and can participate in guard, action open, approval, and outcome closure.
OSuite governs requests or tool calls at an API gateway or protocol boundary before the runtime continues.
A managed platform or external runtime forwards structured decisions and receipts through a translation layer.
OSuite receives receipts, outcomes, or evidence after execution and cannot guarantee inline interception.
Trust materials
Neutral runtime governance also needs a neutral way to carry trust evidence. OSuite now normalizes wallet receipts, DID or VC-style identity claims, delegation chains, registry proofs, and signed request receipts into one trust material envelope. That lets different ecosystems contribute evidence without taking over the certificate model.
Wallet-backed attestations, identity credentials, and registry proofs can travel across workspace boundaries without becoming runtime-specific one-offs.
Signed request receipts and protocol trust materials stay distinct from transport while still entering the same certificate and replay flow.
Trust materials can come from native OSuite controls, external governors, or future Web3 substrates without rewriting the neutral contract.
Protocol lanes
Protocol lanes tell OSuite how governed work moved, without making transport the primary trust object. That lets the control plane stay neutral while still respecting A2A-style exchange, signed requests, native SDK loops, and external runtime governors.
Direct OSuite SDK/API instrumentation with the richest action, approval, replay, and proof semantics.
Families: framework_sdk, tool_hook_runtime
Modes: inline_sdk
Workspace-native agent collaboration where messages and threads stay attached to approvals, replay, and evidence.
Families: framework_sdk, tool_hook_runtime, managed_agent_platform
Modes: inline_sdk, bridge
Vendor-neutral cross-agent task exchange, with PCAA continuing to own admissibility and replay.
Families: managed_agent_platform, openai_compatible, framework_sdk
Modes: gateway, bridge
Request freshness, signature, and identity proofs for commerce or signed external requests.
Families: openai_compatible, managed_agent_platform, observer_import
Modes: gateway, observer
External runtime governance tunnel for higher-assurance execution before OSuite emits the final certificate.
Families: managed_agent_platform, openai_compatible, framework_sdk
Modes: bridge, gateway