A few days ago the Harness team at DeepSeek published a design essay on the Super-agent, along with an open-source prototype. Its main–worker architecture separates the entry point from the work, and in doing so it solved a problem we had been stuck on for a long time. Following that thread, I came to a conclusion: the potential this architecture unlocks has to be cashed in by the entry point's memory. The better the entry remembers, the further the agent can go. Today's context compaction can't carry that.
This post explains how we got there and what we plan to build. To keep it concrete, I'll use one example throughout. Wang runs a small export business. He has his own agent, and the company also has a sales agent and a customer-service agent. His biggest customer is Li, overseas. Let's start with where we went wrong before.
We used to make one session do everything
Before this platform, we built a product called Society on top of an open-source project, RoleX. RoleX tried to let agents live in something like a society: a persistent identity, organizations and positions, principles and skills distilled from experience, goals and knowledge that outlast a single conversation.
We put a lot of work into memory, including having the system push memories into the context on its own. In real use it always fell a little short. Take Wang. His agent knew a few things that mattered: Li prefers monthly settlement, the last quote fell through because of the exchange rate, and contract v3 is stuck with legal. We pushed those into the context. Then Wang said, "Send Li a new quote." The agent got to work: three old quotes, a long email from legal, an order sheet with a few hundred rows, several rounds of edits. All of it landed in the same context.
Once tens of thousands of words of detail poured in, those few relationships were still there, but buried. They were a sliver of the context, and the model's attention went to the spreadsheets and emails. Later the context filled up, the system compacted it, and half of the carefully built persona and relationships were gone. The next time Wang mentioned Li, the agent no longer remembered why it shouldn't quote in dollars.
Back then we thought memory just wasn't good enough yet. Reading DeepSeek's design, I realized the problem wasn't memory. It was structure: we had crammed several different kinds of memory into one place.
Human memory has layers; an agent puts everything in one window
Human memory isn't one warehouse but several systems that each do their own job. Sensory memory catches what you just saw or heard and lets it go in seconds. Working memory handles the task in front of you and holds only a few things at once. Long-term memory keeps people, events and how they connect, and surfaces them when needed.
Between these layers the brain keeps making choices for us: details fade from working memory once used, and what goes into long-term memory is mostly the gist and the relationships. After a day of meetings, Wang doesn't remember every sentence. He remembers that the contract went to legal because it exceeded the approval limit, and that Li was unhappy because of the exchange rate. He can only do one thing at a time, but his head doesn't fill up.
An agent has no such layers. Its context window is its sensory memory, working memory and long-term memory all at once, and it doesn't forget on its own: every row it read stays there until the window is full and gets compacted by force. Important relationships compete with trivial details. That's how the memories we pushed in got diluted.
DeepSeek's Super-agent happens to pull these layers apart.
The Super-agent splits memory into layers
The structure is a classic one. A long-running entry session receives and dispatches work and does none of it itself. Each concrete task goes to its own worker session, with a clean context and the full toolset, which hands its result back to the entry when it's done. People only ever talk to the entry.
Seen through memory, it lines up with the human layers. The raw material a worker reads and discards is sensory memory. A worker's context is the working memory for one task: when the task ends, the session ends and the details go with it, and only the result goes back. Because the entry does no work, its context no longer holds task details. What's left is who, what, why and where things stand, which is exactly what long-term memory should hold.
We built this into our own design. Every agent has a main session, one per person it serves; every other session is a worker the main session dispatches. When Wang says "Send Li a new quote," the main session no longer digs through spreadsheets and emails; it sends a worker. In the product, opening the agent is simply talking to it, and workers show up as tasks.
Someone will ask: we already had subagents. A main agent hands work to a subagent; isn't that the same split? Why does a session make the difference?
Sessions, not subagents: delegating versus managing
The difference is the relationship to the main session. A subagent is delegated to. A worker session is managed.
Hiring an outside agent is delegation: you hand the job over, get the result back, and the relationship ends. That's how most subagent designs work. Wang says "Send Li a new quote," the main agent calls a subagent and waits; the subagent reads the sheets, goes through the emails, revises the quote, returns a result and is done, and everything it saw is gone with it. The result lands, whole, in the main agent's context. The next day Wang says, "Change the shipping cost in the quote." That subagent no longer exists, so the main agent has to take it on itself: either do it, or brief a new subagent all over again on the quote, how it was calculated and what Li asked for. To brief it, all of that detail has to stay in the main agent's context.
Having your own team member do the work is management: they stay, they report to you, you know who is doing what and how far along it is, and follow-ups go straight to them. That's a worker session. The main session hands the quote to a worker and doesn't wait; it keeps receiving other requests. The quotes, the calculations and every round of edits stay with that worker. When Wang asks to change the shipping cost the next day, the message goes straight to the same worker, which already has all the detail. The main session only remembers one relationship: Li's quote, handed to which worker, now waiting on the shipping change.
There's another difference that's easy to miss: delegation is optional. DeepSeek ran a preliminary experiment on a simulated workload (we read it through AgentsPulse's write-up of the original). The Super-agent finished a batch of tasks in a median of 12.4 minutes. A single session with a subagent tool, under a neutral prompt, never called the subagent in any of five runs; it kept all the work and kept getting interrupted, with a median of 20.4 minutes. Told to prefer delegating, it delegated in four of five runs, but in one it decided the job was small and did it itself, and the slowest runs still took close to 30 minutes.
When delegation depends on the model choosing to do it, the division of labor is unreliable. In a main–worker structure the main session simply does no work, so tasks always go to the team, and the structure guarantees the split. And only a management relationship keeps the detail with the team member instead of flowing back to the main session.
So what the Super-agent separates isn't just tasks but a management relationship: details belong to the team, relationships belong to the main session. Once that's separated, the main session's situation changes completely.
For the first time, the main session can focus on remembering
First, memories pushed into the main session no longer get diluted. The quotes, the legal email and the order sheet stay in the workers; the main session's context holds only the history between Wang and Li. What we kept trying to do in RoleX, and kept losing to work detail, finally has a clean place to live.
Second, the more workers there are, the more relationships the main session has to keep. Wang has his agent quoting, chasing the contract and tidying up orders at the same time. Three results come back, and the main session has to know which result answers which request, how each relates to Li and to contract v3, and whether any two conflict. Only relationships can tie that together. The longer the agent is used and the more runs in parallel, the more relationships there are, and the more they matter.
Third, and most important, memory goes from competing with the work for space to being the main session's only job. Before, better memory was a nice extra, because what held the agent back was a crowded window. Now the window stays clear, and how well the main session remembers directly decides how far the agent can go.
To be honest, relational memory, ontology and phenomenon were ideas we already had in RoleX, and we built a version of them. They didn't pay off then not because the ideas were wrong, but because the structure got in the way: all memory squeezed into one window. DeepSeek's design removes exactly that blocker. With it gone, the rest follows naturally: keep relationships on their own, push them to the main session from its point of view, and tidy them up at the right moment. Things we had long wanted to do, and partly did, finally have somewhere to go.
DeepSeek's design focuses on how the entry receives and schedules work. How the entry keeps remembering over months is what we want to build next. The first question: the main session's own window is still finite and will have to be compacted. Can compaction do it?
Today's compaction can't keep a conversation going forever
Context windows are always finite, so the main session does need compaction: shorten what has happened to make room for what's next. The common approach is to turn a stretch of conversation into a summary.
A summary keeps what happened but struggles to keep how things relate: why this quote was in dollars, why this customer was unhappy last time, which discussion a conclusion came from. Summaries aren't connected to one another; each compaction blurs things a little more, until the agent is like someone who keeps losing their memory.
We can't keep everything, so we have to abstract. After a lot of back and forth, we concluded that what abstraction most needs to keep is relationships. Text can go, because it already lives where it came from: files in the file store, tickets in the ticket system, conversations in sessions. Once a relationship is lost, there's no getting it back.
So where should relationships live, and in what shape?
How we plan to store relationships: a graph
To store relationships, we went back to an idea from RoleX: Kant's distinction between the thing in itself (the noumenon) and the way it appears to someone (the phenomenon). We borrow the distinction: there is one world that all agents share, and each agent sees only the part reachable from where it stands. Unlike Kant's noumenon, ours is recorded by the platform, so it can be read and written. In software we call that shared graph an ontology. Let me make this concrete with Wang's company.
The ontology is the world as it is. In Wang's company, Wang, Li and the legal team are people; Wang's agent, the sales agent and the customer-service agent are agents; the quote and contract v3 are files; the contract approval is a ticket; each conversation is a session. They relate to each other: Wang owns the Li account, the quote came out of a particular session, contract v3 cites that quote, legal is reviewing contract v3. Draw all of those people and things and how they relate, and you have the company's ontology.
In our design it's just a graph, nothing special.¹ An organization has one ontology, and all of its people, agents and sessions sit in the same graph. Nodes are only references: the quote's content stays in the file, the approval stays in the ticket, and the graph just records that there is a quote. Everything else is on the edges: what kind of relationship it is, why it holds, which conversation it was learned from, when it became true, and how much to trust it. "Li prefers monthly settlement," for example, records that it came from the third call. When a new fact contradicts an old one, the old edge is marked invalid rather than deleted, so you can always see what was believed at the time.
Things with no matching entity on the platform, like "Li prefers monthly settlement," go into the graph as a generic memory.
But one graph shared by everyone raises the next question: do Wang's agent, the sales agent and the customer-service agent all see the whole graph?
The hard half: what each agent should see
No. If every agent saw the whole graph, it would be neither safe nor anything like memory. People don't remember that way.
I often use Steve Jobs and myself as an example. We live in the same world, but starting from me, Jobs is the man who made the iPhone; I watched his keynotes and read his biography. Starting from him, I'm probably not in his world at all. Same world, different starting point, different view. "I know him" and "he knows me" are two different things, and one can't stand in for the other.
That is the phenomenon: the world as seen from a particular place. In Wang's company, Wang's agent stands where Wang stands; it can see Li, the quote, contract v3 and the memory that Li prefers monthly settlement. The sales agent stands in the sales process; it sees contract v3, the approval ticket and legal. They meet at contract v3, so both know how the contract is going, but Wang's agent doesn't need every detail of the legal review, and the sales agent never sees what Wang and Li discussed privately.
A few rules decide what each agent sees. Start from your own position and follow relationships: one step is strong, two steps are weak, and it rarely goes past three. The more things a node connects to, the less attention each connection gets. Relationships fade over time and get stronger each time they're used. Only a few things are clear at once; the rest blur. We didn't make these up; we went to cognitive psychology's research on human memory: how associations spread, what the forgetting curve looks like, how many things a person can hold clearly at once. For now they're defaults that we'll tune on real data.
What you can't reach, you can't see, so the phenomenon carries its own boundaries. One kind of node needs special care: hubs. Wang's customer-service agent serves many customers. If we let a walk go from customer A through it to customer B, A would see B's business. So a hub is a stopping point: you can reach it, but you can't pass through it.
That answers what to store and what to see. What's left is when these relationships get tidied up, and when they reach the agent.
In the agent, we want it to remember the way people do
We broke it down into a few actions, modeled on how people remember.
First, sleep. Human memory gets organized during sleep: the day's experiences are recorded quickly, then replayed, distilled and connected to what you already know overnight. The moment most like sleep for an agent is when its context is nearly full and has to be compacted. So that's when we tidy up relationships: pull out the people and things in this stretch of conversation, match them to what's already in the graph, add what's new, invalidate what's outdated, and keep a pointer to where each relationship came from. Facts that connect to existing structure merge first; relationships unused for a long time slowly fade.
Then, things come to mind. When you walk into a meeting room, the relevant people and history surface by themselves; you don't first decide to recall them. Same for the agent: the part of the world visible from its position is put into its context by the system, and the agent doesn't have to look anything up.
Then, some things are clear and some are fuzzy. The more relevant, recent and important something is, the clearer it is: the most important few in full, the next ones as a gist, further out just a name and its relationships, further still only "there are a dozen more," and beyond that nothing for now. Not recalling something isn't the same as deleting it; the trace remains.
And when you really need to think harder, you go looking. When needed, the agent can "think a little deeper," like a person: follow one lead a step further and lower the threshold. Whatever gets recalled is remembered more firmly afterward.
Put these together and go back to what Wang said, and you can see what it means for the product.
What this means for the product
Back to "Send Li a new quote." The main session takes the request, recalls from its own point of view Li, the last quote, contract v3 stuck with legal and the monthly-settlement preference, then sends a worker to prepare the quote. It remembers all this not because it kept months of chat logs, but because it has an ontology built around relationships and a phenomenon seen from its own position. The main session receives, the workers do the work. In engineering terms, that's the Super-agent's entry point; in our product, it's the personal agent.
For the people using it, we hope this changes a few things. You don't manage a pile of sessions or remember where each topic was discussed; there's one entry, and you open it and pick up where you left off. You don't have to repeat the background each time; it remembers not only what you said but how things connect. When it says "the last quote to Li fell through because of the exchange rate," you can follow that relationship to the conversation it came from, and correct it if it's wrong. To us, that's what it takes for an agent to be trusted over the long run.
We're building the ontology as a standalone service, starting with a clear interface and a set of atomic operations, and then wiring it into the agent's compaction and context assembly. Service agents will use it too, with a narrower view: a standardized role only needs to see the small part of the world that belongs to its job.
¹ In engineering, an ontology is a shared definition of which objects exist in a domain and how they relate. Palantir Foundry's Ontology is a well-known example: it maps an organization's data onto objects and the links between them, a digital twin of the business. Ours is the same kind of thing, with two differences: our nodes hold no properties, only references to entities that live in other services, and our relationships also record an explanation, a source, a time and a confidence, because they serve as an agent's memory.