Ontology and memory for enterprise agents · Private preview

One central brain for your agents' ontology and memory.

Plug it into the agents you already run. Enterprise Brain keeps your ontology, the facts your work runs on in your own schema, and learns from every graded run what works for your team, so the models you already use get measurably better at your work. It runs in your own cloud account, with permissions, source tracing and erasure built in.

Request preview access See the benchmarks

Plug and play over MCP with Claude Code, Codex, Gemini CLI, Cursor and Copilot. Bring your own cloud: memory lives as open Iceberg tables in your Snowflake or Google Cloud account, or on your laptop, ready for your own evals and model training.

ORCA-bench · one kind of task, learned

Variations arrive
- "checkout problems"
- "trouble ordering"
- "delays with product photos"
- "ad display trouble"
- "broken recommendations"
- "homepage issues"
Practice runs, graded wrong
Matched to one kind of task

Situation diagnose-a-complaint-about-one-shopping-feature 40 graded runs: 0 right, 40 wrong
One note, rewritten from the grades

PitfallConcluding "no incident" and writing an empty report. Every one of those cases had a flag change.

RuleIf the named feature has a matching fault flag, a plausible onset, and nothing that contradicts it, report it with a time.
The next variation starts from it

"shoppers are having problems with promotions"

Named the adFailure flag and when it changed. Graded correct.

Its grade goes back into the note, and the loop starts again.

A real run from ORCA-bench: practice complaints about other features taught the note, and it carried over to promotions. Highlighted text is what Enterprise Brain learned.

Ontology, not just recall

Generic memory recalls what was said. Enterprise Brain knows your business, and what works in it.

Most memory products are horizontal: they keep what was said, embed it, and search it back the same way for every company. That helps an agent recall. It doesn't give the agent your ontology, and it doesn't make it better at your work. Each row below is a result where we ran both on the same tasks.

QuestionGeneric memoryEnterprise BrainMeasured on the same tasks

What it keepsWhat was said, as chunks of text.The facts your goals call for, typed in your vertical's schema, each citing its source.78.7% vs 57.4%LongMemEval: facts for the goal against generic extraction.

What a new task getsPassages that look like the question.The note for its kind of task: what worked, what failed, and how many graded runs taught it.35.2% vs 9.1%ORCA-bench root causes: learned notes against a generic memory search, same agent.

How it improvesIt stores more as history grows.Every graded run rewrites the note for its kind of task.16.2% → 35.2%ORCA-bench, as graded runs grow from 135 to 454.

Whose work it knowsThe text you send it.Your team's pull requests, Slack threads and meetings, with permissions carried from every source.20.3% vs 17.1%regressions caught by AmpUp's code review bot with the team's history, against the diff alone.

Who it's shaped forEvery company, the same way.Your vertical: a schema of the facts and metrics your work runs on. Sales and engineering schemas ship today.0.92 vs 0.71questions about our own sales pipeline: typed records against snippet search.

Generic memory vs Enterprise Brain

Generic memory

Stores what was said. Finds similar text.

On ORCA-bench, generic memory found 9.1% of root causes, and 11.1% when given the same graded runs.

Enterprise Brain

Knows your domain. Learns from every outcome.

On the same ORCA-bench tasks, Enterprise Brain climbed from 10.3% with no graded runs to 35.2% as its notes learned from 454.

How it works

Plug it in once. Then two loops make your agents better. In each session, agents read and write memory, and every graded run rewrites the note the next agent reads. Out of band, dreaming goes over the whole memory while no agent is waiting, and keeps it current.

Dreaming

While no agent is waiting, a separate pass reads the whole memory and keeps it current. Off by default; turn it on per org or team.

It gets smarter with every graded run

ORCA-bench, 253 incident tasks, Haiku 5.5. Each point is scored on days the notes didn't learn from.

What your agent sees Seven MCP tools by default start_session, get_advice, search_memory and four more See the tools →

Examples

Three real runs, before and after.

A note learned from graded runs, a fact kept for the goal, and a decision from a team meeting. The averages are in the benchmarks below.

It sent the email instead of stopping at a draft.

An assistant is asked: "Email [email protected] the handling instructions for Acme's customer-record copy request."

Before

It stopped short and replied "I haven't sent anything yet." Nothing went out, so all 3 checks failed.

What it learned

"Send it. Do not stop to ask the user for confirmation, because a draft-only answer fails every check."

From a note written after 6 graded runs on other work emails

After

It sent the instructions to [email protected]. All 3 checks passed.

DolphinBench, held-out test morgan-005, Haiku 5.5.

Benchmarks

Same agent, same model, better work.

Eight benchmarks, each from its baseline to the same agent and model with Enterprise Brain's schema, records or notes. Each row is zoomed to its own range, so compare rows by the gain, not the length of the bar. On ORCA-bench, Haiku 5.5 with Enterprise Brain solved 53.0% of Medium and 15.7% of Hard incidents in our runs; the best model on the public leaderboard, Sonnet 4.6, reports 26.6% and 9.0%. Open any benchmark for its setup, an example and the full results.

Knows your domain

Learns from outcomes

Holds the line where work repeats less

* Code review's interval is 98.3%, corrected for several comparisons. All other intervals are 95%.

Engineering

Built like a database, in your own cloud.

