Frequently asked questions

GoodMem is memory infrastructure for AI agents: a self-hostable server that ingests your documents, embeds and indexes them, and serves governed, permission-checked context back to any model.

It sits between your agents and your data. Your application calls GoodMem to store content and to retrieve relevant passages at inference time; GoodMem manages the ingestion pipeline, the embedding orchestration, the retrieval pipeline, and the access-control layer around them.

A memory is a document, not an extracted fact. When you create one you submit the original content along with its content type and an optional metadata object.

GoodMem stores that original content, extracts text from it, splits it into chunks according to the space's chunking configuration, and embeds each chunk. Retrieval returns chunks, each of which cites the memory and the position it came from. One memory therefore produces many indexed chunks, and chunk count — not memory count — is what drives storage.

You need a memory layer when the context your agents require outlives a single request, and when more than one agent, user, or team has to share that context under different permissions.

The concrete symptoms are: agents that re-read the same source material on every run, context windows that grow until they become the dominant cost, knowledge that has to be scoped per customer or per team, and retrieval behavior you cannot audit after the fact.

A plain vector database is enough when you have one corpus, one embedding model, one trust boundary, and a document pipeline you are happy to own.

If you are embedding clean text you already have in hand, filtering it in SQL, and serving it to a single application, pgvector or a dedicated vector store will do the job with less to run. Use GoodMem when you need several embedders combined and weighted, substantial document extraction (PDF and Office formats, OCR, page images), per-space permissions across many principals, or a record of what was retrieved.

GoodMem stores and retrieves documents. It does not do several things people often assume a memory product does.

It does not extract facts or summarize your content into assertions — it stores what you give it and chunks it. It does not decide on its own when to write a memory; in most framework integrations your agent calls a tool to store something. It does not resolve contradictions between an older and a newer version of the same fact. It does not expire memories on a timer, and it does not update a memory in place. It is not a conversation transcript store: you keep the transcript, GoodMem keeps the durable material.

GoodMem is built and operated by PAIR Systems, Inc., a Delaware corporation founded in late 2024 and backed by Silicon Valley venture firms. GoodMem is the product; PAIR Systems is the entity you contract with.

PAIR Systems holds an ISO/IEC 27001 certification and publishes its policies and security documentation through its trust center. Incorta runs GoodMem in production; further references and security evidence are available under NDA as part of a review.

Retrieval runs a query through every embedder registered on the space, combines the results, and optionally reranks and post-processes them before returning chunks with relevance scores and citations.

A space can carry both dense and sparse embedders, so lexical and semantic matching run together and their scores are combined with per-embedder weights you control. You can constrain results with metadata filters, cap them by count or relevance threshold, and tune the underlying index search parameters per request.

GoodMem ingests PDFs, Microsoft Office documents, and plain text and markup, extracting text with layout awareness and running OCR on scanned material using a self-hosted model.

Chunking is configured per space: you set the chunk size, the overlap, and the separators. Ingestion is asynchronous — a memory is created immediately and moves through a processing status until its chunks are indexed and searchable. Page images can be extracted alongside the text and fetched on demand to support citations.

To correct a memory today you delete it and create a replacement. GoodMem has no in-place update operation, and editing a memory's metadata after processing does not re-embed its existing chunks.

Until the replacement finishes processing, a query can still match the old content, so sequence the delete and the create rather than running them in parallel. It is not available today.

Nothing in GoodMem automatically resolves a contradiction between two memories — if both an old and a new version of a fact are stored in the same space, retrieval can return both and the model decides what to do with them.

The controls you have are deletion, metadata filters that scope a query to the material you consider current, and an optional chronological re-sort of results. If correctness depends on recency, treat superseding as an explicit step in your ingestion pipeline rather than something retrieval will infer.

Deleting a memory removes it from the active GoodMem database and search indexes, including the chunks derived from it and their dense and sparse index entries. GoodMem does not provide a soft-delete or recycle bin.

Copies may remain in database backups or separately retained retrieval records until they age out under the retention schedules the operator sets.

You can delete memories individually or in batches, including by metadata filter. Retrieval logs, where enabled, are governed separately by their own retention: they are written to daily partitions, so operators expire them by dropping partitions on whatever schedule their retention policy requires.

There is no TTL, expiry, or decay on a memory today. A memory persists until something deletes it, so a space grows monotonically unless you manage retention yourself.

The supported pattern is to record your own retention marker in a memory's metadata at ingest, then run a scheduled batch delete filtered on that marker. API keys are separate: those do support validity windows and expiry.

