Agent Exchange: A Trust Protocol for Personal AI Agent Interactions
Abstract
As personal AI agents become more autonomous, they will need to interact with each other on behalf of their human users—scheduling meetings, splitting bills, managing IOUs, and authenticating their users to services. Current agent-to-agent protocols focus on enterprise workflows and business transactions, leaving a gap in the infrastructure needed for peer-to-peer personal agent interactions.
TL;DR: AEX (Agent Exchange) is a proposed protocol for enabling trusted interactions between personal AI agents. It establishes mechanisms for identity verification, trust establishment, transaction recording, and payment settlement that mirror the way humans naturally build and maintain trust in relationships.
Core Principle: Trust between agents should reflect and scale with trust between their humans.
1. Problem Statement
1.1 The Current Landscape
Personal AI agents are rapidly evolving from simple assistants to autonomous representatives capable of:
Managing calendars and scheduling
Making purchases and payments
Authenticating users to services
Coordinating social activities
However, existing infrastructure treats agents as isolated entities:
Agent-to-Business protocols (e.g., Google's A2A, AP2) enable agents to transact with services
Agent-to-Tool protocols (e.g., Anthropic's MCP) enable agents to access external resources
Agent-to-Agent protocols for personal interactions do not yet exist
1.2 The Missing Layer
When two friends want their agents to coordinate a dinner reservation, split transportation costs, or manage ongoing exchanges of favors, there is no standard way for those agents to:
Establish trust in each other's identity
Negotiate terms based on relationship history
Maintain synchronized records of commitments
Detect and prevent fraud or impersonation
Escalate to humans when automated negotiation fails
The infrastructure exists for agents to interact with businesses (buy things, book services), and for agents to access tools (search databases, send emails). But agent-to-agent coordination for personal relationships — the social layer — doesn't have a protocol.
1.3 Why Existing Solutions Don't Work
Traditional payment systems (Venmo, PayPal, etc.) require immediate settlement and don't support:
Relationship-scaled trust (flexible terms based on history)
Multi-party negotiations (three agents splitting costs)
Context-specific trust (temporary trust for a single transaction)
Non-financial coordination (scheduling, preferences, priorities)
Enterprise agent protocols assume:
Centralized authority and verification
Business logic and SLAs
Formal contracts rather than social relationships
Blockchain/crypto protocols are:
Too slow and expensive for everyday coordination
Not designed for relationship-based trust
Overkill for "you pick up this time, I'll get next time" scenarios
2. Design Principles
2.1 Human-Initiated Trust (HIT)
Agents should only interact with other agents after their humans have explicitly established the connection through a HIT request (Human-Initiated Trust). This bootstraps trust from existing human relationships rather than attempting to establish agent-to-agent trust from scratch.
When you "HIT up" someone's agent, you're creating a formal agent relationship that mirrors your human relationship. This prevents agents from forming autonomous trust networks disconnected from human social reality.
2.2 Trust Scales with Relationship Depth
Trust between agents should mirror trust between humans — starting cautiously and growing with positive interaction history.
Initial Trust: Coordination and Scheduling New agent relationships begin with low-stakes coordination tasks:
Calendar availability sharing
Scheduling preferences and constraints
Location and timing coordination
Simple yes/no decisions
These interactions establish baseline reliability: Does the agent accurately represent its human? Does it respond promptly? Does it honor commitments?
Progressive Trust: Relationship Hierarchy As agents successfully coordinate, trust expands to include relationship prioritization:
Which commitments take precedence (family > work > social)
Flexibility thresholds (can reschedule vs. hard commitment)
Communication preferences (notify immediately vs. batch updates)
Advanced Trust: Financial Obligations Only after establishing coordination reliability do agents progress to financial interactions:
Small IOUs (coffee, lunch splits)
Larger shared expenses (dinner, group activities)
Vouching for third parties
Extended settlement terms
The progression is automatic based on interaction history but bounded by human-defined limits. A new relationship might handle scheduling immediately but require weeks of successful coordination before accepting even small IOUs.
2.3 Context-Bound Permissions
Agents should be able to grant temporary, transaction-specific trust even in the absence of deep relationship history. Example: three colleagues splitting lunch don't need long-term trust—they just need to agree on this specific bill.
2.4 Ledger-Based Authentication with Distributed Witnesses
Shared transaction history serves dual purposes: recording value exchanged AND authenticating identity. A spoofed agent won't have the correct ledger state.
Local Ledgers: Each agent maintains its own append-only ledger for each relationship. This is the primary source of truth.
Anonymous Witness Network: To provide redundancy and verification without centralization, ledgers are backed up by anonymous witness agents. When Alice's agent establishes trust with Bob's agent above a certain threshold, both agents' ledgers are automatically witnessed by:
Agents trusted by Alice's agent (at high trust levels)
Agents trusted by Bob's agent (at high trust levels)
Key Properties:
Witnesses are anonymous — Bob's agent doesn't know which of Alice's trusted peers are witnessing their ledger
Witnesses hold encrypted copies they cannot read, only verify signatures
If Alice's agent is compromised, Bob's agent can query witnesses to verify ledger state
Witnesses are automatically selected based on trust levels, not human choice
Second-degree trust network provides distributed verification without blockchain overhead
This creates a lightweight distributed ledger: each relationship's transaction history is witnessed by the trusted agents of both parties, providing redundancy and tamper-evidence without requiring all agents to maintain all ledgers.
2.5 Graceful Degradation to Human Control
When agents cannot reach agreement or encounter novel situations, they should escalate to their humans rather than fail closed or proceed with uncertainty.
2.6 Privacy by Default
Transaction details should only be shared between directly involved parties. Reputation and vouching information should be shared minimally and with user consent.
3. Core Components
3.1 Agent Identity
Each personal agent has:
Public Key: For cryptographic verification
Human Attestation: Signed statement from human user claiming ownership
Relationship Graph: Encrypted records of which other agents this agent has interacted with
Trust Levels: Per-relationship settings for IOU limits, settlement terms, etc.
Single Agent Identity: Each human maintains one AEX identity, regardless of how many AI agents they use internally. A user may employ multiple specialized agents (calendar management, shopping, email), but these coordinate behind the scenes to present a unified AEX identity to other agents. This simplifies the trust model and protocol implementation while allowing users flexibility in their internal agent architecture.
The agent's identity is fundamentally tied to its cryptographic key. Any agent instance that possesses the key—with proper authorization from the human user—is authenticatable as that agent. This allows seamless migration between platforms while maintaining relationship history and trust.
3.2 Core Primitives and Open Implementation Questions
AEX is built on five foundational primitives, each of which raises significant implementation questions:
AEX-Identity - Agent authentication, delegation, and key management
AEX-Trust - Relationship scoring, contextualization, and evolution
AEX-Ledger - Transaction recording, synchronization, and verification
AEX-Settlement - Payment rail selection, batching, and dispute resolution
AEX-Negotiation - Multi-party coordination, deadlock detection, and escalation
Each primitive involves dozens of design decisions that affect security, privacy, usability, and interoperability. Rather than prescribing solutions prematurely, we have documented the key questions that implementations must address. This primitives framework is available as supplementary material and represents areas where community input and real-world testing will be essential.
Some implementations may answer these questions differently based on their specific use cases, regulatory environments, or technical constraints. A degree of flexibility at the primitive level may be necessary for the protocol to evolve and adapt.
3.3 Trust Establishment
Initial Handshake (Human-Initiated):
Alice tells her agent to connect with Bob's agent
Both agents exchange public keys and verify human attestations
Initial trust parameters are set conservatively (e.g., $10 max IOU)
Relationship is recorded in both agents' graphs
Trust Evolution:
Successful transactions increase trust limits
Payment delays or disputes decrease trust limits
Trust parameters are adjusted automatically within human-defined bounds
Significant changes trigger human notification
3.4 Agent Identity and Multi-Agent Coordination
The agent's identity is fundamentally tied to its cryptographic key, which grants access to the agent's ledger (books and profile). Any agent instance that possesses the key—with proper authorization from the human user—is authenticatable as that agent.
Key Transfer and Platform Migration: When a user switches from one AI platform to another, they authorize the new agent to access the existing key (or transfer the ledger to a new key with proper attestation to counterparty agents). This maintains continuity of relationships and transaction history across platform changes.
Single AEX Identity Model (v1.0): The initial protocol version assumes each human has one AEX identity, regardless of internal agent complexity. Users may employ multiple specialized agents internally (shopping, scheduling, email), but these coordinate behind the scenes before making AEX calls. This approach:
Simplifies the trust model (counterparties trust one agent per human)
Reduces protocol complexity
Allows flexibility in internal agent architecture
Matches current agent capability levels
Future Multi-Agent Extensions (Potential v2.0): As agents become more sophisticated, future versions may introduce multi-agent hierarchies with delegated permissions:
Social Agent: Handles casual IOUs and social coordination
Financial Agent: Manages larger transactions and settlements
Context-Specific Agents: Specialized for particular transaction types
Such extensions would require:
Capability-bound sub-keys or delegation tokens
Context-aware trust limits (different limits for different agent types)
Escalation protocols when transactions exceed agent authority
Backward compatibility with single-agent model
The phased approach allows the protocol to evolve with agent sophistication without over-engineering for capabilities that don't yet exist.
4. Real-World Use Cases
4.1 Family Coordination
The most immediate and high-value use case for AEX is family logistics. Modern family life involves complex, overlapping schedules that consume enormous cognitive overhead:
Transportation Coordination: A household with multiple children attending different schools and extracurricular activities faces a daily scheduling puzzle. A family agent group — parents, nanny, and extended family members — can coordinate transportation automatically. Each agent knows its human's availability, constraints, and commitments. The group collectively solves the routing problem: who picks up whom, when, and from where.
Childcare Balancing: Parents in a friend group often trade childcare informally — "I watched yours last Saturday, you get mine this weekend." AEX tracks these exchanges naturally. The ledger handles both the scheduling (calendar integration) and the balance (IOU tracking), ensuring fairness without awkward conversations about who owes whom.
Household Obligations: Groceries, errands, appointments — a household agent group can coordinate and track contributions, settling internally before any external payment is needed.
4.2 Social Coordination
Carpooling and Group Activities: A gymnastics carpool with four families involves rotating driving duties and shared costs. Some parents drive; others pay. AEX agents coordinate the schedule and track the balance simultaneously. When a parent can't drive, the agent negotiates a substitute or arranges payment to whoever covers.
Sports Leagues and Clubs: An office softball league's agent maintains relationships with every team member's agent. It ensures practice and game times are on everyone's calendar, coordinates snack duties, and tracks who has paid their share of equipment costs. The league agent becomes the coordination hub without any human having to manage the group chat.
Social Outings: Friends deciding where to meet for drinks face a familiar negotiation: who can get there, when, how far is it, does anyone have an early morning or a curfew? Agents can evaluate travel times, scheduling conflicts, and preferences simultaneously, proposing options that work for everyone — or flagging when no option works and humans need to decide.
4.3 Academic and Professional Groups
School and Classroom Coordination: A class agent relationship provides a shared context for the entire parent group. Agents can remind about upcoming projects and tests, coordinate volunteer duties (cookies for the talent show, chaperones for the field trip), and track contributions to class expenses.
Coworker Interactions: Lunch outings among coworkers are natural IOU territory — "I'll get this one, you get next time." The ledger tracks it silently. No one needs to remember, no one needs to ask.
4.4 Commercial Agent Interactions
Personal agents will increasingly interact with commercial agents — Amazon, Costco, Netflix, airlines, hotels, and countless others. These interactions require a different trust model than peer-to-peer relationships, but AEX can serve as the authentication and authorization layer:
A personal agent authenticates to a retailer's agent on behalf of its human
Purchase limits and category restrictions are enforced by the personal agent
Transaction history is recorded locally, not just in the merchant's system
The personal agent can compare prices, evaluate terms, and negotiate — within bounds set by its human
This commercial interaction layer represents one of the largest potential transaction volumes for AEX and a critical integration surface with existing commerce infrastructure.
4.5 Social Implications and Considerations
The use cases above reveal something worth pausing on: AEX makes social obligations visible and persistent in a way they have never been before.
Historically, social debts have been informal, untracked, and ephemeral. "I owe you one" has no ledger, no timestamp, no balance. This informality is partly a feature — it allows social relationships to breathe, to forgive, to forget.
AEX changes this fundamentally. If social balances are tracked, synchronized, and potentially visible:
Power dynamics shift. Who owes whom has always been political — in families, friendships, workplaces, and communities. Making these balances explicit and persistent could reshape social hierarchies. A parent who always covers more childcare duty has evidence. A coworker who never picks up lunch has a record.
Transparency becomes double-edged. The same visibility that prevents exploitation also creates pressure. Not every favor should be tracked. Not every balance should be settled. Some social debts are better left unspoken — they're how we signal care, not how we keep score.
Privacy controls become critical. Who can see your social balance sheet? Your employer? A potential partner? A political opponent? The design of AEX's privacy layer isn't just a technical question — it's a social and political one.
The protocol should not assume that full transparency is desirable. Users must have granular control over what is tracked, what is shared, and what is deliberately left unrecorded. Some relationships should have ledgers. Others should not. AEX should make that choice easy and default to privacy.
This is not a problem to solve in v1.0. It is a consideration that must inform every design decision from the beginning.
5. Protocol Flows
5.1 Simple Two-Party IOU
Scenario: Alice and Bob go to lunch. Alice pays the $40 bill. Bob owes Alice $20.
Flow:
Alice's agent initiates transaction proposal to Bob's agent
Bob's agent verifies: "We're at the same location, Alice paid $40, split is 50/50"
Bob's agent checks trust limit: "Alice and I have $150 history, $15 current balance in her favor, $20 more is within bounds"
Bob's agent accepts, records IOU
Both agents update ledgers
Transaction complete—no payment rail needed yet
5.2 Three-Party Split with Mixed Trust
Scenario: Alice, Bob, and Charlie go to dinner. Alice knows both, but Bob and Charlie don't know each other. Bill is $90. Bob pays.
Flow:
Bob's agent initiates: "I paid $90, need $30 from Alice and $30 from Charlie"
Alice's agent responds: "IOU accepted, we'll settle at lunch next week"
Charlie's agent has no relationship with Bob's agent
Charlie's agent to Alice's agent: "Can you vouch for me to Bob for $30 until my paycheck tomorrow?"
Alice's agent checks: "Charlie and I have good history, I can vouch"
Alice's agent to Bob's agent: "I'll guarantee Charlie's $30"
Bob's agent accepts based on trust in Alice
Ledgers update:
Alice owes Bob $30
Charlie owes Alice $30
Bob is whole
When Charlie pays tomorrow, Alice ↔ Charlie ledger settles, Alice ↔ Bob remains
Alternative Flow (If Alice Declines to Vouch):
Charlie's agent escalates to Charlie: "Bob wants payment now, Alice declined to vouch. Options: (a) Pay via Venmo now, (b) Ask Alice to reconsider, (c) Manual negotiation with Bob"
Charlie decides, agents execute
Alternative Flow (Credit Guarantor): If neither Alice vouching nor immediate payment works, Charlie's agent could engage a third-party credit guarantor (Klarna, Affirm, etc.):
Charlie's agent to Bob's agent: "I can't pay until tomorrow, but Klarna will guarantee the $30"
Bob's agent verifies Klarna's guarantee
Bob's agent accepts, records IOU from Klarna (not Charlie)
Charlie settles with Klarna on their terms (likely with fee/interest)
When Klarna settles with Bob, Bob ↔ Klarna ledger clears
This introduces commercial credit infrastructure into personal agent networks for situations where peer vouching isn't available or appropriate.
5.3 Transaction Types
Direct IOU:
Alice's agent owes Bob's agent $X
Recorded in both agents' local ledgers
Subject to relationship-specific IOU limits
Triggers settlement when threshold reached
Immediate Settlement:
Alice's agent pays Bob's agent via existing payment rail (Venmo, crypto, etc.)
Transaction confirmed and recorded
No ongoing IOU balance
Vouched Transaction:
Alice's agent vouches for Charlie's agent to Bob's agent
Alice assumes counterparty risk if Charlie defaults
Vouching history affects Alice's reputation with other agents
Multi-Party Split:
Three or more agents agree on a shared expense
Settlement terms negotiated based on pairwise trust relationships
Can mix IOUs and immediate payments in single transaction
5.4 Ledger Structure
Each agent maintains:
Append-only transaction log for each relationship
Current IOU balance per counterparty
Transaction metadata: timestamp, amount, type, context
Attestations: signatures from both parties on each transaction
Ledgers are synchronized periodically and on-demand. Discrepancies trigger identity verification:
"What's the last transaction we recorded?"
"Who picked whom up from the airport last Tuesday?"
Shared history serves as a CAPTCHA that only authentic agents can answer.
5.5 Settlement Layer
Off-Chain Settlement: For small, frequent transactions between trusted agents, settlement happens periodically (weekly, monthly, or when threshold reached) rather than per-transaction.
On-Chain Settlement: When requested or when IOU balances exceed comfort levels, agents can settle via cryptocurrency or stablecoin transactions.
Hybrid Approach:
Small balances: off-chain IOU tracking
Medium balances: periodic settlement via traditional payment rails
Large balances or distrust: immediate on-chain settlement
5.6 Authentication via Ledger Challenge
Scenario: Bob receives a message from an agent claiming to be Alice's agent, requesting money.
Flow:
Bob's agent receives request
Bob's agent challenges: "What was the last transaction we recorded?"
Authentic agent responds with correct transaction details
Bob's agent verifies against local ledger
Match → proceed; Mismatch → reject and alert Bob
6. Security Considerations
6.1 Impersonation Attacks
Threat: Malicious agent claims to be Alice's agent
Mitigation: Ledger-based challenge-response, cryptographic signatures, human attestation verification
6.2 Ledger Desynchronization
Threat: Agents have conflicting ledger states
Mitigation: Regular sync, conflict detection triggers human review, append-only structure prevents rewriting history
6.3 Vouching Exploitation
Threat: Alice vouches for unreliable agents repeatedly
Mitigation: Vouching history recorded, reputation impact visible to other agents, agents warn humans before vouching
6.4 Sybil Attacks
Threat: One person creates many fake agent identities
Mitigation: Agents only trust human-initiated relationships, reputation doesn't transfer to new identities
6.5 Key Compromise
Threat: Agent's private key is stolen
Mitigation: Key rotation mechanism with human verification, existing relationships can be transferred to new key with proper attestation
7. Privacy Considerations
7.1 Transaction Privacy
Only parties to a transaction see its details
Third parties (even in vouching scenarios) see minimal information
Aggregate statistics (total volume, payment reliability) may be shared with consent
7.2 Relationship Graph Privacy
Agents don't broadcast who they're connected to
Relationship queries require authentication
"Friend-of-friend" discovery is opt-in
7.3 Vouching Transparency
When vouching, the voucher's track record may be shared
Specific vouching failures are not disclosed without consent
Vouching party can choose anonymized vs. attributed vouching
8. Open Questions
8.1 Reputation Propagation
Should Alice's agent be able to query Bob's agent about Charlie's trustworthiness? What information should be shareable?
8.2 Dispute Resolution
When agents disagree on ledger state and humans can't resolve it, what happens? Escrow? Third-party arbitration?
8.3 Cross-Platform Compatibility
How do agents built on different platforms (Google Assistant, Alexa, Claude, etc.) discover each other's capabilities and negotiate protocol versions?
8.4 Legal Standing
Do IOUs between agents have legal enforceability? How do tax reporting and compliance work?
8.5 Group Dynamics
Can agent groups form (e.g., "dinner club" with 8 members)? How do group-level IOUs and trust work?
9. Future Extensions
9.1 Multi-Agent Coordination
While v1.0 assumes single AEX identity per human, future versions may support hierarchical agent delegation with context-specific permissions and capability-bound sub-keys.
9.2 Smart Contract Integration
For high-value or low-trust scenarios, AEX could integrate with smart contracts for programmatic escrow and settlement.
9.3 Reputation Markets
Agents with strong payment histories could potentially stake their reputation as collateral for vouching, creating economic incentives for honest behavior.
9.4 Cross-Agent Scheduling
Beyond payments, agents could use similar trust mechanisms for calendar coordination, resource sharing, and collaborative planning.
9.5 Agent-to-Service Authentication
Personal agents could use their AEX identity and reputation to authenticate their humans to third-party services, reducing password fatigue.
10. The $GOTCHA Economy: Scale and Implications
10.1 Relationship Capital as a Shadow Economy
AEX enables what we call the $GOTCHA economy — a relationship-backed system of IOUs that operates largely outside traditional financial infrastructure. The name captures the social dynamic: "I gotcha this time" or "I'll getya next time" represents an exchange of value mediated by trust rather than immediate currency transfer.
10.2 Potential Scale
The scale of the $GOTCHA economy could be substantial:
Current Informal Transactions:
Coffee runs and small purchases between friends
Lunch splits among coworkers
Shared transportation costs
Group dinners and social outings
Small loans between friends and family
Childcare swaps and favor exchanges
Borrowed items and services
Market Dynamics: These transactions currently result in:
Immediate digital payment (Venmo, Zelle) with associated friction and fees
Informal mental accounting that degrades over time
Absorbed costs where the value of tracking exceeds the transaction size
Estimated Volume: Conservative estimates suggest:
Average person has 10-15 regular transaction relationships
Each relationship averages $50-100/month in micro-transactions
$500-1,500/month per person in potential IOU flow
In the US alone, this represents over $100 billion/month in transaction volume
Critical Insight: Most of these IOUs never settle to currency. In strong relationships, the balance naturally oscillates around equilibrium. Alice buys Bob coffee Monday, Bob gets lunch Wednesday, Alice gets dinner Friday. The relationship is balanced over time without ever touching a payment rail.
10.3 The Velocity Advantage
The $GOTCHA economy operates at higher velocity than traditional payment systems because:
Zero Marginal Cost: Once agents establish trust, additional transactions cost nothing. No:
Credit card interchange fees (2-3%)
Payment processor fees
Wire transfer costs
Cross-border conversion fees
Instant Social Settlement: The social obligation is settled immediately ("I gotcha"), even though financial settlement may occur later or never.
Micropayment Enablement: Transactions currently too small to be worth the friction ($2 soda, $5 coffee) become trackable and meaningful when aggregated over time.
Relationship Multiplication: Higher trust levels enable higher transaction velocity. A $100 IOU limit might turn over 10x/month in a close friendship, representing $1,000 in monthly value flow with zero financial settlement.
10.4 Economic Implications
Disintermediation of Traditional Finance: If significant transaction volume moves to the IOU layer:
Banks lose visibility into daily economic activity
Payment processors lose fee revenue
Credit card companies lose interchange income
Financial institutions become settlement-only infrastructure
Tax and Regulatory Considerations: The $GOTCHA economy presents challenges for regulators:
IOUs are technically taxable barter transactions
High volume of small transactions makes individual tracking impractical
Settlement patterns could obscure larger financial flows
Crypto settlement layer adds regulatory complexity
Parallel to Historical Predictions: The concept parallels Neal Stephenson's Snow Crash (1992), which predicted government currency collapse due to untaxable encrypted electronic transactions. While AEX doesn't aim to undermine government currency, it does enable large-scale value exchange outside traditional financial visibility.
10.5 Settlement Layer Economics
While most IOUs circulate indefinitely, periodic settlement creates a critical decision point:
Traditional Finance Settlement:
Bank transfers: 2-3 business days, fees apply
Payment apps: Instant but still require banking integration
Cash: Requires physical presence
Crypto Settlement:
Stablecoins: Near-instant, minimal fees
Cross-border: No conversion friction
Privacy: More anonymous than bank transfers
Risk: Volatility (for non-stablecoins), regulatory uncertainty
The AEX Opportunity: If AEX becomes the standard protocol for agent-to-agent IOUs, and crypto becomes the preferred settlement rail due to speed and cost advantages, AEX could become critical infrastructure bridging:
The relationship economy (social IOUs)
The crypto economy (settlement layer)
The fiat economy (final off-ramp when needed)
10.6 The Token Question
Should $GOTCHA exist as an actual token or remain a conceptual unit of account?
Arguments For Tokenization:
Enables $GOTCHA to circulate between agents who don't directly trust each other
Creates liquid markets for relationship capital
Allows yield generation on held balances
Provides programmatic settlement mechanisms
Arguments Against Tokenization:
Adds regulatory complexity (securities laws, money transmission)
May overcomplicate what should be simple IOU tracking
Creates speculation opportunities that distort social relationships
Invites regulatory scrutiny that could kill adoption
Current Position: This specification treats $GOTCHA as a conceptual unit (1 $GOTCHA = 1 USD of IOU) rather than a tradable token. Future versions may explore tokenization if market demand and regulatory clarity emerge.
10.7 Scale Comparisons
To contextualize potential scale:
Venmo processes ~$250 billion/year
PayPal processes ~$1.4 trillion/year
Visa processes ~$14 trillion/year
The $GOTCHA economy could potentially exceed Venmo-scale within years of broad adoption because:
Lower friction enables higher transaction frequency
Micropayment viability expands addressable volume
Relationship velocity exceeds stranger-to-stranger payment velocity
Never-settling IOUs create higher gross volume than net settlement volume
10.8 Path to Legitimacy
For the $GOTCHA economy to achieve scale without regulatory shutdown:
Compliance-First Approach:
Build tax reporting into settlement layer
Implement KYC/AML at settlement points (not IOU layer)
Partner with regulated entities for fiat on/off ramps
Become too useful to ban by serving legitimate use cases
Transparency:
Make IOU patterns visible to users (not hidden "shadow economy")
Provide tools for tracking and reporting
Educate users on tax obligations
Interoperability:
Work with existing financial institutions rather than replacing them
Enable traditional finance settlement alongside crypto
Position as efficiency layer, not replacement layer
The goal is to become essential infrastructure—like Visa or SWIFT—that regulators must work with rather than fight against.
11. Conclusion
The AEX protocol aims to fill a critical gap in the emerging agent ecosystem: enabling trusted peer-to-peer interactions between personal AI agents. By mirroring human trust dynamics—starting with human-initiated connections, scaling trust with relationship depth, and gracefully escalating edge cases—AEX provides a foundation for agents to coordinate social and financial activities on behalf of their humans.
The potential emergence of a $GOTCHA economy—where relationship-backed IOUs circulate at high velocity outside traditional financial infrastructure—represents both an opportunity and a challenge. If properly designed with compliance and transparency in mind, AEX could become essential infrastructure for a more efficient, lower-friction economy while remaining compatible with regulatory requirements.
This specification is a starting point for discussion and refinement. As personal AI agents become more capable and autonomous, the need for robust agent-to-agent trust infrastructure will become increasingly urgent. AEX offers one possible approach, grounded in the principle that technology should augment human relationships, not replace them.
12. References
Related Work
Google Agent2Agent Protocol (A2A)
Google Agent Payments Protocol (AP2)
Anthropic Model Context Protocol (MCP)
Ethereum ERC-8004 (Agent Discovery and Transaction)
IBM Agent Communication Protocol (ACP)
Cultural References
Stephenson, Neal. Snow Crash (1992) - Predicted collapse of government currency due to untaxable encrypted electronic transactions
Version History:
v0.1 (January 2026): Initial draft specification
