#intent packet protocol

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.