Jul 23, 2026

Why Your Agents Are (Should Be) Keeping Secrets From Each Other

Hi! It's been a while.My advisor says a paper is done when you would rather do anything than open the file again. By that measure I finished two: one on delegated play, one on the economics of ideas. The first is on arXiv now; the second will be by the end of the month. When I told him, he asked (warmly ... I hope!) whether the blog had died.Thanks for reading! Subscribe for free to receive new posts and support my work.It had not. It was defrosting. And it's back!The agents did not take the hiatus off. Dube International runs agents for two companies selling into adjacent markets. One shared model drafts outreach for both, from the same skill library and the same memory. In a year when every vendor demo ships with an agent, ours holds down two jobs, no benefits, no complaints.It's an appealing idea. Every correction a human makes to one client's agent improves the model that runs all of them. However, it is also a data leak. For a correction on the first account to help the second, something has to cross the boundary between them. The question I keep returning to is what crosses, and what never does.What actually crossesThe production pattern is dual-tier memory. Each agent keeps private fragments, local to its deployment. A shared tier holds the fragments that cross agents, each carrying immutable provenance. MIRIX, published in July 2025, splits memory into six components and enforces access control across them rather than treating memory as one store. Each component forces the same question: what may leave the agent.The Vault is the strictest tier. Relevance does not move it. Access control there is not a filter run after retrieval; it is a property of the store. (For those keeping up with Silicon Valley, this is also the description of what a Claw looks like. In the past, we've done an overview of the context engineering behind OpenClaw).Most of what an agent knows is not allowed to leave. The draft it wrote, the account it targeted, the reply it got: private. What we promote to the shared tier is never the message a human fixed. It is the judgment the fix implies, stripped of the content that occasioned it.Take a case. A reviewer rewrites an agent's draft to an owner-operated transport company, cutting a paragraph that assumed the owner had a dispatcher. The private fragment is the draft and the account. The shared fragment is smaller and duller: do not assume staffing you have not observed. Dull is the point; dull generalizes, and a lesson with no client attached is a lesson you can reuse. Its provenance points at the correction event, not the client record. The second client's agent never sees the first client's message. It inherits the judgment the message earned.Procedural memory is the cleanest case. LEGOMem, from October 2025, treats corrected skills as modular units that transfer across a multi-agent pipeline. A skill is already content-free (very loaded word, maybe someday we will discuss further); it is a way of doing a thing, not a thing that happened to a client. When the unit you share is a skill and not a record, the boundary holds without anyone watching it.Provenance turns this from hopeful into auditable. Temporal knowledge-graph systems such as Zep attach time and source to every fact, so a shared judgment traces back to the human decision that produced it without dragging the private data along. That trail is also the reward signal. A correction is worth propagating only if you can find out later which corrections propagated well.Links are not boundariesThe provenance trail needs somewhere to live, and the field has mostly converged on a shape. Google's Open Knowledge Format is the cleanest statement of it, standing in for a family of flat, file-based knowledge stores: markdown files, YAML frontmatter for metadata, and a graph implied by the links between documents. A single file looks like this:--- id: acme-q3-forecast type: analysis author: t.dube created: 2026-07-19 sources: [acme-crm-export, acme-call-notes] --- The Q3 pipeline weakened after the pricing change. See [the pricing decision](./acme-pricing-change.md) for the trigger. The metadata sits in the frontmatter, the body carries the claim, and the link to acme-pricing-change.md is the edge in the graph. It wins for reasons that hold: the files are human-readable and portable, they need no database, and the graph costs nothing because a link is one line. A reviewer can read a fragment, and so can grep.What the format cannot do is hold the boundary. A link says two documents are related, not which of them may cross to a competitor's agent. The tier a fragment belongs to is a field in the YAML, and a field is a convention. Nothing in the format stops a retrieval step from reading a private fragment and promoting it; the convention holds only as long as every reader honors it. That is the failure we started with, moved down one layer. A filter applied after retrieval is not access control, because the data has already been read.Picture a shared office with one filing cabinet and no locks. Every folder wears a sticker. Some say SHARED. Some say PRIVATE, ACME ONLY. The system works as long as everyone who opens the drawer reads the sticker and obeys it. Then the office hires a temp who is fast, tireless, and does not read stickers, and the cabinet has no opinion about that. A sticker is not a lock. It is a request. The tier field in the YAML is that sticker, and a retrieval pipeline is the temp: it opens folders thousands of times a day, by relevance, at speed, with no one watching.Here is the failure in motion. Client A's agent holds a private fragment:Acme is cutting prices 15 percent in Q3, stop leading with premium positioning. A query from client B's agent, selling into the same market, matches it, and of course it does; the fragments that score highest across competitors are exactly the ones about the market they share. The retrieval step reads it, the model folds it into a draft, and client B's outreach lands in a prospect's inbox knowing something only client A told anyone.No one decided to leak it. Every component did its job, which is the unsettling part. If you run agents for two competitors, sit with that email: it reads like it was written by someone who has seen your other client's books, because in every way that matters, it was. That is not an edge case. It is the default behavior of a store that keeps the boundary in metadata.The problem is mechanism design, not storage. I cannot audit every retrieval, the same way I cannot read every draft before it sends. A boundary that holds only when each reader chooses to honor it is not a boundary. It is an agreement, and an agreement among readers is the thing I am trying not to depend on. The mechanism-design question is narrow: build the store so the leak is not an event you catch but a state the store cannot represent. Not a rule with a penalty. A move the board does not accept.The answer I have settled on is a typed hypergraph.What is a typed hypergraph?Start with the graph you already know from the OKF example: notes on a corkboard, string between pairs. One string, one relation, two things. The forecast cites the pricing change. That works until you try to pin up a promotion, which is not a pair. A promotion is one event with four parts that only mean anything together: the judgment being shared, the correction that produced it, the human who signed it, and the tier it may enter. String those up pairwise and the event shatters into four separate strings that nothing holds together. Pull one and the others do not notice. Two years later the judgment is still in the store, the signature has drifted three links away, and a client asking who approved the thing their competitor's agent learned gets a reconstruction instead of an answer.A hypergraph fixes the geometry. A hyperedge is one string that loops through all four notes and binds them into a single fact, which exists whole or not at all.Typed is the word with teeth. Nodes carry types: judgment, content, correction event, client, agent. Edges carry types too, and a type is not a label. -- Easy way to think about this? Types just give nodes and edges a meaning, it's like having color-coded strings and pins, and the colors mean something :PIt is a rule the store enforces, the way a database refuses to put a word in a number column. One promotion becomes one typed edge recording the judgment, the correction behind it, the human who signed it, and the tier it may enter. The tier stops being a YAML field and becomes a property of the edge.Rerun the pricing scenario in this store. The Acme fragment is a content node, typed private. Client B's query matches it, the retrieval reaches for the node, and the store refuses before anything is returned. There is no draft with the leak in it, no filter to check, no incident to write up, because the leaking retrieval was never a thing the store could express. It is a type error. If the boundary between clients lives anywhere a reader can decline to check it, I do not have a boundary, I have a hope with a schema. The office threw out the stickers and welded a wall through the cabinet.Why a hypergraph, and why not. The case for it is above, one line per row. The case against it is real, and worth stating before you buy the database:The honest answer to "why not a hypergraph" is that most of the time you should not. If every agent sits inside one trust boundary, you have no boundary to enforce, and the flat store hands you a 30 percent gain with none of this overhead: greppable, database-free, readable by a human on a bad day. The hypergraph is not the better store in general. It is the store you switch to the moment a leak across clients becomes possible, because that is the moment the graph stops being free anyway. You pay for the boundary either way. The only question is whether you pay in schema or in incidents.When to sync, and how you would knowSharing is neither free nor instant. Recent work on distributed agents has measured the tradeoff: long-term memory costs more but improves accuracy. Memory is a line item. For latency-sensitive work, use distributed shared memory with periodic sync: agents run on local state to stay fast, and reconcile against shared state on a slower loop to stay correct. MemGraphRAG uses a global knowledge-graph layer for this, keeping cross-agent answers consistent on the multi-hop queries that naive retrieval gets wrong. In our version the agent drafts from private memory in real time, and promotion to the shared tier happens off the hot path, gated the way outputs are gated. LangGraph implements the gate as an interrupt, a human checkpoint before state commits. A bad draft costs one send; a bad shared judgment costs every agent that later retrieves it.Measurement is the part the field has not solved.What resists scoring is that last row: the value of a shared fragment before it has fired anywhere. Contribution attribution traces which agent's correction improved which other agent's result, and is becoming a standard metric for that reason. The cross-client improvement stays invisible until you instrument it. I can claim it when I can point to the specific correction from the first client that raised the auto-approve rate on the second, and not before.TL;DR: The unit you shareKeep two tiers. The private tier holds everything that happened; the shared tier holds only what it taught you. Content identifies and judgment generalizes, so promote the lesson and leave the case file where it lives. Staple a provenance trail to every shared fragment so you can name the human who approved it, ideally before a client asks.Store it in a typed graph, not a flat pile of markdown with a PRIVATE sticker in the frontmatter. A sticker is a request, and your retrieval pipeline is a temp who does not read requests. In a flat store, access control is a promise every reader has to keep, which means it is not access control. In a typed store, a leaking retrieval is a type error the store refuses before it returns anything. Build the boundary into the types, or accept that what you have is a hope with a schema.Thank you for reading, pls subscribe if you haven't, tell your friends, families, neighbours, and nemeses; and I'll see you soon!!

May 20, 2026

WTF are Robotics Foundation Models!?

In 1966, a professor at MIT assigned a student a summer project: solve computer vision. One student. One summer. Solve seeing. Fifty years later, we were still working on it.What finally cracked vision was not careful engineering. It was throwing enormous amounts of data at a neural network and watching what happened. That worked so well we spent the next decade doing the same thing for language, then code, then images, then video.Now we are doing it for bodies.In 2026, the labs are training foundation models on robot data. Arms, legs, wheels, logged at millions of hours. Then they pour the trained models into physical machines. Figure's humanoids are working factory lines. Google's arms generalize to kitchens they have never seen. Tesla's Optimus walks, with some generosity, upright. The method is the same method that cracked language. Ignore the domain experts, pour in data, let the model figure it out. It is working.We are not far from the moment when a robot in your house is cheaper than a dishwasher and more useful than one.A robotics foundation model is not a robot that thinksHere is what everyone pictures: a brain in a metal body, reasoning about the world, deciding to pick up the cup.That is not what this is.A robotics foundation model is one neural network trained on the logged sensor readings and motor commands of many different robots, doing many different tasks. It takes in what the robot sees and the instruction it was given. It predicts the next action. Then the next one. The way a language model predicts the next token, this predicts the next motor command. There is no separate reasoning module. There is one network and a very large pile of other robots' experience.The interesting word in that sentence is "different." Older robot learning trained one policy per robot per task. A model that could open a specific drawer on a specific arm in a specific lab. Move the drawer, retrain. Change the arm, retrain. The robot was a craft object, hand-tuned, and the tuning did not transfer.The thing everyone gets wrong is which part is hard. People assume the bottleneck is the body. Actuators, torque, hands, batteries, the wet mechanical reality of touching the world. Hardware is genuinely hard. But hardware is not what stalled this field for thirty years. What stalled it is the same thing that stalled language before the data era: there was no way to learn something general from a pile of narrow, incompatible examples. Every robot's data was an island.The shift is that the data stopped being islands. Pool the logs from many robots and many labs into one training set, train one model on all of it, and the model gets better at every robot at once, including ones it was barely trained on. The body is now the easy part. The dataset is the moat. This is the same lesson "WTF is Context Engineering!?" landed for language, arriving in robotics about three years late.Finding 1: one model on many robots beats specialists at their own tasksThe cleanest evidence is the Open X-Embodiment project. Thirty-four robotics labs pooled their data into one set: more than a million robot trajectories, 22 distinct robot types, hundreds of distinct skills. Then a single model, RT-X, was trained on the pile.The specialist robots were the control group. Each had a hand-tuned policy, trained only on its own data, by the people who built it. RT-X, trained on everyone's data at once, beat those specialists at their own tasks by roughly 50 percent on average. Skills also transferred across bodies: a behavior present in one robot's data showed up on a different robot that had never performed it.Read that twice. The generalist did not win because it was cleverer. It won because it had seen more bodies do more things, and structure that looks specific to one robot turns out to be mostly shared.Finding 2: the scaling curve bends the same way it did for languageThe second finding is less a single result and more a shape. Across vision-language-action models, including Physical Intelligence's pi-zero and Google's RT-2 line, the relationship holds: more diverse robot data plus a bigger model produces better generalization, and it keeps producing it as you add more. No plateau yet. The curve looks like the language curve looked in 2020, before anyone believed it would keep going.There is a second-order effect that makes this stranger. RT-2 was trained on web images and text alongside robot trajectories. It inherited concepts it never saw a robot do. Ask it to move an object toward "the extinct animal" and it picks the toy dinosaur, because the language half of the model knows what extinct means and the action half just has to point the arm. The robot benefits from data that was never about robots. That is the entire foundation-model bet, now closing a loop through a physical arm.This matters because it converts robotics from a research problem into a logistics problem. If performance is a predictable function of data and scale, you do not need a conceptual breakthrough. You need a fleet, the pipes to log it, simulation to cover the cheap cases, and the compute to train on the pile. Those are purchase orders, not insights. Insights are hard to schedule. Purchase orders have lead times.Finding 3: the data now comes from deployment, not demosThe flywheel only spins if real robots are running real hours. They are. Figure put humanoids on a commercial automotive line, doing repetitive material handling, on shift, not in a demo booth. The relevant number is not the polish of the demo video. It is that every deployed unit logs operating hours on a real task, those hours become labeled training data for free, the next model trains on them, and the next model is the one that ships back to the same units overnight. The robot is collecting the dataset that trains its own replacement, and the replacement arrives as a software update.This is why the company with the mediocre robot and the deployed fleet beats the company with the brilliant robot and the lab. One of them has a dataset that compounds weekly. The other has a paper. That loop did not exist in 2022. It is the single biggest change in the field, and it is almost invisible from the outside because it looks like nothing. It looks like a robot doing a boring job, badly, on purpose, while logging."Robots are nothing like LLMs"The strongest objection, and a serious one: language is discrete and the internet handed us trillions of free tokens. The physical world is continuous, every sample costs a motor cycle and a chance of breaking something, and a wrong token is a typo while a wrong torque is a snapped wrist. The analogy to language is seductive and the economics are not the same.All true. Robot data is orders of magnitude more expensive per useful sample than scraping text, and the failure modes are physical, not embarrassing.But the claim does not require internet scale. It requires that pooled, cross-body data keeps bending the curve, and the evidence so far says it does. You do not need every robot in the world. You need fleet scale, simulation to cover the cheap cases, and real deployment to cover the expensive ones. Language needed the whole internet because no one owned a corpus. Robotics companies own their fleets. The corpus is being manufactured on purpose, by the same machines that will consume it. Expensive is not the same as impossible. It is just a moat with a price tag, which is the most durable kind.What to actually doStop watching demo videos. A humanoid folding a shirt in a lab tells you almost nothing. The question that predicts who wins is boring: who is logging the most real operating hours across the most different bodies, and who owns that data when the contract ends. Watch fleets and data rights, not choreography.If you build anything physical, the strategic layer is no longer the controller. Controllers become a downloaded model, the way an operating system kernel became a thing you apt-get. The value moves to whoever owns the data pipeline and the safety contract around a model that now has actuators. Which is last post's argument with a body attached. A runtime with the keys to your files needed an immune system. A foundation model with the keys to a physical arm needs one more. "WTF is the OpenClaw Ecosystem!?" was about software agents without a trust layer. Bolt that argument onto a 30-kilogram machine moving at speed near a person and the missing contract layer stops being a CVE and starts being an incident report. That gap is the work we care about at Dube International, and it is the same gap, one domain over.My advisor asked, again, when I am going to stop writing about other people's robots and finish the category theory chapter. I told him robots are just functors from intention to motion and watched him decide whether that counted. It did not. It was worth a try.Here is the compression. For thirty years robotics was a craft, one robot at a time, and the craft did not transfer. The moment the data stopped being islands, the same boring recipe that ate vision and language started eating motion, and the only question left is who owns the dataset the robots are building for their own replacements.Next week: what we get wrong about what these models actually understand.See you next Wednesday 👋