Abstract

More and more, AI is checked by other AI. A “judge” model reviews an agent’s plan, a safety filter blocks a risky answer, a permission rule allows or stops a tool call, a policy engine scores a decision, a human signs off, or another service confirms a job was done. Leading AI developers such as Anthropic and OpenAI already build many of these checkers into their agent products. But most systems never ask some basic questions. Who made this checker a checker? What is it allowed to look at and decide? How long does that power last? And what does its “yes” actually allow?

This disclosure answers those questions with one central rule: a checker’s approval is never, by itself, permission to act. Even a signed, trusted or majority-backed “yes” cannot on its own move money, release data, change live systems, use passwords or keys, or move machines. Each real-world action still needs its own permission and a final, exact check at the moment it happens.

Around that rule, the disclosure describes how checkers should be handled from start to finish. A checker can be a rule engine, an AI model, a simulation, a person, a panel or a mix. It can run anywhere, from the same device to the cloud to a secure chip, and it can be created for one task, run as a long-lived service, or combine both. It only becomes a checker when a real authority appoints it. It cannot appoint itself, declare itself neutral, or be picked by the agent it is judging. Its powers are limited to defined evidence and defined answers: approve for consideration, deny, hold, ask for more evidence, dispute, or say “unknown.” It may never treat silence or a timeout as proof that nothing happened, or count two accounts from the same group as two independent reviewers. Its decisions can go out of date before its appointment ends, and shutting it down or losing connection never extends its authority.

Twenty-seven embodiments apply these ideas to agents negotiating together, “what-if” testing in a safe sandbox, risk scoring, choosing which agent acts next, single-use permission passes, swapping in a neutral replacement agent, holding unfinished work safely, handling network splits and unknown results, closing sessions cleanly, and agents from different companies working together with no single owner in charge. Many include maths, pseudocode, flowcharts and runnable Python examples, which are illustrative rather than proof of production security.

Industry relevance: This work is relevant wherever one system approves what an AI agent does, and it is especially relevant to Anthropic and OpenAI.

  • Anthropic has publicly described permission rules, hooks and subagents in Claude Code and the Claude Agent SDK, Constitutional Classifiers that judge inputs and outputs, automated auditing agents in which one model assesses another, its Responsible Scaling Policy, and the Model Context Protocol (MCP), now used across the industry.
  • OpenAI has publicly described guardrails and handoffs in its Agents SDK, model-based graders, approval and sandbox modes for Codex, confirmation steps in ChatGPT agent before consequential actions, its Model Spec chain of command, its Preparedness Framework, and agentic checkout through Instant Checkout and the Agentic Commerce Protocol.

In each case the disclosure addresses who appointed the checker, what it may see and decide, when its approval expires, and why that approval should not by itself trigger an action.

The work also applies more broadly:

  • Google’s Agent Gateway and Model Armor, Microsoft’s Agent 365 and Azure AI Content Safety, AWS’s Bedrock Guardrails, Meta’s Llama Guard and NVIDIA’s NeMo Guardrails;
  • cross-company agent protocols such as A2A and MCP;
  • enterprise platforms such as Salesforce and ServiceNow;
  • agent payments with Visa, Mastercard and Stripe;
  • oversight duties under the EU AI Act.

This industry-relevance statement is AI-generated and does not claim that any named company uses, implements or infringes the disclosed methods. Readers are strongly advised to read the original filings and each company’s own current public documentation before drawing any conclusion.

This disclosure corresponds to Indian Patent Application No. 202631131650 and builds on the Mothership application PCT/IB2026/055615, filed 4 June 2026 and publicly disclosed 16 July 2026, which claims priority from PCT/IB2026/053385, filed April 2026 and publicly disclosed 4 June 2026. The author is open to strategic collaboration, licensing or acquihire discussions.

Creative Commons License

Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial 4.0 License

Download

Share

COinS