Changing the embedding model for content that is already indexed means creating a new space with the new embedder and re-ingesting into it. GoodMem deliberately rejects edits to an embedder's model identifier or dimensionality while a space still references it, because existing vectors would no longer be comparable.

There is no automatic re-embedding or backfill job. Because GoodMem stores the original content alongside the vectors, re-ingestion does not require you to go back to the source system or repeat OCR — but it is a re-ingest, and you should plan for the embedding cost and the time it takes.

GoodMem publishes first-party SDKs for Python, TypeScript, Java, Go, and .NET, plus an MCP server. All of them are generated from a single shared API description, so each one exposes the same core API.

The SDKs are published under the Apache-2.0 license to their language's standard registry. The GoodMem server itself is separately licensed — see the licensing section below.

GoodMem exposes both REST and gRPC, carrying the same operations, and both authenticate with an API key sent in an `x-api-key` header.

Choose based on your stack rather than on capability. If you plan to generate your own gRPC stubs rather than use a published SDK, ask us for the protocol buffer definitions — the generated SDKs are the supported path for most users.

GoodMem has documented integrations for LangChain, LangGraph, LlamaIndex, CrewAI, Google ADK, Microsoft Agent Framework, Spring AI, LangChain4j, DSPy, Genkit, CAMEL-AI, and NLWeb, alongside workflow builders such as n8n, Flowise, and Activepieces.

Most of these expose GoodMem as agent tools that your model calls to store and retrieve, rather than as a drop-in retriever object. The Google ADK integration is the exception: its plugin saves and recalls on each agent turn through framework callbacks, without the model having to choose to call a tool.

Yes. GoodMem ships an MCP server that exposes its operations to standards-compatible MCP clients, and there are packaged plugins for coding agents including Claude Code and the Codex CLI.

This is the fastest way to operate GoodMem conversationally — creating embedders, creating spaces, ingesting documents, and running retrieval without writing integration code.

GoodMem calls embedding, reranking, and generation models as registered endpoints rather than bundling a fixed model, so you register the providers you want to use and supply your own credentials.

Both hosted commercial providers and self-hosted inference servers are supported, and the set of supported providers changes as models ship. The endpoint registration guide carries the current list along with the provider-specific base URL and path behavior for each.

There is no packaged connector suite today. GoodMem exposes ingestion APIs and you drive them from your own pipeline, which is how most deployments load content.

We have built source-system connectors for individual customers, so the work is well understood, but it is not something you can pick off a shelf. If a connector is on your critical path, scope it with us rather than assuming it ships in the box.

Yes. GoodMem supports self-hosted inference endpoints for embedding and reranking, so a deployment can run without content leaving your network.

This is a configuration decision rather than an enforced mode: if an operator registers an external provider, content sent for embedding or generation reaches that provider. If your requirement is that content must never leave a boundary, register only self-hosted endpoints and control who holds the permission to register new ones.

There are two deployment models: GoodMem Cloud, a managed service where each workspace is provisioned with a separate GoodMem application instance and database, and self-hosting, where you run the server in your own environment under the binary license.

Self-hosting uses Docker Compose, driven by an installer that also covers one-command deployments to several hosting providers and Google Cloud Marketplace. There is no Helm chart or Kubernetes operator today; teams running on Kubernetes author their own manifests against the documented ports and health endpoints.

Self-hosting requires a container runtime and a PostgreSQL database with the pgvector extension. There is no separate vector database, message broker, or object store to operate. Depending on configuration and operation, GoodMem may call registered embedding, OCR, reranking, or generation endpoints, which may be self-hosted or provided by third parties.

The server is a Java service shipped on a distroless, non-root image. GoodMem's core application data lives in PostgreSQL: original content, extracted text, chunks, dense and sparse vectors, page images, access-control records, and retrieval logs.

Yes. The server takes a database URL and user as configuration, so you can run it against your existing managed PostgreSQL — RDS, Cloud SQL, or your own cluster — instead of the bundled container.

This is the recommended arrangement for production, because it puts backup, point-in-time recovery, failover, and monitoring under the tooling your team already operates. The database needs the pgvector extension available.

Sizing depends on how large your corpus is, the embedding dimensions you choose, how fast you ingest, and your query volume — enough variables that a published table would mislead more than it helped. Tell us your corpus size and expected query rate and we can help you work through provisioning.

For a proof of concept, one instance against a modest database is usually enough to load a representative sample and measure retrieval on your own data before committing to a shape.

