EXTRACT

Search indexes your documents.
Memoth remembers them.

A vector store makes text findable. It never decides what was worth keeping. Memoth reads each source passage by passage and writes down what a person would have kept — what happened, what is true, how it is done, and the resources they belong to — as typed fragments that each name their origin.

EXTRACT · GOVERN · SERVE

Become a design partnerHow it works

What Memoth is

A store, a ledger, and a write-back loop. One layer under every agent.

MEMORY STORE
EPISODICpayments failover — what broke
SEMANTICtopology: active-active
PROCEDURALrollback runbook · 6 steps

Typed fragments, not chunks — what a mind would keep.

GOVERNANCE
●source: Arch p.12 · verified
●merge recorded · ledger #4821
●ACL: devops → read

Every memory carries its source; every change hits a ledger.

PERSISTENT LAYER
↺learned: retry window 30s
→written back · 2m ago
▲week-2 recall +18%

What agents learn writes back. Week two beats week one.

Memoth.aiThe memory layer

How it actually works

Three things happen between a document and a fragment.

CONNECT

Point a connector at a source, or drop a file in. Upload is synchronous, capped at 64 MiB, and takes .md, .txt, .pdf, .docx, .pptx, .xlsx and .html.

Ten connectors exist. 4 of them run against live APIs today, and the wall below says which.

EXTRACT

Each source is read passage by passage rather than chunked and embedded whole. What survives is what a mind would keep — episodic, semantic and procedural memory, plus the resources they belong to. The rest is dropped instead of stored on the chance it helps later.

Sanitized, tagged, and mapped to your departments, functions and verticals.

FRAGMENTS

Every fragment carries where it came from and which resource it belongs to. Nothing is readable until an agent holds an edge to that resource, so a new fragment is governed from the moment it exists.

Each run reports what it did: discovered, edges planned, and an ACL preview — before a single fragment is served.

Measured, not promised

We publish the numbers behind every claim.

37/40
Answers correct on our document-QA suite, held to a zero-hallucination CI bar: one made-up answer fails the build.
40% → 80%
Task success with conditioned memory on CAMP-Bench, with hallucination cut to a third.
CAMP-Bench
Our benchmark for promotion: the right memory, to the right agent, at the right time, per domain. Every release is judged on it.

Both figures are reproducible on a frozen fixture, not third-party-validated. We run the same suites on your corpus during a pilot and hand you the table.

Connectors

Ten sources, labelled by what actually runs.

connectors10
running live4

Available

Running against the live API today.

NotionGitHubGranolaDocument upload

In validation

Written and fixture-tested, never yet run against the real API.

ConfluenceJiraSlackGoogle DriveGoogle DocsLinear

Planned

No code exists yet. It is on the roadmap and nowhere else.

This is the same list the product's Sources screen renders, from one file. A connector cannot be described one way here and another way inside the app.

Design partners

We're choosing a handful of teams to build with.

What you get

The memory layer under your agents early, tuned to your domain first. We measure token cost, task success and served-stale rate, and hand you the numbers. If they don't show up, you walk with a free audit.

Founder-direct iteration. Your corpus never leaves your environment.

Book 30 minutes