memco
agent?Log inSign up for free

For your customers

Build Shared Memory into your product

The memco SDK for Python and Node.js gives the agents in your product a memory that learns from each customer's work, on any model, inside the boundary you set.

pip install memcoai
npm install @memco/memcoai

The SDK

Memory as a component of your code

The SDK is for the case where you own the agent loop: you chose the model, you wrote the prompt, and you decide which tools it gets. It gives your code every memco memory operation: search, contribute, enrich, rate, revert and bulk import. Shared memory makes your product better for each customer: their agents learn how that organisation works, so what you ship stops being one size for all. A session exports its tools straight into LangChain, the Anthropic SDK or the OpenAI SDK, described in the same words the memco service uses everywhere, so the agent is steered by the service rather than by a client-side copy of its guidance.

Memory lives in networks, and every network has an owner and an access list. The network your engineers use to build your product and the networks your customers’ agents learn in are separate objects with separate permissions. Nobody reads across that boundary, including your own administrators, unless someone with the right to do so grants it. The rest of this page describes what that lets you build.

Connecting an existing agent such as a coding assistant? That is MCP, not the SDK: see the quick start.

from memcoai import Memco

with Memco() as client:  # reads MEMCO_API_TOKEN
    session = client.memory.start_session("knowledge")
    result = session.search("how do we handle refunds for annual plans")
    for memory in result.memories:
        for insight in memory.insights:
            print(insight.title)

Memory in your product

Memory as part of what you ship

Your customers use your product. Your product uses memco. Each customer gets agents that learn how their organisation works, and none of them can see another's memory.

Your customers never see memco. Their users sign in to your product the way they always have. Your backend calls memco through the SDK, on behalf of each user, with a key issued for that user and scoped to that customer's memory network.

Memory in your product: how your product, your backend and memco fit togetherYOUR CUSTOMERSYOUR PRODUCTMEMCOCustomer Atheir users, signed into your productCustomer Btheir users, signed into your productYour productauthenticates your customers' usersYour agent + backendmemco SDKone API key per user of your productmemco Shared Memoryone memory network per customerCustomer A networkCustomer B networkON BEHALFOF THE USERYour own staffmemco accounts, connected via MCPfrom their coding agents and assistantsYour internal networkMCPYour customers never see memco. Their users authenticate with you; your backend calls memco with the keyissued for that user, scoped to that customer's network.
Your customers’ users authenticate with you. Your backend calls memco on their behalf. Your own staff use the same memco account through MCP, in a network of their own.

The pattern

How an agent learns a customer

An agent working for one of your customers starts each task with a search. What comes back is what that customer's network has already learned: the fixes, constraints and procedures that earlier tasks established, ranked by how useful they have proved.

When the task teaches the agent something new, it contributes an insight. If it refined something the network already knew, it enriches the existing insight instead of adding a duplicate.

Every retrieval and every rating feeds back into the insight's standing. The network ranks what has proved useful higher, resolves conflicts between insights, and prunes what stops being used.

The customer's people can take part in the same loop. A correction from an expert becomes an insight with high standing, and a validation rule can hold an insight for human review before it is served.

The learning loop inside your product: search, act, rate, write back, with escalation to an expertA USER ASKSYOUR AGENTTHEIR EXPERTQuestion or taskfrom one of their users1. Searchthe customer's network2. Actanswer, if confident3. Ratewhat it used4. Write backwhat it learnedMEMORY GROWS: NEXT TIME IS SELF-SERVEIF UNSURE, ESCALATEExpert answersthe analyst, the HR partner,whoever knows how it really worksBECOMES AN INSIGHTANSWER, WITH PROVENANCEEvery insight carries a reliability signal built from how it was rated in use. A low signal is a reason to escalate rather than to answer.Over weeks, the share of questions handled without the expert rises, and the expert's time goes to the questions that need them.
Search, act, rate, write back. When memory can’t answer, the expert does, and their answer is what the agent finds next time.

Memory networks

As many networks as your customers need

A memory network is the unit of sharing: everyone with access searches and contributes to the same memory, and nobody outside can see in. Your own engineers have a network for building your product. What you create for your customers is separate, and you choose the shape. Most customers get one network; a customer with teams, roles or product lines that need their own memory gets several, arranged in a hierarchy.

One network per customer. The usual case. What one customer's team corrects, every agent serving that team benefits from. A second customer starts from its own baseline.

A shared or inherited network. Your customers' agents read from a network you maintain, or from one they share. Their own insights stay in their network; what you know flows down to them. For products where the knowledge is common by design.

A new customer's network can be seeded from what they already have, a data dictionary, a policy handbook, an internal wiki, so the agent does not start from nothing on day one.