Backing up the PostgreSQL database captures GoodMem's core application data, and standard PostgreSQL tooling — logical dumps, physical backups, point-in-time recovery on a managed service — is the supported path.

A complete recovery plan must also preserve deployment configuration, license material, TLS assets, credentials, and the required container images. Your achievable recovery objectives therefore depend on both the database platform and your own tested restoration procedure. Backup and recovery design review is available as part of enterprise onboarding.

GoodMem exposes a Prometheus metrics endpoint and separate liveness, readiness, and startup probes for orchestrators, plus gRPC health checking. Request-ID correlation ties log lines belonging to the same request together.

Two things it does not currently emit: structured JSON logs and OpenTelemetry traces. If your platform standard requires distributed tracing today, plan to correlate at the request-ID level instead.

Yes. The install guide documents deployment from a mirrored registry and a fully offline path where images are exported, transferred, and loaded on the target host.

A self-hosted server reports license telemetry by default. That reporting can be turned off, arranged under an enterprise agreement along with licensing for an environment that has no outbound connectivity. Register self-hosted inference endpoints as well, so retrieval does not reach an external provider. Talk to us before planning an air-gapped rollout.

A GoodMem instance is one database serving one tenant. Separating customers from one another therefore means running separate instances with separate databases, rather than partitioning inside a shared one.

Within an instance, spaces and access controls partition content among agents, teams, and workloads. These are logical authorization boundaries, not independent customer tenant boundaries. Distinct external customers should use separate instances and databases. Requirements for separate compute, networks, cloud accounts, encryption domains, or failure domains have to be addressed in the deployment architecture itself.

Access control is a role and grant model evaluated on protected resource API requests. Authority is expressed as an operation paired with a selector that says which resources it applies to, granted directly to a principal or bundled into a role.

Roles exist at instance scope and at space scope, so a principal can administer the instance, or hold viewer, contributor, content-manager, or admin rights on an individual space. Principals are either people or service identities, which lets a production workload hold its own durable identity so credentials rotate without changing who has access to what.

API keys authenticate protected API requests, and a key can carry a permission ceiling that is fixed when the key is issued and cannot be widened afterwards.

A scoped key is evaluated twice: the subject must hold the permission, and the key's ceiling must also allow it. That lets you issue a key to an agent, a CI job, or an integration that holds strictly less authority than the identity behind it. Keys support validity windows, only a verifier is stored rather than the key itself, and revocation is permanent.

No. GoodMem does not support SSO, SAML, OIDC, or SCIM provisioning today. Authentication is by API key, and people are onboarded through a one-time enrollment credential that they exchange for their first key.

Until it ships, deprovisioning a person means revoking their keys, so treat key inventory and revocation as part of your joiner-mover-leaver process. If an SSO requirement governs your timeline, tell us during a security review so we can talk about sequencing.

Yes. GoodMem can maintain a retrieval activity log showing which principal and key ran a query, which spaces were queried, and what was returned.

Logging is governed by administrator policies that select which callers and spaces are recorded, so it is a deliberate configuration rather than on everywhere by default. Logging is configurable, asynchronous, and best-effort. It records retrieval activity rather than every API operation, and should not be relied on as a complete security audit log. Records are written to daily partitions, so operators control retention through partition management.

Retrieved content is wrapped in request-specific delimiters carrying a random nonce and a machine-readable classification marking it as untrusted data rather than instructions, which helps a downstream consumer distinguish stored content from its own instructions.

It is a defense-in-depth signal for a probabilistic consumer, not a parser-enforced boundary. Anyone who can contribute to a space can influence what your agents read, so treat contribution rights on a space as the security-relevant permission they are, and keep a human in the loop for consequential actions.

GoodMem Cloud is not currently offered under a HIPAA business associate agreement and should not be used for workloads that require one.

For regulated workloads, customers commonly self-host so they control the infrastructure, the database, where data resides, and which model endpoints are called. Self-hosted GoodMem does not require Customer Content to be transmitted to PAIR Systems. Self-hosting does not by itself make a deployment compliant: you remain responsible for configuring and operating it to meet your own legal and compliance requirements. Talk to us to confirm the scope of any support or services before using GoodMem with regulated data.

PAIR Systems holds an ISO/IEC 27001 certification. A SOC 2 Type II audit is underway; PAIR Systems does not yet have a SOC 2 Type II report.

Certificates, policy documentation, and further security evidence are available through the trust center, and additional artifacts can be shared under NDA as part of a security review.

PAIR Systems does not use Customer Content to train shared or general-purpose models, or to improve models or services across customers. That commitment is contractual, in the Cloud terms of service.

