# Concept - Gift Graph - Consent-Gated Context Between Agents *First explored 2026-02-15 in a Claude chat, as initial ideation and a feasibility check · written up here 2026-09-01 · built from 2026-09-30 ([[Gift Graph Product Log]])* **The problem:** My partner has been telling his Claude which typefaces he wants licenses for. Someday I will ask my Claude what to get him. Today those two conversations cannot meet, and the only bridge is the oldest one: he curates a wishlist, or I go fishing. Both defeat the point of a gift. The general form of the problem is bigger than presents. Personal agents are accumulating rich context about the people who use them, and there is no consent-shaped way for one agent to lend a sliver of that context to another. Every current answer is total (share the account) or nothing. The interesting design space is the middle, where one party lends context, the other party's agent uses it only when asked, and neither side sees more than they agreed to. **The shape:** A single MCP server that sits between two personal agents, keyed per pairing. His agent calls `drop_hint` with a fragment, a category, a confidence, and a disclosure tier. My agent calls `get_gift_context` when I ask about gifts, and the server returns only what the tiers allow. Four tiers do the work, running from verbatim ("he wants a license for Söhne") through category ("he is into typography and font licensing") and vibe ("something design-related and craft-oriented") down to silent, where the data shapes recommendations and is never quoted or attributed. He sets a default tier and can flag individual drops surprise-safe, meaning never reveal even if I ask directly. Notification is his dial too, set to push (rare, opt in), passive (my agent simply knows more when asked), or seasonal (a nudge before a birthday, only if he enabled it). That last piece makes the design asymmetric, and the asymmetry is the feature: I do not need to know he shared anything. ![[gift-graph-architecture.png]] **Technical scoping:** A consent registry (pairing code, mutual opt in, unilateral revocation at any time). A drop store with fragments encrypted per pair, which leaves the operator nothing useful in the store alone. A disclosure engine that rewrites a fragment down to its tier before it leaves the server; the receiving agent is never trusted to be discreet. An anti-inference batcher, the part I care about most: a 48-hour release delay, a three-drop minimum per category before anything at category or vibe tier is served, and jitter on top, which keeps "something design-related" from being triangulated back to "he mentioned a font on Tuesday." Tombstones for revocation and for marking a hint as bought, built on private set intersection, letting a hint be invalidated without either side revealing purchase history. A v0.1 is a weekend of work, covering drop and pull with tiers, a local server, and two Claude clients. Payments, PSI, and the seasonal trigger are v0.2 and later. **Security and efficacy:** The threat model has three actors. The pair themselves, where the risk is over-disclosure, handled by tiers, surprise-safe flags, and the veto: nothing is bought, sent, or revealed without the owner of that side. The server operator, where the risk is a honeypot of intimate preferences, handled by per-pair encryption and a store that holds tier-reduced fragments only. And the receiving agent, where the risk is leakage through cleverness, handled by doing the reduction server-side and by the batcher, because the most dangerous leak is a timestamp. Efficacy is the harder half. A hint at vibe tier is only useful if the receiving agent can turn it into a good recommendation. The system is measured on privacy and on recommendation quality at each tier, the curve between how little I know and how well I choose. The link to [[Thesis - Current tools are lossy membranes|lossy membranes]] is direct. This is a membrane designed to be lossy on purpose, with the loss set by the person on the far side. **Beyond the consumer case:** The couple is the smallest instance of a pattern enterprises already ache for. A customer's support agent lending an operational fragment to a vendor's agent at category tier ("the outage cluster is in their EU region") without exposing the ticket, the customer, or the runbook, which is the [[Pylon Case Study|B2B support]] problem with the walls kept up on purpose. Procurement agents sharing budget vibe without sharing the number. Care coordination where one system's agent lends a patient's context to another at the tier the patient chose, which is the version of [[Kaiser Permanente Case Study|regulated data sharing]] that HIPAA has been waiting for someone to make legible. Every case runs on the same primitives of pairing consent, tiered reduction, anti-inference timing, revocation, and a human veto on both ends. The consumer version is the cheapest place to learn whether the tiers are understandable, which is the whole reason to start there. **Prototyping and testing:** Start with the pair I have. My partner and I run v0.1 for one gift cycle, and the questions are specific. Can he set a tier without reading documentation, and does he understand what each tier lets through? Does my agent produce a better idea at vibe tier than I would have found alone, and how does that change at category tier? Can either of us triangulate what the other dropped, which I will red-team against my own agent. After one cycle, five to ten pairs, friends and family who already gift each other, measured the same three ways, by tier comprehension, recommendation quality by tier, and inference leakage under adversarial prompting. Only then comes the business pilot, with one vendor and one customer support team who already share context badly over email, and the measure there is whether tier-reduced context resolved a real ticket faster than the wall did. This is [[Thesis - Ship Probes, Not Monoliths|probes over monoliths]] applied to itself: v0.1 exists to find out whether four tiers are three too many. **Built:** v0.1 was built with Replit Agent from this spec on September 30, 2026, and driven from Claude Code as both users the next morning. Production runs [[Gift Graph Product Log|{version}]] today. The build, the decisions, and what the live server taught me are in [[Gift Graph Product Log]]; the platform gets its own read in [[Replit Case Study]]. **Where it sits:** [[UX - Webapps in an MCP World|If agents are becoming the users]], what one agent may tell another becomes the consent question of the decade, and [[UX - Controls Near the Consequence|the control belongs next to the consequence]]: the person whose context moves is the person who holds the dial. I decided against patenting any of this. Publishing the spec is the cheaper protection and the better use of the idea.