Pith is the persistent, source-grounded reading memory your agent plugs into — real citations behind every recall, instead of a stateless scratchpad that resets each run.
Agent harnesses are good at loops and tool calls and bad at remembering anything between runs. Most "memory" is a scratchpad: a context window that fills, gets summarized lossily, and vanishes when the run ends. Pith is the durable, cited memory your agent reads from over MCP. Your reading accumulates into a source-grounded knowledge base; the agent queries it as a tool and gets back facts with links to where they came from. Pith doesn't run your agent — your harness calls Pith, the way it calls any other tool.
What changes for you
Scenario 1
Memory that survives across runs, not just within one
A context window is gone the moment the run ends; Pith persists. Your agent writes its working knowledge into a reading memory it can query on the next run, so a multi-day task builds on what earlier runs learned instead of relearning it from scratch.
Scenario 2
Retrieval that comes back with citations attached
When your agent asks Pith "what do we know about X," it gets passages grounded in real saved sources, each with a link. The agent can cite its evidence in the output — and you can audit why it said what it said, rather than trusting an opaque embedding blob.
Scenario 3
One memory, many harnesses
Because Pith speaks MCP, the same cited reading memory is reachable from an Agent SDK loop, a custom orchestrator, or an off-the-shelf client — without rebuilding the store for each. Swap or combine harnesses; the memory layer stays put and stays grounded.
Founder's note
I think the interesting part of an agent isn't the loop — it's what the loop remembers. Frameworks come and go; a grounded, cited memory of what you've actually read is worth keeping across all of them. So I built Pith as that layer: not a harness, but the source-backed memory a harness can call.
FAQ
How does an agent connect to Pith?
Over MCP. Pith exposes a hosted MCP server with tools for searching and reading your cited reading memory. Any MCP-capable harness — an Agent SDK loop, a custom orchestrator, or a desktop client — registers the server and calls those tools inside its own loop. To the agent, Pith is just another tool that happens to return grounded, cited knowledge.
Is Pith competing with my agent framework?
No — it's complementary. Pith is the memory layer, not the harness. Your Agent SDK loop, planner, or orchestrator stays in charge of control flow and reasoning; it calls Pith for persistent, source-grounded recall the same way it calls a search or code tool. Pith never tries to run the loop.
How is this different from stuffing context into the window?
A context window is per-run, size-bounded, and lossy when summarized — it forgets the moment the run ends. Pith is durable storage the agent retrieves from on demand, so it pulls only what's relevant for the step instead of carrying everything, and the knowledge persists across runs and across harnesses.
Why does citation matter for an agent's memory?
Because grounded recall is auditable recall. Every fact Pith returns links back to the source it came from, so the agent can cite its evidence and you can trace why it acted as it did. For agents that touch real decisions, source-grounding is what separates a defensible answer from a confident guess.
Where does the memory live, and is it used for training?
In Frankfurt, Germany — EU-only residency, isolated per workspace, exportable anytime as Markdown or JSON. We do not train models on your content. The memory stays in the EU even when the agent calling it runs elsewhere.
Can the agent write to Pith, or only read?
Both, with control. Read access lets the agent query the cited reading memory; write-scoped access lets it save new sources or update knowledge as it works. Write operations are gated by explicit scopes, so an agent only changes what you've allowed it to.
Related
Last reviewed: 7 June 2026