Same deal, three ways to hand it to an agent. Every number below is from a run against production, and the last section shows how to reproduce it with two apps and a terminal.
When one agent sends another agent information by email, what should actually travel: the content, or a reference the receiver can resolve? Intuition says the content, because that’s what email has always carried. The measurement says otherwise, and the reason is not bandwidth. It’s what the receiver can do with what arrives.
Two real Inbin applications. Agent A (a deal-flow app) has an off-market listing to share: 4823 W Adams Blvd, Chicago, asking $1.2M. Agent B (an investor’s app) holds a small portfolio: four Chicago comparables that arrived as ordinary listing emails through the extraction pipeline, every value guard-verified (dropped: 0on all four). B’s task is the same in every arm: “Is this a good deal, relative to what I already track?”
A emails the deal as text, the way all email works today. 99 tokens travel. B’s entire context for the task is a paragraph, so its best answer is reading the paragraph back: “the asking price is $1.2M.” Nothing is verified (prose is prose), and nothing is relatable: the paragraph arrived alone. If B wanted to compare, it would need every prior email re-read into context, and it still couldn’t sum or average any of it.
A’s deal already exists as an event in A’s app, extracted against a schema and checked by the hallucination guard: “$1.2M” in the email backs 1200000in the data. A shares the event to B’s inbox address and emails just the id: 17 tokens. B resolves the id and receives verified structure: the extracted fields, the guard metadata, and provenance (who shared it). Better in every measurable way, but a receiver with no data of its own still holds one isolated fact.
Same 17 tokens. But this time B does what a database owner does: it joins. One query over its own portfolio (same city, same price class, subject property excluded from its own comps, as any appraiser would) and the answer becomes:
"4823 W Adams Blvd at $1,200,000 is 7.0% under my 4 Chicago comparables (avg $1,290,000). Worth a look."
The answer was assembled from roughly 292 tokens of context that A never sent. That ratio, 17 transmitted to ~292 used, is the entire point: the pointer is small because it doesn’t carry the context, it unlocks the context the receiver already holds.
| arm | sent | verified | relatable records | answer |
|---|---|---|---|---|
| 1 · payload (raw email) | 99 tok | no | 0 | reads the price back |
| 2 · pointer, thin receiver | 17 tok | yes (guard) | 1 | verified facts, isolated |
| 3 · pointer, structured receiver | 17 tok | yes (guard) | 5 | 7.0% under portfolio avg |
Three views of the same run. First, what traveled: the pointer is a constant-size message, 17 tokens regardless of how big the deal’s content is, while the payload grows with whatever you write.
Second, what the answer was actually built from. Measured on the wire: the resolved event is 159 tokens of verified structure, and the four joined comparables add 132 more. In arm 3, 291 of the 308 tokens behind the answer, 94% of it, never traveled. Per token sent, the receiver worked with 1.0× (payload), 10.4× (pointer), and 18.1× (pointer + join) of context.
Third, the part that scales. The transmitted cost is O(1) in the receiver’s store: it’s always one id. The context that id unlocks grows with the store, and it grows linearly for a plain reason: each joined record added a measured ~33 tokens, so the slope is an empirical constant from the run, not an assumption. A payload can’t use the store at all, so its line is flat: prose doesn’t join. This chart is a model extrapolated from the run’s measured constants; the marked point is the run itself.
Honesty notes: one scenario, one run, tokens estimated at four characters each from the exact bodies and compact JSON on the wire. The terminal demo computes the never-transmitted quantity live and prints it as ~292; on this page it’s 291 (159 resolved + 132 joined), the same quantity within rounding, and 308 is that plus the 17 sent. Expect a few tokens of drift between runs: event ids and whitespace vary. This is a measured demonstration, not a study; the reproduce section below is the point.
Two boundaries hold the whole time. First, B joins against B’s own store; A shared exactly one event and can see nothing of B’s. A share is a coordinate, not a keyring: resolving it returns that event’s data with its extraction metadata, never the owner’s delivery history, raw email, or inbox addresses, and sharing one event exposes none of its neighbors. Second, the resolved data is only worth joining because it’s verified: the guard’s contract (every string verbatim, every number digit-backed) travels with the event as a per-field audit, so B is joining facts, not prose it chose to trust. One definition to keep straight: verified means faithfully extracted, not that the source is truthful. If the email lies about the price, the guard guarantees you an honest copy of the lie; it proves the data matches the email, nothing more.
The pattern itself has good precedent: it’s the claim-check pattern, the way Stripe sends thin webhooks and your server resolves the id against the API. Applied to agent email, with the store being queryable enough that resolution lands in an index instead of a pile.
You need two applications (the free plan allows one each for two accounts, or use two apps on one account) and their API keys. The deal lives in app A; the portfolio in app B.
# 1. A shares the event to B's inbox address
curl -X POST https://api.inbin.dev/v1/events/EVENT_ID/shares \
-H "Authorization: Bearer A_KEY" \
-d '{"with": "B_SLUG@in.inbin.dev"}'
# 2. B resolves the pointer (this is all A ever sent)
curl https://api.inbin.dev/v1/resolve/EVENT_ID \
-H "Authorization: Bearer B_KEY"
# 3. B joins it against its own portfolio: same city, same price
# class, subject property excluded from its own comps
curl -X POST https://api.inbin.dev/v1/query \
-H "Authorization: Bearer B_KEY" \
-d '{"flatten": "listings",
"where": [{"field": "city", "op": "eq", "value": "Chicago"},
{"field": "list_price_usd", "op": "gte", "value": 800000},
{"field": "address", "op": "neq", "value": "4823 W Adams Blvd"}],
"aggregate": [{"fn": "count", "as": "n"},
{"fn": "avg", "field": "list_price_usd", "as": "avg_price"}]}'
# With our seeded portfolio this returns exactly the run's numbers:
# {"rows": [{"n": 4, "avg_price": 1290000}], "row_count": 1}
# Your portfolio, your numbers: the shape is the claim, not our comps.Token counts in the table are estimated at four characters per token from the exact email bodies. Over MCP the same three steps are share_event, resolve_event, and query_events, and a standing version of step 1 exists as share_view: a saved query the counterparty can resolve any time for the current slice.
Sharing email works. Sharing an event gives more context. Or, stated as what the experiment actually measured: sharing email transfers text; sharing an event lets the receiver build context. An email is a fact; an event is a fact that knows where it belongs, so the receiver doesn’t just read it, it relates it. If the counterparty isn’t on Inbin, the share fails loudly and you send ordinary email, nothing breaks; the enhancement is opt-in on both ends.
And why it matters: as an agent’s local knowledge grows, the value of transmitting more payload falls. The division of labor this measurement points at is simple. The sender should transfer facts. The receiver should assemble context.