# ARBITR - Where autonomous execution becomes accountable URL: https://magentix.ai/arbitr The execution-assurance control plane for the moment autonomous systems act. Built for organisations whose AI and agentic automations now execute real changes across payments, records, workflows, and cross-system processes, and need to see, in evidentiary form, exactly what happened. Runtime-agnostic. Vendor-neutral. ARBITR makes delegated execution visible, structured, deterministic, tenant-isolated, portable, and evidentiary. Not identity. Not policy. The layer that records, and proves, what actually ran, under whose authority, at the moment it committed. ## ARBITR and system logs are not the same thing System logs are produced by the systems doing the work, for the people who run those systems. They tell engineers what happened inside an application, a database, or a piece of infrastructure. Their job is operational diagnosis, not delegation evidence. ARBITR is produced by the autonomous systems doing things on someone's behalf, for the people who are accountable when those things go wrong. It records which agent acted, under what delegated authority, on whose behalf, against which target system, with what result, and at the moment it committed. The unit of capture is the act of delegated execution, not the operation of the underlying machine. A system log answers: did the application work? ARBITR answers: was this autonomous action authorised, by whom, in what context, and is there a deterministic record I can present to a board, an auditor, or a regulator? Both are useful. They are not substitutes. ## The runtime governance gap The boundary between advisory AI and executing AI is where the assumptions holding current governance in place quietly break. Once a system moves from suggesting an action to performing one - making the payment, modifying the record, triggering the workflow, deploying the change - the decision cadence most governance frameworks rely on no longer exists. "Human in the loop" sounds reassuring because it assumes a human can plausibly review what happened before consequences land. At machine speed, that assumption stops being true. Actions commit faster than any review cycle can reach them. A log is not enough; traceability shows that something happened, but not, on its own, that the action was authorised, by whom, within what scope, under what delegation, with what consequence. That is the gap ARBITR exists to close, built from the same governance-first perspective used in regulated financial services and other high-trust operating environments. ## The primitive: the ARBITR Envelope At the core of ARBITR is a single primitive: the Envelope, Structured Execution schema v1. It is a structured, append-only execution record emitted per step, giving each consequential action a stable, defensible record shape across runtimes, tenants, and environments. Versioned, tenant-scoped, trace-correlated, capability-bound, secret-safe, signature-ready, and authority-context aware. Each envelope captures the initiating actor reference (the human or upstream system that triggered the step), the agent reference (the AI or automated component that performed it), the delegation context (the authority chain under which the step was permitted), the authority scope (the specific bounds on what the step was allowed to do), the target system and action performed, the result status, and optional checkpoint references and artifact pointers. It preserves a stable record shape so evidence can be interpreted consistently, exported cleanly, and later sealed cryptographically without changing the underlying execution history. The envelope is not a policy decision or a compliance certificate. It is a deterministic execution record. ## What ARBITR gives the customer Visibility. A real-time view of what autonomous systems are doing at the moment they act, every consequential step captured in a standardised envelope recording initiator, agent, delegated authority, target system, and outcome. Accountability. Every execution step carries its delegation context, traceable back to why something was permitted, not just that it happened. This closes the gap between "the system had permission" and "the system should have acted in this specific way at this specific moment." Portable evidence. Structured, exportable evidence bundles that are vendor-neutral and signature-ready, designed for three levels of review: an executive summary for boards and decision-makers, a structured control and exception view for procurement and assurance teams, and detailed execution records with checkpoint and artefact references for compliance, audit, and investigation. Not locked into one platform or AI vendor. ARBITR is not just producing logs; it is producing evidence packages executives can understand, procurement teams can assess, and compliance teams can work with, in a standards format. ## Architecture principles ARBITR is SaaS-first and runtime-agnostic. Envelope discipline is absolute because evidence portability depends on a stable record shape across tenants, runtimes, and releases. Storage is append-only. Tenant isolation is enforced at the database layer. No raw secrets are persisted in envelopes. Signature-readiness is built in from v1 so evidence bundles can be cryptographically sealed as the programme matures. This is the discipline that makes the evidence defensible later, not just convenient now. ## Competitive positioning The agent market is splitting into layers rather than converging into one crowded category. ARBITR's lane is the neutral execution-evidence and interpretation layer across agents, runtimes, enterprise systems, and commit surfaces. It records, reconstructs, and packages execution evidence without replacing agents, identity, policy engines, payment rails, or enforcement systems. Across the market's categories: - Local-first and AIOS agent runtimes (OpenClaw; NVIDIA NemoClaw; on-prem private AIOS): ARBITR adds enterprise-grade execution evidence, capturing gateway and session events, channel-originated instructions, skill and tool calls, file and shell activity, cron jobs, approvals, checkpoints, and outcomes via a tightly scoped outbound-only encrypted stream that needs no inbound access to the customer estate. - Agent platforms and managed cloud runtimes (OpenAI Frontier / ChatGPT Workspace Agents; AWS Bedrock Managed Agents; Microsoft Copilot / Agent 365; Salesforce Agentforce 360; Google Gemini Enterprise): complementary. These govern agents inside their own estates; ARBITR evidences Microsoft, non-Microsoft, AWS, Google, Salesforce, and OpenAI execution together so delegated work stays visible across boundaries. - Agentic coding and development tools (Anthropic Claude Code; OpenAI Codex; Cursor; Windsurf): ARBITR captures code, file, shell, PR, and deployment activity and connects it to authority context, approval state, and downstream production impact. - Self-hosted and open-weight agents (Kimi K2.6; Qwen Code): supported through local-first Python, Node, and MCP adapters that emit the same envelopes and outputs as managed runtimes. - The tool-access protocol layer (MCP): a strategic observation surface; ARBITR normalises MCP tool calls across runtimes into execution envelopes. - Identity, trust, and payment-context layers (MATTR; Tunic Pay): complementary; they strengthen credential, delegation, and payment-decision signals before action, while ARBITR records and interprets the execution trail after action. - Authority-enforcement and compliance-enforcement layers (Zortrex; Genesis50): adjacent control layers that constrain or block execution at the commit boundary or the compliance choke point, while ARBITR provides neutral evidence across whichever enforcement system an organisation chooses, without presenting itself as a compliance guarantee. The market is not becoming one agent platform. It is becoming a network of execution surfaces. ARBITR helps organisations evidence, interpret, and defend what autonomous systems actually executed across those surfaces. ## Status and the pilot ARBITR is in active development. The core primitive is stable, the V1 product scope is defined, and ten pilot organisations are being selected. The product is not available for general sale; the pilot programme is the only commercial path today. It is best suited to organisations deploying or planning autonomous systems where execution authority matters across payments, record modification, agent-triggered workflows, or other compliance-sensitive operations. Each pilot partner pays a single fixed entry fee and receives lifetime access thereafter. This is not a discount scheme; it is a partnership. An Expression of Interest leads, where the fit is strong, to a qualification call; shortlisted organisations receive the Prospectus and, under mutual non-disclosure, the Architecture Brief and Envelope schema.