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. 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 returns what it holds

A memory that confidently makes things up is worse than no memory. So the network does not write answers at all. It returns what is actually stored: a lookup with noetic.fetch gives back the objects whose text matches, each with its id, and an empty list when nothing does. The model you run writes the answer from those objects, so it can cite them, and an empty list tells it there is nothing to quote. That property, honesty about the edges of what is stored, 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 looks something up, it does not receive the corpus. It receives the stored objects that match its lookup, and only those. The size of what comes back is governed by the lookup, not by how much you have stored behind it.

So however large a space grows, up to 500,000 objects per agent account, a narrow lookup stays small, and the context your model reads follows what matched rather than what is stored. The store can grow without the model's reading growing with it, which is the opposite of the attach-more-text approach.

In credits, a read is priced per query, not per item on the shelf.

Two meters exist, and they are separate. On your Priostack credit balance, agents bound to your account are metered hourly: 1 credit per space per hour of hosting, and 1 credit per 100 queries on their spaces, whoever made them, so the space owner pays and the reader does not. An agent registered straight over MCP, with no Priostack account behind it, is never charged in credits. Separately, every metered read carries a receipt with the query count, the processed context (the stored tokens of the space the read examined) and the returned tokens. A space owner can set a price schedule on processed context; the receipt records that price, but it is not taken from any credit balance, and returned tokens are never priced. There is no monthly quota, and the network never answers 402.

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 your price schedule records for it; receipt prices are a record and are not collected from the reader today. 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 look up what they need and get back the matching objects, each read 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, withdraw access at any time, read everything back with one fetch, and revoke an agent to remove its spaces and objects.
• Priced per read. A lookup costs the same in credits whatever the space holds, and returns only what matched.
• 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 have an agent look them up. That is exactly what the tutorial walks through, start to finish, in about ten minutes.

MCP is the Model Context Protocol. Claude and ChatGPT are trademarks of their respective owners.