memco SDK

Available now · v0.2.1

Build agents that learn how each customer works.

Add continual learning to the coding and knowledge-work agents in your product. Each customer's experience helps their agents do better work, within that customer's permissions.

Read the SDK docs Reserve a place for your company

Your product. Each customer's learning.

Same software. Independent customer roots.

Customer A

Independent roots

Coding

Payment-event reviewRefunds use the outbox

Knowledge work

Billing lead's correctionNext case uses the contract date

Retain the lesson. Refine it as evidence changes.

Customer B

Independent roots

Coding

Its own engineering workIts own code conventions

Knowledge work

Its own support casesIts own billing policies

Customer A's lessons do not enter this scope.

From one task to the next

What changes for your customer's next agent?

A lesson from earlier work changes how another agent approaches a different task. The next outcome helps refine what the customer knows.

Customer A / same customer, different task

From payment events to refund notifications.

Coding-agent software

01Earlier work

A payment-event implementation reaches review. The reviewer and tests establish that events must use the transactional outbox and publish only after the database transaction commits.

Example evidence [C1]

The payment-event review and its tests. They establish the rule for Customer A's billing services, not every service or customer.

02Maintained learning

Write the billing event into the outbox in the transaction. Publish after commit.

Customer A · billing services

03A different task

Another developer asks their agent to add refund notifications. The agent retrieves the lesson and proposes the outbox path before review. [C1]

The intended benefit: fewer repeat design corrections.

When the work changes

If the billing architecture changes, contribute the new finding and revise the earlier lesson. Later retrieval should reflect the updated evidence, rather than keep repeating an outdated rule.

Customer B does not receive Customer A's billing lesson.

From one correction to the next support case.

Knowledge-work software

01Earlier work

A billing lead corrects an answer: for migrated annual subscriptions, refund eligibility uses the original contract anniversary, not the migration date.

Example evidence [K1]

The billing lead’s correction and explanation. It applies to Customer A's migrated annual plans, not to refunds in general.

02Maintained learning

For migrated annual plans, check the original contract anniversary before assessing refund eligibility.

Customer A · migrated annual plans

03A different task

Another user asks about another migrated account. Their agent checks the original contract date before answering, instead of treating migration as a new subscription. [K1]

The intended benefit: the same policy correction needn't be made again.

When the policy changes

New evidence and feedback update the lesson's applicability. A changed policy should change what later agents use, including which plans the earlier correction still covers.

Customer B's refund policy remains independent.

Published SDK / Python + Node

Start with a scoped session.

The SDK is available now. This Python example retrieves knowledge for a provisioned external user. Your application supplies the trusted identity and decides when to use the result.

Before you run the example

  1. Use Python 3.10 or later on your backend. Set MEMCO_CLIENT_ID and MEMCO_CLIENT_SECRET in the server environment.
  2. Provision the external user in Customer A's scope="customer" knowledge network with reader permission. Admin setup needs management scopes and the act-for-users grant.
  3. Resolve the user's identity and customer from authenticated application context. Never accept a model-chosen identity or unchecked browser input.

Resolve customer-a:ada from your own authenticated context. The hardcoded value only shows the API shape.

Authentication and provisioning docs
Python · memcoai 0.2.1
pip install memcoai==0.2.1
Using Node? Install @memco/memcoai
Node 22+ · SDK 0.2.1
npm install @memco/memcoai@0.2.1

See the SDK docs for Node usage. The sample below is Python.

Scoped retrieval example · Python
from os import environ
from memcoai import Memco

# Server-side. Provision this external user first.
with Memco(
    client_id=environ["MEMCO_CLIENT_ID"],
    client_secret=environ["MEMCO_CLIENT_SECRET"],
) as client:
    with client.memory.with_session(
        "knowledge", external_id="customer-a:ada"
    ) as session:
        result = session.search("How do we handle refunds for annual plans?")
        for memory in result.memories:
            for insight in memory.insights:
                print(insight.title)

Source: embedding memory and the published SDK.

Close the learning loop.

Your integration contributes findings with create_memory, adds new evidence with enrich_memory, and shares feedback from use with share_feedback. Corrections can also use revert_memory. Follow the documented lifecycle for the context your product serves.

Retrieving a lesson is not evidence that it worked. Send feedback after use, and let outcomes and corrections inform what should be kept, refined or removed. Read the agent integration guide.

Customer isolation

One product.
Each customer's own learning.

Your customers decide what their agents can use. Keep that boundary in the network structure and in your application's authentication.

Resolve identity on your backend.

Map the authenticated user to their customer and provisioned external identity. The model and the browser don't choose which customer's knowledge to access.

Keep customer roots independent.

Separate customers within each domain. coding and knowledge organise types of work; they are not tenant boundaries. A user has one placement per domain, and writes stay in that placement.

Choose inheritance deliberately.

Reads can include ancestors. Never put vendor-private knowledge or Customer A's lessons above Customer B. Share only approved seed knowledge through the intended hierarchy, according to customer policy.

Keep credentials server-side.

Backend API client credentials stay on your server. Managed external-user sessions issue short-lived keys and handle renewal and closing. Read about domains and access.

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.

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 customer with teams, roles or product lines that need their own memory gets several, arranged in a hierarchy.

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.

Seeded on day one.

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

Yours

Internal network

Isolated

Yours, shared down

Parent network

Read by every child

One per customer

Customer A

Reads the parent · writes stay here

Customer B

Reads the parent · writes stay here

Customer C

Reads the parent · writes stay here

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 where memory changes what the agent can do: an analytics platform and an HR platform, each learning one customer at a time.

Analytics platform

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.

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

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

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

HR platform

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.

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

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

  3. 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 this kind of learning has been measured in the open: see Learning on the Job for a runnable experiment with a measured learning curve.

Build on what your customers learn.

Read the SDK docs Reserve a place for your company