Integrations

Memory for the agents you build

The Memco SDKs for Python and Node.js give the agents you write, and the products you ship, a memory that learns from use and stays inside the boundary you set for it.

pip install memcoai

npm install @memcoai/memco

Read the SDK docs View on GitHub

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. Sessions are bound in code, so a model can never drop or invent a session id. Results and errors are typed. 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.

If what you want is for an existing agent such as a coding assistant to use Memco, that route is MCP rather than the SDK, and the quick start covers it.

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

The larger opportunity is for companies whose product has an agent in it. Your customers use your product. Your product uses Memco. Each customer gets an agent that learns 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.

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

In most products two audiences meet the agent. The people asking for something: a policy lead who needs a number, an employee who needs to know about leave, a project manager who needs an estimate. And the experts who know how things actually work at that organisation: the analyst, the HR partner, the engineering lead.

The agent searches the customer's memory before it does anything. When memory answers, the agent acts and rates what it used. When it doesn't, the agent escalates to the expert rather than guessing. The expert's answer becomes memory, and the next time a similar request arrives it is self-serve.

Every memory carries a reliability signal built from how it was rated in use, so a low signal is a reason to escalate. Every write is reversible within a window, so an expert who spots a wrong lesson can remove it before it spreads. Over weeks, the share of requests the agent handles alone rises, and the experts' 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

One network per customer, or one you share down

A memory network is the unit of sharing. Everyone with access searches and contributes to the same memory; nobody outside can see in. Your own engineers have a network for the coding and knowledge work of building your product. What you create for your customers is separate, and you choose the shape:

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.

An inherited network. You maintain a parent network holding what every customer should start with: how your product works, good practice for the domain, policies that apply to everyone. Each customer's network inherits it and adds its own. Read access flows down; writes stay local. A customer's corrections shape their own network and never reach another customer.

A shared network. 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.

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.

Network management and external user registration are being added to the SDK and will follow the initial release. The documentation describes the model and will be updated as they ship.

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.

An analytics platform whose customers run large, layered data estates

A vendor sells a platform that 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. The platform’s 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 the vendor: 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.

An HR platform whose agent answers employees’ questions about policy, leave and process

A vendor sells an HR platform 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. The vendor’s 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 memory, and the next such case is answered with the ruling and its source.

For the vendor: 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.

Sessions that cannot be dropped.

Bound in code, outside the model’s reach. Every call an agent makes is recorded as part of the same task.

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+.

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.

Get an API key SDK documentation github.com/memcoai/memco