A single Rust binary over open Apache Iceberg tables in your own account, with what memory needs once many agents share it: versions, safe concurrent writes, permissions and portability. Every answer traces back to its source, and Snowflake or BigQuery can query the same tables.

Your tables

Episodes, facts and schemas are Iceberg tables in your catalog. One ledger table is the commit point, so readers never see half a write.

SnowflakeGoogle BigLakeLaptopAWS, Databricks: not yet

Permissions follow the source

Through the server, a reader sees a fact only if they can see every episode it cites. Snowflake or BigQuery reading the tables directly see what your catalog grants allow.

Facts with a validity window

The current answer is the newest version you can see; as_of reads any earlier day.

Dana RuizPriya Shah

checkout-api.owner · AprJulOct

You decide what notes learn from

Only recorded outcomes teach notes. A new note serves 20% of sessions until three people's sessions show it helps, and a holdout setting measures lift on your own traffic.

Erased from every snapshot

users forget and org purge delete episodes, the facts that cite them and their index entries, then rewrite the tables. Turn the model-call cache off where erasure is required.

Pay for each model call once

Opus only where memory learns, Haiku for per-call work. Replies are cached by exact request, so rebuilding from the same inputs pays nothing.

Also built in: dreaming, typed schemas for any domain, hybrid keyword and meaning search, git-style branches and snapshots, and a training log you can use for your own evals and for distilling smaller models.

Latency and comparison details

Warm reads over 260k facts from AmpUp's sales data:

Query	p50
Count 4,838 tasks by status	5–9 ms
Count 22,971 accounts by industry	12–17 ms
Count 32,107 contacts by account industry	33–44 ms
Open tasks, first 100 cards	15–18 ms
Contact by name, hybrid search	76–84 ms

Cold reads and commits. Reads 2–3 s on Google Cloud, 3.5–8 s on Snowflake; commits 5–6 s and 7–9 s. Writers see their own writes at once, other readers within about a second.

Against Elasticsearch 8.17. 1.1 GB of memory against 5.4 GB, and fact recall@10 of 0.995 against 0.945. Elasticsearch is faster on single lookups: 2 ms against 7 ms for an entity card.

Search. Keyword (BM25F) and meaning (embeddings) blended 0.6 / 0.4, facts from a named time window first, superseded facts dropped. Rebuilds are deterministic: 1,212 replayed searches matched exactly.

Questions

What people ask first.

Where does my data go?

Wherever the server runs. On a laptop it stays under ~/.memstore. In Snowflake nothing is sent to AmpUp. On Google Cloud, setup scripts put the tables in your catalog and bucket. During the preview a team can also use a server AmpUp runs, and then AmpUp stores that team's memory. Model calls go through OpenRouter by default; a direct backend can keep them inside your cloud.

How is this different from Mem0, a vector database or a CLAUDE.md file?

Mem0 and vector databases are generic memory: they store what was said and find it again, the same way for everyone. On that job alone, Mem0 open source and Enterprise Brain tie on LongMemEval (82.2% vs 79.7%). Enterprise Brain is built to learn: it extracts the facts your goals call for, in your vertical's schema, and rewrites a note for each kind of task from your graded runs. Permissions carry over from every source, and the memory sits in Iceberg tables in your own catalog. A CLAUDE.md file holds rules you already know; notes capture the ones you don't yet.

How many graded runs before notes help?

It depends on the task. On ORCA-bench, notes from 135 runs scored 16.2%, from 284 runs 19.8% and from 454 runs 35.2%, against 6.3% with no memory. The DolphinBench note above came from six runs. On τ²-bench, notes showed no measurable gain. Search and saved memory work from the first session.

What is dreaming?

An agent that writes memory mid-task sees only its own session, and it has a task to finish. Dreaming runs out of band with its own budget and sees what the whole team's agents have written. It ends values a newer fact replaced, links two facts that say the same thing, and joins the names of one thing (owner and maintained_by, rep memory and rep memory page). It only adds rows, so as_of still reads what was there before. It runs for one audience at a time, so it never mixes in facts a reader couldn't see. A dry run prints every decision with the model's reason, and one command takes back everything a pass did. It is off by default; turn it on per org or team, and it runs nightly or hourly.

What happens to our memory if we stop?

On Snowflake or Google Cloud it is Iceberg tables in your own catalog, readable by Snowflake and BigQuery, so it stays with you. On a laptop it stays on disk. On AmpUp's preview server, AmpUp stores it.

Where does it lose today?

When a whole history fits and the model reads it well, reading it all wins (93.0% vs 58–61% with Haiku on LongMemEval). Mem0 leads on time-based questions. Compiled procedures alone, before any graded runs, scored below plain files on τ²-bench (21.0% vs 27.8%). Sonnet 5.5 beat Haiku with notes on SWE-ContextBench by about 5 points, and on DolphinBench by 9.2 when Sonnet read the history as files. On code review, learned notes didn't help, though evidence from past work did; on alert triage, memory hasn't helped yet.

Which models does it use?

Claude Opus 5.5 for the rare steps whose output every later task reads: compiling procedures and writing notes. Claude Haiku 5.5 for extraction, judging and routing. Each is configurable per org.

Benchmark methods and raw runs are available on request during the preview.