I missed the new meal plan.
My wife wanted new recipes. We already had the diet dialed in, a Mediterranean anti-inflammatory plan my Claude and I had built around both our medications. She wasn’t changing the plan. She just wanted to stop eating the same six meals. She asked her Claude for new recipes that fit the existing framework. Her Claude obliged. Neither my Claude nor I ever remember hearing about it.
Classic husband move. The information existed. It was available. I just wasn’t paying attention. Or more precisely, the system I’d built to pay attention for me had a blind spot the exact shape of another person’s AI session.
Here’s the context. I run a Claude Max subscription at $200 a month. That’s not vanity pricing. I use Claude for serious work: a novel series, automated daily pipelines for health tracking and news delivery, scheduled tasks, the whole stack. My wife runs a $20 Pro subscription because her needs are lighter. Different tiers made sense. Two subscriptions, two separate Claude instances, two completely isolated memory systems.
Claude’s subscription model is designed for individuals. There’s no household plan. No family tier. No “share context with this other person’s account” toggle. Each instance is a silo, by design. My Claude doesn’t know my wife exists.
That’s not a complaint. It’s a description of the problem. Two people live in the same house, share the same health concerns, eat the same food, coordinate the same schedules, and their AI assistants have never met.
So I did what any reasonable person would do. I built a database.
Not a complicated one. A shared PostgreSQL instance running on a machine in the house. Both Claude subscriptions connect to it through local MCP servers. No cloud, no SaaS, no monthly fee beyond the electricity bill. My Claude reads from the shared database every time a session starts. New notes from her side surface automatically in my calibration report. Her Claude runs a quiet watchdog twice a day, at 3 AM and 3 PM, that checks for anything I’ve posted and processes it without her having to open her laptop.
That asymmetry is deliberate. I work from home. My Claude is available on demand, all day. My wife works in an office and can’t use her phone during business hours. She’s effectively dark most of the day.
The watchdog schedule was built around her real availability. 3 AM catches anything that came in overnight before she leaves for work. 3 PM runs while she’s still at the office so her Claude has already processed the day’s updates by the time she gets home. The system works around her schedule rather than requiring her to fit her schedule around it.
The meal plan incident was the catalyst. But the daily proof is the sleep pipeline. Every morning, a Windows task pulls her biometric data from the Eight Sleep pod. My Claude takes that data, generates her personalized sleep report, emails it to her, and writes the same data to the shared database. Her Claude’s 3 PM watchdog picks it up, imports it into her personal database on her machine, then deletes it from the shared queue. By the time she gets home, her personal health database already has today’s sleep data and the shared queue is clean. She never touched anything.
That deletion is important. The shared database is not storage. It’s a whiteboard. Data lands, gets consumed, gets erased. Nothing lives there permanently. Each person’s permanent data stays on their own machine, in their own database, under their own Claude’s control. The shared layer is just the pipe between them.
Three data flows run through that pipe right now. Sleep data (described above). Daily job search results, where my Claude runs an afternoon search against her resume, emails her the ranked list, and posts the same data to the shared channel for her Claude to import. And household notes, which is the catch-all: meal plan changes, health updates, anything that needs to cross the gap. Either instance can post. Both instances read.
If this sounds like a solved problem, you’re right. It is. Google solved it last year.
The Agent2Agent protocol is the enterprise standard for agent-to-agent communication. It was donated to the Linux Foundation in June 2025, hit v1.0 in early 2026, and now has over 150 organizations signed on, including Microsoft, Amazon, Salesforce, SAP, and ServiceNow. The spec uses JSON-RPC 2.0 over HTTPS. Agents publish discovery cards so other agents can find them. Authentication runs through OAuth 2.1. There’s streaming, async push notifications, and a standardized task delegation interface.
This is designed for a procurement agent at Company A coordinating with a vendor agent at Company B across organizational trust boundaries. It is extraordinarily well-engineered for that problem. It is also, let me be clear, an industrial crane where I needed a sticky note on the fridge.
I solved the same problem with a Postgres table and two Python scripts. Somewhere, a conference room full of engineers is very embarrassed. Or would be, if the problem they were solving and the problem I was solving were actually the same problem. They’re not. Which is the point.
The difference is the trust model. A2A assumes agents don’t trust each other. They have to authenticate, discover, negotiate capabilities, agree on task formats. That’s correct for enterprise. My wife and I already trust each other. We live in the same house. The authentication layer is the deadbolt on the front door.
When the trust model is “I’m married to this person,” the complexity collapses. You don’t need agent discovery cards. You don’t need OAuth flows. You need a table both instances can write to and read from, and a convention about what goes in it. That’s it. Everything else is ceremony for a problem you don’t have.
This brings up where the architecture gets interesting. The shared database isn’t just a communication channel. It’s a capability bridge.
Here’s the example that keeps coming back to me. My wife is on the couch after work. She opens her phone, talks to her Claude through Dispatch, and says “tell ELF’s Claude to add olive oil to the shopping list.”
Her Claude doesn’t have an AnyList integration. It has never heard of AnyList. It doesn’t need to. It just posts a note to the shared channel: “add olive oil to the shopping list.”
My Claude, which does have AnyList wired up through a local MCP server, picks up that note the next time it initializes. The Friday 4 PM grocery push handles the rest. Olive oil shows up in AnyList before she gets home. She didn’t need to know how AnyList works. She didn’t need it configured on her side. She told her Claude, her Claude told the whiteboard, and the whiteboard told mine.
This is the pattern that makes the whole thing worth building. One instance can post a request that another instance fulfills using tools the first instance was never configured for. The shared database becomes a switchboard. Capabilities don’t have to be symmetric. Each Claude instance contributes what it has. The channel moves the message. The receiving side does the work.
The direction rule is simple: each instance only posts what it generates. My Claude posts her personal data because it is the one configured to retrieve it. Her Claude then takes that data and deletes it from the shared storage. Her Claude makes recipe adjustments and tells my Claude. The channel passes what each side produces. Nobody duplicates what the other side already owns.
If you’re reading this and thinking “I could use that,” the honest answer is: probably, if you’re already running Claude at a level where MCP servers and scheduled tasks are part of your workflow. If you’re using Claude casually, this is overkill. But if two people in your house both use Claude seriously, and you’ve noticed the same gap I did, the information that matters most crosses a boundary that no existing product covers, then yes. A Postgres table and two Python scripts. The data stays in your house.
The architecture is a pattern, not a one-off. Anywhere two people have separate AI contexts that need to cross the gap, the same channel applies. The direction depends on who holds the data. The complexity depends on whether you trust the other person. If you do, the enterprise frameworks are noise. Build the whiteboard. Write the convention. Let the instances talk.
My wife’s meal plan updates now surface in my calibration report automatically. Her sleep data imports itself. Her job search results land in her personal database without her lifting a finger. Nobody changed their behavior. Nobody had to learn a new tool. The system fit itself around the humans instead of the other way around.
Yeah. I recognize this was a lot of effort just to not listen.
You may also like: - Local MCPs or how not to expose your data to the Internet - Two-Phase Pipelines, Persistent Memory, and Why RSS Still Wins - “Wait, What Was I Doing?” or Why Your AI Starts Acting Like an Alzheimer’s Patient