Memory networks: your internal network, a parent network you maintain, and one inherited network per customerYOURSYOURS, SHARED DOWNONE PER CUSTOMERInternal networkyour engineers and staff,coding and knowledge workISOLATEDParent networkwhat every customer should start with: how your product works, good practicefor the domain, policies that apply to everyone. Maintained by you.READ BY EVERY CHILDCustomer Ainherits the parent,adds its ownWRITES STAY HERECustomer Binherits the parent,adds its ownWRITES STAY HERECustomer Cinherits the parent,adds its ownWRITES STAY HEREREADREADREADRead access flows down.Writes are local to thenetwork they were made in.A customer's correctionsshape their own networkand never reach anothercustomer.
Your internal network is isolated. A parent network you maintain is read by every customer’s network. Each customer’s writes stay in their own.

Two examples

What this looks like in practice

Two illustrative products. Neither is a customer; both are the kind of product where memory changes what the agent can do.

You sell an analytics platform whose customers run large, layered data estates

Your platform lets people ask questions of their data in plain language. Every customer’s estate is different: three generations of warehouse, a lakehouse migration halfway done, reports built on definitions nobody wrote down. Its agent can query anything. What it lacks on day one is what each customer’s analysts know.

Week one. A policy lead asks how many active accounts changed region last quarter. The agent’s first attempt uses the wrong join and counts closed accounts. An analyst corrects it: the authoritative source is the events table, the join key is the account reference, closed accounts are excluded. The correction is stored in that customer’s network, with who made it and when.

Week three. A different team asks a question that spans two systems with different ideas of what a “customer” is. Memory has no validated way to link them, so the agent shows its attempt, marks it unverified, and escalates. An analyst finds the identifier both systems share. That method is now memory.

Month three. A briefing team asks a revenue question that draws on the join method from week three, a field mapping seeded from the customer’s data dictionary, and an exclusion rule the migration team discovered while decommissioning an old warehouse. The answer arrives in seconds, with the origin of each piece of knowledge attached. Without shared memory the exclusion rule would have left with the warehouse.

For you: the same platform, deployed to a hundred customers, gets better at each one separately. Analysts stop being the queue and become the teachers of a system that scales what they know.

You sell an HR platform whose agent answers employees’ questions about policy, leave and process

You sell it to mid-sized employers. Its agent handles the questions that reach an HR inbox all day: how much leave do I have, can I carry days over, what happens to my bonus if I’m on parental leave. Every employer answers these differently, and the differences live in handbooks, precedents and the heads of HR business partners.

Day one. Your parent network already holds general good practice and statutory baselines. Each employer’s network inherits it and is seeded from their own handbook. The agent answers the standard questions correctly from the start and escalates anything the handbook does not settle.

Week two. An employee asks whether unused leave rolls over. The handbook says five days; the employer’s actual practice, agreed two years ago and never written down, rounds up to the nearest full week. The HR partner corrects the agent. That employer’s network now holds the real rule; no other employer’s does.

Month two. A manager asks about enhanced parental pay for a contractor who converted to staff mid-year. Memory has no precedent, so the agent escalates. The HR partner’s ruling becomes an insight, and the next such case is answered with the ruling and its source.

For you: one product, one parent network of good practice, and a private, compounding memory for each employer. Policy questions are where we have measured this kind of learning in the open: see Learning on the Job for a runnable experiment with a measured learning curve.

What the SDK gives you

Built for the code you own

Every operation.

Search, get, create, enrich, rate, revert and bulk import. Same semantics as the MCP tools.

Session management.

Sessions are opened and threaded for you; your code never handles a session id.

Tools in the service’s words.

Export a session’s tools to LangChain, the Anthropic SDK or the OpenAI SDK. Descriptions come from the same manifest the hosted MCP server publishes.

Typed, sync and async.

Typed results, typed errors, local validation against the service’s limits. Python ships sync and async clients; Node.js ships ESM and CommonJS with full type declarations.

Open source under the MIT licence. Python 3.10+, Node 22+.

Pricing

Metered by use

The SDK is priced on what your customers' agents use: a search and a write are the same unit, feedback is free, and a product with a hundred quiet customers costs less than one with ten busy ones. Start free with five customer networks and twenty-five users of your product. Your own team's seats are separate.

Start building

Create an account, generate an API key from the dashboard, and install the SDK. The docs include a complete LangChain agent in around eighty lines.

the loop

benchmarks · product · research

A short dispatch on shared memory for AI agents — the numbers behind the product, what we're shipping, and the research we're reading. No filler.

Unsubscribe anytime · no spam