Why Synapse works with any AI — and why that matters.

Yes. Synapse is a plain HTTP API. It doesn't care which model you're using, what framework you're building in, or what cloud you're on. If your agent can make an HTTP request, it can use Synapse.

That means it works out of the box with OpenAI, Anthropic Claude, Google Gemini, Mistral, Llama, and any other model — hosted or local. It also works with LangChain, AutoGen, CrewAI, and custom-built agents. There's no SDK lock-in and no required plugin.

It doesn't. By default, every conversation starts from zero. The moment a session ends, everything said or decided is gone. The next time a user talks to your agent, it has no idea who they are, what they previously asked, or what decisions were already made.

This is fine for a chatbot answering FAQ questions. It's a real problem the moment your agent is handling anything that unfolds over time — a client relationship, a multi-step workflow, an onboarding process, a compliance record. Synapse gives your agent a memory that persists across every session, every conversation, and every model version you deploy.

A context window is a scratchpad that gets wiped when the session ends. Synapse is a database that persists indefinitely.

Even if your model has a large context window, you still have to fill it — which means deciding what to include in every single prompt. As history accumulates across dozens of sessions, you can't fit it all. You end up writing logic to summarize, truncate, or select what gets passed in. That logic breaks. It's expensive to run. And it still disappears when the session ends.

Synapse handles retrieval for you. It stores records permanently and surfaces only the most relevant ones for each request — so your context window stays clean and your agent always has the right background, not just whatever happened to fit.

Three reasons that doesn't close the gap:

Cost. Passing millions of tokens on every request is expensive at scale. Even if the window exists, it's rarely economical to use it fully.

Performance. Models don't process a 1M-token context as well as a focused, relevant one. Attention degrades with noise. Retrieval gets you precision; brute-force context gets you dilution.

Persistence. No matter the window size, it still resets when the session ends. Long context is a buffer. Synapse is a record. Those are different things with different purposes.

Synapse also improves as you add more records — it gets smarter about what's relevant the more your agents use it. A larger context window can't do that.

Most memory systems call an LLM to classify, summarize, or embed the data before storing it. That means every write has latency, cost, and an external dependency. If that LLM is slow, rate-limited, or down — your write fails or backs up.

Synapse classifies records using a self-hosted open-source model (Gemma 3 1B) running on infrastructure we control — not a third-party API. No OpenAI call, no Anthropic call, no per-classification token cost. You POST a record and it's stored.

For high-frequency agents logging events, tracking decisions, or updating customer state continuously, this difference is significant in both cost and reliability. It also means classification keeps working even if every major LLM provider has an outage simultaneously — because we don't depend on any of them.

Synapse doesn't decide on its own — your agent does. You write records explicitly: a decision made, a fact learned, a task completed, a preference noted. Synapse stores what you tell it to store, classifies it by type, and makes it retrievable.

This is intentional. Fully autonomous memory systems that "figure out what to save" introduce unpredictability. Synapse gives you control over the record structure while handling all the classification, indexing, and retrieval automatically. You define what matters. Synapse makes sure it's there when you need it.

Yes — that's one of the core use cases. Synapse is designed for multi-agent environments where shared context matters.

A research agent can write a record. A drafting agent can retrieve it an hour later without being told it exists. A supervisor agent can query across all records for a client to assemble a complete picture. Sessions, agents, and even separate services can all read from and write to the same memory store.

This is particularly useful in financial services and professional services workflows where multiple team members — or multiple automated processes — are working on the same engagement over time.

Your records are stored in your own database. Synapse does not send your data to any third-party LLM for classification or processing — classification runs on infrastructure we control, using a self-hosted open-source model. There are no shared indexes, no training on your records, and no cross-tenant data access.

For enterprise and white-label deployments, Synapse can be deployed entirely within your own infrastructure — your cloud account, your VPC, your compliance boundary. This is a first-class option, not an afterthought. It's particularly relevant for financial services, legal, and healthcare teams with strict data residency requirements.

RAG is designed for documents — you chunk a PDF or knowledge base and retrieve relevant chunks when a user asks a question. It's a lookup tool, and it works well for that.

Synapse is designed for agent memory — the ongoing record of what an agent has done, learned, and decided. Records aren't documents. They're structured facts: a client preference noted on a specific date, a task completed in a prior session, a decision made three weeks ago. The retrieval model is built around that structure, not around document similarity.

You can use both. RAG handles your knowledge base. Synapse handles your agent's running memory. They solve different problems.

It means your memory survives your model choice — including future changes to it.

If you build your memory layer on top of a specific LLM's tooling (OpenAI's memory feature, Claude's project memory, etc.), you're tied to that provider. Switch models, and your history either doesn't migrate or requires engineering work to port.

With Synapse, the memory layer is independent. You can swap from GPT-4 to Claude to an open-source model tomorrow and every record your agents wrote is still there, fully searchable, immediately available. The model changes. The memory doesn't.

For organizations evaluating multiple providers or planning to run different models for different tasks, this is the practical difference between memory that compounds over time and memory that resets every time you make a vendor decision.