Transactions used to require people.
Now agents can complete them.
Now agents can complete them.
MeshKit is the transaction infrastructure that connects Agent Commerce to real purchases and payments.
Jaegyu Lee · jaegyu.lee@meshkit.dev
01 · Moment
The user only
has to ask.
"Set up my Busan trip for tomorrow.
Morning arrival, a hotel near the station, and ground transport."
Morning arrival, a hotel near the station, and ground transport."
The agent finds the right apps, requests bookings, and carries the flow through payment.
1
Find apps
Discover flight, hotel, and transport capabilities
2
Request bookings
Call booking and payment functions in each app
3
Check policy
The wallet verifies amount, terms, and limits
4
Leave a record
The app signs the execution result
02 · Shift
Users used to tap apps.
Now agents call app functions.
If an agent owns the trip-booking flow,
can the transaction run reliably?
It needs direct app function calls, not brittle screen automation.
Today · Human
Choose apps
Operate screens
Approve and pay manually
→
Next · Agent
Discover required app functions
Execute with signed requests
Pay within wallet policy
03 · Why now
Agents already
search, compare, and choose.
AI is already taking over discovery, comparison, and selection. What is missing is the execution and payment layer.
$3B
in U.S. online sales influenced by AI during Black Friday 2025
23%
of U.S. consumers have used AI to make an actual purchase
90%
of B2B purchases are expected to involve AI agents by 2028
Agent Commerce is the next step in a buying behavior that has already started.
Sources: Salesforce · Morgan Stanley · Gartner (2025)
04 · Problem
Why agent commerce needs
new transaction infrastructure.
There is still no standard way to execute apps, pay, and leave verifiable results.
UI automation
Breaks when the screen changes
Platform lock-in
App capabilities and pricing get trapped inside one platform
Execution record
No common format for what ran, who approved it, and how it was paid
05 · Market
The new transaction infrastructure market
MeshKit is building for
Within commerce, MeshKit targets the layer where agents handle purchasing and payment.
TAM
$15T+
SAM
$3-5T
SOM
$10-25B
TAM
All repeatable and automatable commerce
SAM
Commerce where agents participate in purchase and payment flows
SOM
Starting with Agent Wallet x mobile commerce
Assumption: 0.5-1% of global mobile commerce
To unlock this market, agent transactions need a shared path.
Sources: Statista · McKinsey · Juniper Research · MeshKit estimate
AgentUser request
MeshKitTransaction path
AppExecution result
Request
Check policy
App execution
Record
06 · Solution
Agent transactions
flow through MeshKit.
Request, approval, execution, and records run on one shared path.
07 · How it works
A transaction completes
in four steps.
The agent discovers apps, calls them, pays, and records the result.
Discover
Find executable
app functions
app functions
Call
Run the app with
a signed request
a signed request
Payment
The wallet checks
terms and limits
terms and limits
Record
The app signs
the result
the result
08 · Demo
An agent transaction flow
validated across three apps
OpenAI-sponsored · Hashed-hosted · OBA Weekendthon
Main Track Top 3
Main Track Top 3
HermesChatDailyMartMintNotes
✓ Discovery: app functions exposed in executable form
✓ Call: app-to-app execution with signed requests
✓ Payment: testnet payment after wallet policy verification
✓ Record: the app signs and issues the execution result
↗ VentureSquare: "An execution network for app-to-app function calls and result verification"
Loop 1App-to-app call
Loop 2Payment & record
09 · Beachhead
The beachhead is
Agent Wallet x mobile purchasing.
We start where repeat purchases are frequent: mobile commerce, using the payment flow validated in the demo.
1
Beachhead
Agent Wallet x mobile purchasing
Start with bookings, orders, and subscriptions where agents will repeatedly pay on behalf of users.
Key moment: the first time an agent spends money
→
2
Infrastructure
Permissions, limits, and payment records
Standardize approval policy and records for mobile purchases so more apps can plug in.
Every repeat transaction compounds policy templates and records
→
3
Expansion
B2B repeat purchasing and settlement
Expand into repeat orders, bookings, and settlement workflows that require verifiable records.
Extends into post-payment verification and dispute handling
This is not a feature rollout. We start where repeat payments happen first, then expand into larger transactions.
10 · Business model
As transaction volume grows,
revenue grows with it.
We begin with per-transaction fees, then expand through policy, record, and settlement API usage.
Revenue model
Transactions
×
Fee per transaction
+
API usage
Repeat transactions increase both fees and API usage
Transaction Fee
Fee per transaction
Wallet Policy
Permission policy engine
Verification API
Record verification API
Settlement
Settlement tools
11 · Competition
Only MeshKit
connects the full transaction path.
MeshKit is not one feature. It is the shared path agent transactions move through.
Category
App execution
Wallet policy
Payment
Execution record
AutomationUI automation
Screen clicks
-
-
Weak
Payment APIPayment infrastructure
-
Partial
Strong
-
Big TechPlatform
Strong
Inside platform
Inside platform
Inside platform
MeshKitTransaction path
App calls
Policy verification
Payment connection
Signed records
Core difference: MeshKit is not a single feature. It is the shared path agent transactions move through.
12 · Moat
The more transactions repeat,
the stronger MeshKit gets.
As more app functions and approval policies connect, the next transaction becomes faster and safer.
App capability network
Executable functions and call conditions per app
Wallet policy templates
Amount, frequency, and app-level permissions
Transaction record graph
The basis for settlement, disputes, and the next transaction
13 · Roadmap
Build repeat transactions,
then build the moat on top.
Start with mobile transactions, then expand into external apps, record verification, and settlement.
14 · Founder
Building agent transaction infrastructure
from Agent OS experience
This roadmap starts from hands-on experience building agent and service infrastructure.
Jaegyu Lee
M.S. in Database Systems, Seoul National University of Science and Technology
- Ouroboros: 4,000+ ★ open-source Agent OS
- Day1Company PODO Tech Lead: 0 -> $6M ARR / 12 months
- ZEP Tech Lead: led company-wide AI-native transition; cut infra costs 40% at 4M MAU
- Platgarden CTO: edtech exit experience
AIDatabaseGoWebRTC
"The execution infrastructure I built for Agent OS is now becoming transaction infrastructure for agents."
15 · Raise
From demo flows
to repeat transactions in real apps
With a $1M pre-seed, we will make the path from agent app calls to payment and records usable in real apps.
$1M Pre-Seed
$1M
Raise
18 months
Product runway
10
Initial integrated apps
Productize transaction path
Wallet policy and app integrations
Record lookup and settlement prep
Milestone: complete a repeatable request -> payment -> execution record flow across 10 apps.
An Open Transaction Network
for Agent Commerce
for Agent Commerce
In the era of agent-driven commerce, MeshKit carries the transaction all the way through.
Jaegyu Lee · jaegyu.lee@meshkit.dev
Appendix · Trust model
Execution stays in the app.
Records stay verifiable.
Off-chain Execution
- Real actions such as orders, bookings, and note saves execute inside the app
- Sensitive data stays in the app environment
- The LLM interprets intent; the app owns the result
- Wallet policy checks permissions, budget, and expiry
Off-chain Receipt
- Execution records are stored as off-chain logs and app-signed receipts
- Includes caller, capability, payload hash, nonce, and timestamp
- Requests and results are signed together to prevent replay and spoofing
- Lookup tools, settlement, and dispute handling use the same receipt
On-chain Anchor
- Only request hash, receipt hash, and payment transaction are anchored
- Policy ID and settlement state are linked together
- Sensitive data is not posted; only verification references remain
- App-signed receipts are checked against on-chain anchors to verify execution
Appendix · Mobile MCP
App capabilities are discovered locally
and called safely app-to-app.
Service SDK
- Each service exposes executable capabilities as MCP tools through the SDK
- Apps declare owned functions such as order creation, booking changes, and note saves
- Permission scope and input schema are provided together
- Apps receive explicit function calls instead of screen manipulation
Local MCP Server
- A local MCP server inside the mobile OS performs tool discovery
- The agent finds required app functions through the local server
- Request, permission check, and execution result stay on the device path
- The attack surface is reduced by not exposing every app function to external servers
MeshKit App-to-App
- MeshKit standardizes app-to-app MCP transaction paths
- Wallet policy checks amount, permissions, and limits before execution
- The app signs the execution result as a receipt
- Local execution is connected to verifiable records for safe mobile operation