The Intent Packet Protocol (IPP): A Coordination Stack for Agentic AI
A public disclosure and invitation to build an open standard for routable, auditable, economic intent
Preface and disclosure
Iâm publishing this as a defensive, public disclosure of this concept because I do not want any single party to hold patents on these emerging ideas. It is infrastructureâlevel and should remain open and free. The goal is to create clear prior art and attract collaborators to shape a neutral standard (potentially stewarded by a standardsâlike foundation such as OpenTerms.com, which I intend to create).
Preface and disclosure
This document is a deliberate, timeâstamped defensive publication intended to place the core ideas into the public domain as prior art. It invites collaboration as an open standard.
What follows defines the Intent Packet Protocol (IPP) and an accompanying Coordination Membrane Stack for agentic AI systems operating across edge, fog, and cloud environmentsâat a conceptual and architectural level. The internet scaled because TCP/IP standardized the unit of communicationâpacketsâand the rules for addressing, routing, and reliable delivery.
Agentic AI will scale when we standardize the unit of coordinationâintentâand the rules for addressing, routing, verifying, and settling actions among heterogeneous autonomous systemsâwithout prescribing specific encodings or algorithms.
Why a new protocol is needed
Small language models and compact planners will soon run on nanoscale hardware at the edge: drones, substations, vehicles, handhelds, cameras, factory lines, kiosks. Networks move data well, but coordination remains bespoke. Todayâs stacks route bytes, not goals. They deliver telemetry and models, not decisions. When autonomous systems must decide who should act, under which constraints, with which authority, using whose budget, we fall back to adâhoc custom schemas, siloed buses, and brittle cloud orchestrators.
This does not scale across jurisdictions, vendors, or security domains. It centralizes choke points, increases backhaul dependency, complicates compliance, and blocks local economic participation. The absence of a universal intent envelope is the architectural gap. IPP addresses this gap.
Background: the informationâgeometry view
A practical way to understand whatâs coming rests on three observations:
Cost keeps falling. Language and planning models now fit on edge hardware. Coordination has to work where they run.
Velocity keeps rising. Decisions are moving to real time. We need checks before action, near the point of action.
The information surface keeps expanding. Billions of endpoints are coming online. Most opportunity will appear at the seams where systems meet.
Two lenses follow from this:
Three accesses. (1) Access to information: edgeless compute on flat networks. (2) Access to value: programmable payments at the edge. (3) Access to information / hardware membrane interactions: the overlaps among apps, devices, delivery networks, finance, and rulesâwhere disruption and new profit pools emerge. IPP aims squarely at those overlaps by making intent the unit that carries provenance, policy, and payment across membranes.
Fractals. The same pattern repeats at every scaleâdevice, facility, city, nation. A viable substrate must be recursive: the same envelope and verification model should work for two devices on a local link and for crossâborder networks.
IPP fits this view operating at the interconections: it lowers coordination cost, supports realâtime velocity with preâexecution checks, and expands the usable surface by standardizing how autonomous systems propose and settle actions across membranes.
Membranes: background and operating model
What is a membrane? A membrane is a boundary where interfaces, rules, and economics change. Crossing a membrane means moving from one set of assumptions to anotherâapp logic to device capability, private network to public internet, internal policy to external law, budget to settlement, and so on. Coordination friction lives at these boundaries.
Why it matters now. As the information surface expands (more endpoints, more policies, more payment options), the number of seamsâwhere membranes meetâgrows faster than the number of devices. Most failures in autonomous coordination happen at seams: something that was permitted in one context is disallowed, unfunded, or unproven in the next.
Canonical membranes in digital systems
Application membrane â human or system workflows. Unit: tasks/goals. Interface: APIs, events. Risk: doing the wrong thing.
Capability/device membrane â what hardware and local services can actually do (sensors, actuators, models). Unit: capabilities. Risk: overâpromising or unsafe actuation.
Delivery/network membrane â how information moves (LAN, cellular, mesh, satellite). Unit: links/routes. Risk: latency, loss, jamming, cost.
Policy/compliance membrane â laws, contracts, standards, safety cases. Unit: obligations/permissions. Risk: illegality, sanctions, safety violations.
Economic/payments membrane â budgets, prices, escrows, credits. Unit: money/tokens. Risk: unpaid work, fraud, cost blowouts.
Identity/trust membrane â credentials, attestations, reputations. Unit: claims/proofs. Risk: spoofing, impersonation, weak provenance.
Data/privacy membrane â residency, consent, PII handling, classification levels. Unit: data classes/labels. Risk: leakage, misuse, nonâcompliance.
How IPP uses membranes. IPP treats intent as a membraneâtraversable artifact. Each intent envelope binds:
Origin & scope â identity/trust membrane (who is proposing, under what authority, for which locale/mission).
Goal & semantics â application membrane (what is to be achieved, with machineâparsable detail).
Capabilities required â capability/device membrane (who is eligible to execute).
Routing & discovery â delivery/network membrane (how the proposal moves to eligible executors).
Policy proof â policy/compliance membrane (why this proposal is allowed before anyone acts).
Privacy class & audit â data/privacy membrane (what may be shared and how itâs verifiable later).
Economic terms â payments membrane (how resources are reserved and settled on completion).
With IPP, crossing membranes does not require bespoke glue each time; the same envelope carries the facts every membrane needs to accept, forward, or refuse an action.
From data packets to intent packets
A data packet carries bytes and leaves meaning to the application. An intent packet carries a compact, signed description of an action proposal suitable for autonomous execution. Downstream actors can verify it, route it, decompose it, negotiate it, or reject itâwithout roundâtrips to a central brain. Where TCP/IP abstracts physical links, IPP abstracts organizational, legal, and economic membranes so unlike systems can work together safely at scale.
The IPP envelope: core properties
IPP defines a selfâcontained, cryptographically attestable envelope for an action proposal. Instead of publishing fieldâbyâfield schemas, IPP focuses on properties every compliant envelope must satisfy:
Verifiable origin and scope. The envelope binds the proposing agentâs identity and the context (locality, mission, governance) in which the intent is valid.
Machineâparsable semantics. The goal, context, and constraints are expressed so autonomous systems can evaluate and, if needed, split the work.
Preâexecution policy proof. Each envelope carries a compact artifact showing the proposal conforms to machineâexecutable policy before resources are allocated.
Portable audit. There is enough linked evidence to reconstruct what was proposed and what occurred, independent of any single vendor.
Coupled settlement. Acceptance, execution, and completion can be tied to payment or credit so work can be priced and settled.
Implementations can choose their encodings, crypto, and data models. IPP standardizes what must be true, not how it is serialized.
The Coordination Membrane Stack
IPP organizes how intents move and resolve:
Addressing & discovery. Map a proposed action to eligible executors based on capabilities and governance context (what skills are required, under which rules, in which place).
Routing. Move intents across mixed networks. Intermediaries can verify policy conformance and eligibility without seeing private data.
Compliance. Make a preâexecution policy proof a condition of forwarding or acceptance. If the proof is missing or invalid, the intent doesnât proceed.
Economics (payments/settlement layer). Couple acceptance and completion to payment so work can be priced, budgeted, escrowed, and settled.
Fractal orchestration. Run the same abstraction from a handful of devices to multiâorganization coalitions.
Builtâin compliance and provenance
In IPP, compliance is not advisory. If the policy proof is absent or invalid, the envelope does not resolve. Because the proof is produced alongside the planânot after executionâconformance is portable and checkable at every hop. Provenance ties the issuerâs runtime and data signatures to the envelope so auditors and insurers can replay decisions, attribute liability, and price risk.
Embedded economics
Coordination needs cashflow. IPP supports embedded settlement so agentâtoâagent interactions can be priced, budgeted, insured, and paid without central schedulers. This enables local markets for microâcapabilities (for example: âclassify this sample,â âdispatch within 3 km,â âbalance 5 kW electricity for 10 minutesâ), fair exchange across trust boundaries via escrowed acceptance and auditable completion, and programmable caps or credits that reflect policy.
Payment rails are pluggable and jurisdictionâaware.
Security considerations
Attested execution for issuers and executors so proposals and actions can be tied to measured runtimes and known policy sets.
Freshness by design through nonce/expiry semantics appropriate to the transport to prevent replay.
Transparent policy toolchains with reproducible proofs so compilers can be independently checked.
Tamperâevident audit using contentâaddressable, crossâverifiable records.
Abuse pricing and flow control via rateâlimits and economically priced participation to deter floods.
Worked examples
Airspace coordination
A regional operator manages a mixed fleet of small UAVs supporting inspection and public safety. A local node observes a weather window and proposes a timeâbounded survey of Sector 12 with altitude, privacy, and export restrictions. The intent is addressed to âany aircraft with battery ⼠40%, optical payload v3, and authorization for that sector.â Nearby candidates receive the envelope, verify the policy proof (airspace class, geofences, privacy redaction rules), and check that settlement terms cover airspace fees and pilotâinâcommand oversight. One aircraft accepts, the others stand down. If the link drops, the aircraft continues under the same verified plan and logs events for later reconciliation. On completion, the aircraft publishes audit pointers (position trace, redacted imagery fingerprints, event log) and references a payment receipt. The operator closes the loop with a single, verifiable artifact of who acted, under which rules, and how it was paid.
Distribution grid flexibility
A electrical substation controller detects a phase imbalance and drafts an intent to curtail 150 kW for 10 minutes within 3 km. Eligibility is âhousehold or commercial battery with stateâofâcharge ⼠40%, tariff class X, consent on file.â The envelope carries a policy proof covering local privacy law and utility safety constraints, plus a capped price schedule. Dozens of resources receive the proposal; their agents verify policy and price, accept a share (for example, 3â5 kW), and lock microâescrow. During the window, each participant follows the setâpoint locally; exceptions are logged. When the window closes, devices emit signed summaries: actual curtailment, timestamps, compliance notes. Settlement clears automatically. No personal telemetry leaves premisesâonly signed summariesâyet the utility gets verifiable flexibility at street level.
Industrial field service
An operator at a remote site needs a CategoryâA valve replaced within two hours, budget ceiling $500. The site agent forms an intent addressed to nearby certified suppliers and technicians. The policy proof enforces that only parts meeting the facilityâs spec and jurisdictional rules can be used; the economics section includes an escrow that releases on delivery scan and installation confirmation. The first eligible supplier counters with a 90âminute delivery; a certified technician 15 km away accepts the install. The system coordinates the handoff: delivery logs, installation steps, safety checksâall recorded as audit pointers. Funds release when both delivery and install proofs align. The operator gains speed and compliance without central dispatch.
Disaster logistics
After a coastal storm, a cityâs emergency network needs 1,000 liters of potable water distributed to four shelters before nightfall. A command node publishes an intent with location windows, safety and chainâofâcustody rules, and budget caps. Eligible vehicles (municipal, nonprofit, private) receive the proposal through mesh links. Each verifies the policy proof (road closures, priority routes, handling rules), commits to a segment, and locks escrow for fuel and perâstop fees. As deliveries complete, drivers submit signed drop confirmations tied to shelter staff countersignatures. The city seesâwithout central micromanagementâwhere water went, who delivered it, and that policy and budget were respected.
Relation to AP2 (Agent Payments Protocol)
In IPP, the economic membrane is the payments and settlement layer: how agents price work, reserve budget, escrow funds, and release payment on completion. AP2 is a payments protocol for agentâled purchases. The two meet here: IPP can use AP2 to execute the payment portion of any intent that involves buying goods or paid services, while IPP continues to handle policy checks, routing, and audit. Nonâcommerce actions remain IPPânative.
Alignment in practice
Mandate reference. An IPP intent that requires settlement may carry a reference to an AP2 mandate and associated proof. Acceptance is conditional on verifying that mandate.
Gated execution. Before actuation, recipients verify both the IPP policy proof and the AP2 mandate reference. If either fails, the intent does not proceed.
Linked audit. On completion, executors publish IPP audit pointers and reference the AP2 payment proof so technical and financial records reconcile without exposing payment details.
Relation to A2A, MCP, and other emerging agent frameworks
What IPP adds. IPP is about accountability: policy checked before action, audit after action, and payment on completion. The items below improve connectivity and execution; they do not standardize those accountability steps.
Google A2A (Agent-to-Agent)
What it is: cross-vendor discovery and a common messaging language.
What it isnât: no standard for policy verification, third-party audit, or settlement.
How to use with IPP: use A2A to find/reach peers; send the IPP intent envelope as the payload so proposals arrive with proof, audit hooks, and payment terms.
Anthropic MCP (Model Context Protocol)
What it is: a âUSB-Câ style tool/access port so models can call tools and data sources.
What it isnât: no policy proof, no audit format, no payment coupling.
How to use with IPP: after an IPP-verified intent is accepted, executors may call MCP tools to fulfill it; IPP still carries the proof, audit pointers, and settlement terms.
LangChain / LangGraph (and similar)
What they are: execution frameworks for planning, routing, memory, evaluation.
What they arenât: no standardized cross-boundary contract (policy, audit, payment).
How to use with IPP: emit IPP intents whenever work crosses organizational or policy boundaries; accept only after IPP verification; on completion, return audit + settlement via IPP.
In short: A2A handles discovery/messaging. MCP handles tool access. Frameworks handle execution. IPP provides the cross-boundary contractâpolicy-verified intent, portable audit, and settlementâand runs over any of them.
Standards and community enablement: OpenTerms.com is proposed as a prospective standardsâlike foundation
An open protocol needs an open community. OpenTerms.com can serve as a neutral, standardsâlike foundation to convene contributors and steward the commons around IPP. Concretely, OpenTerms.com could:
Publish canonical, compilerâready policy bundles (and their hashes) for the IPP compliance membrane.
Maintain open registries for capability descriptors and policy bundle identifiers to ensure interoperable discovery and routing.
Run interop events, conformance test suites, and reference implementations under permissive licenses.
Host an RFC process (public issue tracker + proposals) and a lightweight governance charter to prevent vendor capture while enabling rapid iteration.
Curate machineâreadable change logs for legal, regulatory, and termsâofâservice artifacts that feed the intentâtoâpolicy compiler.
This document does not require any affiliation; it proposes OpenTerms.com as a practical locus for the standardsâlike functions required to grow an open IPP ecosystem.
Strategic implications
When intent becomes a routable, verifiable, and settleable packet, value creation migrates from centralized model farms and proprietary orchestrators to the intersections of membranesâwhere capabilities, policies, jurisdictions, and budgets meet. Control shifts to those who define the envelope, the policy compiler semantics, the resolver indexes, and the settlement rules. Open IPP prevents single-vendor capture, preserves national and corporate sovereignty, and enables efficient local markets.
This also reframes liability and insurance. Because intent packets bind provenance, policy, and audit in one artifact, risk pricing can move from blanket premiums to per-intent micro-actuarial models. Compliance shifts from post-hoc paperwork to pre-execution proofs. Regulators gain a testable substrate; operators gain faster cycles with less backhaul.
Claim language (as an intentional public disclosure, high level)
Independent claim A computerâimplemented method for decentralized coordination among autonomous agents, comprising: representing proposed actions as intents within a verifiable envelope that (i) binds origin and scope, (ii) encodes machineâparsable goals and constraints, (iii) carries a compact artifact proving preâexecution conformance to machineâexecutable policy, (iv) enables portable audit, and (v) couples acceptance, execution, and completion to settlement; discovering eligible counterparts based on capability and governance context; forwarding intents across intermediaries that can verify the artifact without access to underlying private data; and, upon verification, executing all or part of the proposal and emitting audit suitable for independent reconciliation.
Dependent concepts (illustrative, nonâexhaustive)
Routing and selection informed by capability, locality, and governance context.
Deterministic production of policy proof artifacts from humanâreadable governance sources.
Intent decomposition and recomposition across multiple executors with coupled settlement.
Crossâverifiable audit suitable for thirdâparty assurance.
Operation across intermittent links and at multiple scales without changing the envelope abstraction.
Governance and standardization
To avoid capture, IPP should be advanced in an open venue with a lightweight governance model: public RFC process, royaltyâfree license for the envelope specification, interop test suites, and reference implementations under permissive licenses. The policy compiler should support pluralism: multiple rule sources and multiple backends so that national and sectoral sovereignty are preserved. An independent registry of capability descriptors and policy bundle identifiers enables interop without central control.
OpenTerms.com or other public website can act as that neutral venue: hosting the RFC process, publishing signed releases of the specification and policy bundles, and coordinating interop events while keeping artifacts royaltyâfree and vendorâneutral.
Call for collaborators
This is a public proposal and a defensive disclosure, not a finished standard. The work ahead includes: formalizing the envelope schema and encodings; specifying resolver and router behavior; defining the policy IR and compiler interface; building reference implementations for edge hardware; and validating the economic primitives in real deployments. The first cohorts who align around a clean core will likely define the default for decades.
If you are an AI researcher, protocol engineer, systems builder, risk/insurance modeler, or a policymaker seeking a technically enforceable substrate, you are invited to engage. If you operate platforms that monitor and normalize policy texts, consider publishing compiler-ready bundles and hashes to feed the compliance membrane. If you maintain AP2 or similar payments protocols, consider coâauthoring an interop draft that treats AP2 mandates as firstâclass settlement proofs referenced by IPP intents. If you plan to run edge fleets, prototype an issuerârouterâexecutor loop with simple intents and measure cost, latency, auditability, and settlement reliability.
Closing
TCP/IP made information universal by standardizing how we move bytes. IPP proposes to make coordinated action universal by standardizing how autonomous systems propose, verify, route, and settle intents. The packet is the protocol. The envelope is the contract. The checksum is the law. The footer is the budget. The network is the negotiation.
This document places the Intent Packet Protocol (IPP) and the Coordination Membrane Stack into the public domain as prior art and as a starting point for an open standard. Build with it, argue with it, improve itâbut do not enclose it.