Where a customer enables customer-specific optimization, the resulting processing is performed for that customer and governed by the applicable configuration and agreement. Customer data does not contribute to shared or cross-customer models. Self-hosted GoodMem does not require Customer Content to be transmitted to PAIR Systems; content sent to model providers you select, or shared with us during support, is governed separately.

GoodMem Cloud processes data in the United States. There is no EU region today, and transfers are governed by standard contractual clauses set out in the data processing addendum.

There is no EU region today. If EU residency is a requirement today, self-hosting is the route: you run the server in the region you choose, against a database you control. Subprocessors for the managed service are listed in the addendum and the trust center, with a notification and objection window for changes.

GoodMem supports extensions: packaged post-processors that an instance administrator uploads and that run inside the retrieval pipeline to transform results before they are returned.

Because an extension executes inside the server and sees retrieved content, uploading one is an administrative capability and should be governed like deploying code. Restrict the permission to the identities that genuinely need it, review what you upload, and if your threat model does not allow it, do not grant it to anyone.

No. GoodMem is not open source. The server is proprietary software distributed as a binary under the GoodMem Free Binary License, which grants continuing rights to use versions you validly obtain, subject to the license's terms, but does not grant rights in the source code.

The client SDKs are published under Apache-2.0 and are open source; the server is not. "Free" in the license name refers to price for the covered uses, not to software freedom.

The free binary license lets you run unmodified GoodMem in your internal business operations, and inside products and services you provide to third parties, at no cost — including commercial SaaS products built on top of it.

What it does not allow is offering GoodMem itself as a standalone hosted, managed, or white-labelled GoodMem service, or modifying, reverse-engineering, or redistributing the software outside your own application. Rights continue for as long as you comply with the license. If your business model is close to that line, or you want managed-service or reseller rights, those are available under a commercial agreement.

Yes, subject to the embedded-distribution conditions in the GoodMem Free Binary License. GoodMem must remain a component of the application you deliver rather than a standalone GoodMem service, and your end-user terms must protect PAIR Systems' rights as the license requires.

That covers shipping it in a container image, a virtual machine image, or an on-premises installer alongside your own software. What it does not cover is distributing GoodMem on its own, or running it as a hosted GoodMem service for others.

A self-hosted GoodMem deployment is designed to operate on infrastructure you control, without ongoing connectivity to PAIR Systems. Your content, embeddings, and access policies remain in your own PostgreSQL database.

Subject to continued compliance with the license, you may keep using versions you validly obtained. Continued operation depends on retaining the necessary software artifacts and on maintaining your infrastructure, configuration, credentials, and model endpoints. What would no longer be available from PAIR Systems is future releases and support. Enterprise agreements may also include source-code escrow and continuity rights, with release conditions defined in advance.

GoodMem Cloud bills for instance compute by the second while an instance is running, plus the data that instance stores. There is no per-memory charge, no per-API-call charge, and no per-seat charge.

Pausing an instance stops its compute charges while its stored data continues to be billed. Current rates are shown in the console, and a trial is available without a credit card.

Expect a stored footprint substantially larger than your source documents, because GoodMem keeps the original content, the extracted text, the chunks, dense and sparse vectors, and optionally rendered page images.

In one measured workload a document expanded by roughly thirty times, with page images accounting for most of that. Actual ratios vary materially with document format, page-image settings, chunking, and embedding dimensions, so measure a representative sample when sizing a deployment. Our total-cost analysis walks through the measurement and the arithmetic.

Self-hosting GoodMem costs nothing in license fees for the uses the free binary license covers, including commercial use. Your costs are the infrastructure you run it on and the inference providers you register.

There are no artificial caps on the number of memories or spaces on a node; capacity is whatever your hardware and database sustain. Enterprise agreements add commercial terms such as support tiers, service levels, and the continuity arrangements described above.

A 99.99% uptime service level agreement is available as part of a signed enterprise agreement. The standard Cloud terms of service do not carry an availability commitment, and self-hosted deployments run on your own infrastructure, so their availability is yours to manage.

If you need a contractual uptime commitment with defined measurement and remedies, that is an enterprise conversation rather than something the self-serve tiers include.

Free self-hosted and self-serve users are supported through the community forum, on a best-effort basis with no response target. Enterprise licenses add contractual support tiers, with initial response targets as short as one business day and, at the most stringent level, 24/7 coverage and a two-hour initial response target for severity-one incidents.

Security vulnerabilities are handled separately and should always be reported privately through the disclosure process, whatever tier you are on.