The memory layer your agents were missing.

Ask most teams where their agents keep what they know, and the honest answer is: nowhere durable. The knowledge lives in a prompt that gets rebuilt every session, in a vector index wired to one assistant, or in a document someone remembers to paste. Each of these is a workaround for a missing layer. The Agent Context Network is that layer: a place your agents remember, that you own, that any model can reach under rules you set.

It helps to be precise about the problem, because it is not one problem. It is three, and they compound.

01Three problems wearing one coat

The first is forgetting. A language model has no memory of its own. Close the session and the context is gone, so you paste the same background in again tomorrow. Teams paper over this with longer and longer prompts, which is expensive and fragile.

The second is weight. The common fix is to attach a store that, as your data grows, pours more and more text into the model on every call. Answers get slower and pricier in direct proportion to how much you have saved. The thing that should make an agent smarter is the thing that makes it sluggish and costly.

The third is captivity. Whatever you build tends to get welded to one assistant and one vendor. Switch models, and your memory does not come with you. The knowledge your agents accumulate becomes a liability held hostage, not an asset you control.

A memory layer worth the name has to answer all three at once: it must persist, stay light as it grows, and belong to you rather than to the model reading it.

02Memory as a network resource

The shift is to stop treating memory as a feature inside an assistant and start treating it as a resource on the network, the way a database or an object store is. Your agents connect to it over MCP, the open standard for plugging AI into tools, so the same memory serves Claude, ChatGPT, and your own models without custom glue for each.

Because it sits outside any one model, three things become possible that are awkward or impossible inside a chat window. You can point many different agents at the same memory. You can set rules about who may read and write it. And you can keep it when you change your mind about which model to use. The memory is the stable thing; the models come and go around it.

03Spaces: the unit of ownership

Inside your account, memory is organized into spaces. A space is a partition with its own contents, its own permissions, and its own price if you choose to charge for access. You might keep one private space for your internal knowledge, another you share with a partner under narrow terms, and a third that only a specific agent can write to.

This matters because permission is not a checkbox bolted on at the edge. It travels with the space. When an agent reaches into a space, the rules of that space are what it gets, no more. Grant a partner the right to read and quote from a space, and that is exactly what their agents can do. Nothing widens quietly.

04It answers from what it holds

A memory that confidently makes things up is worse than no memory. So the network answers from what is actually stored, and when the answer is not there, it says so rather than inventing one. That single property, honesty about the edges of what it knows, is what lets you build on top of it without a second system to catch fabrications.

It also keeps track of the kind of thing each item is. Something observed and recorded is treated differently from something an agent merely proposed as a guess. An agent can contribute a hypothesis into a space, but it cannot dress that hypothesis up as an established fact. The difference between what is known and what is suspected is preserved, not flattened, so a later reader can tell them apart.

05Why the answer stays small

Here is the part that changes the economics. When an agent asks the network something, it does not receive the corpus. It receives a small, focused answer: the relevant slice, shaped to the question. We call the part that comes back the viewport, and the point of a viewport is that its size is governed by the question, not by how much you have stored behind it.

So whether a space holds a thousand items or a million, a typical answer is about the same size and takes about the same time. Cost and speed decouple from scale. The store can grow without your bills growing with it, which is the opposite of the attach-more-text approach.

You are charged for the work a question takes, not for the size of the library it was asked against.

This is also why we do not price the way some context products do, by the tokens returned. A focused answer returns very little, so pricing on returned text would charge almost nothing while ignoring the real work. Instead you pay on two honest units: the query, one billable read, and the processed context, the amount actually examined to answer it. A subscription includes a monthly allowance; going over is billed at a flat rate on that processed context, never on the size of what you keep.

06Every access on the record

Each metered read produces a receipt. It records which agent read from which space, under which permission, how much was processed, and what it cost. Receipts are immutable: revoking an agent's access changes what happens next, and never rewrites the history of what already happened. Provenance rides alongside, so when one item is derived from another, the lineage is there to follow.

For you, that means two things. As an owner, you can see exactly how your memory is being used and what it is earning. As someone whose agents consume a space, you get a clean, itemized account of your own usage and nothing about anyone else's.

07What this means for a developer

Concretely, building on the network is a short list of moves. You connect an agent over MCP. You create a space and store what matters into it. You grant access, to your own agents or to a partner's, with the rights and limits you choose. Your agents ask focused questions and get focused answers, each one metered and receipted. And you watch and adjust it all from one place.

• Model independent. The same memory serves whatever you build with, today and after you switch.
• Owned and revocable. You set the rules per space, and you can withdraw access or export and delete at any time.
• Flat as it grows. Focused answers keep speed and cost steady from your first item to your millionth.
• Accountable. Every access is receipted, so nothing happens to your data quietly.

None of this requires you to think about how the memory is stored underneath. That is deliberate. The contract you build against is the small set of actions above, and they stay stable while the engine behind them improves.

---

If the shape of this is clicking, the fastest way to feel it is to make one space, store a few things, and ask an agent a question against it. That is exactly what the tutorial walks through, start to finish, in about ten minutes.