# Concept - Gift Graph - Consent-Gated Context Between Agents **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: 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: verbatim ("he wants a license for Söhne"), category ("he is into typography and font licensing"), vibe ("something design-related and craft-oriented"), and silent (the data shapes recommendations but 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: 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, so the operator learns nothing useful from the store alone. A disclosure engine that rewrites a fragment down to its tier before it leaves the server, rather than trusting the receiving agent 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, so that "something design-related" cannot be triangulated back to "he mentioned a font on Tuesday." Tombstones for revocation and for marking a hint as bought, built on private set intersection so a hint can be invalidated without either side revealing purchase history. A v0.1 is a weekend of work: drop and pull with tiers, a local server, 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 not a quote but 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, so the measure of the system is not privacy alone but 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. In every case the primitives are identical: 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, with the same three measures: tier comprehension, recommendation quality by tier, and inference leakage under adversarial prompting. Only then the business pilot, 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. **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.