Research · launch

Hello, Persistent Intelligence

Announcing our $35M Series A.

By Arbaaz Khan, Founder & CEO

Today, we’re announcing our $35 million Series A, led by RRE Ventures, just six months after our seed announcement, bringing our total capital raised to $43 million. We’re using it to bring this infrastructure to developers and enterprises. Eventually, we’ll bring it to the cloud, to on-prem and to consumer devices. Today, when people say memory, they mean storage: chips and drives that hold bytes. Graphon Labs is ushering in software as memory, where what you keep is understood, not just stored.

01 · motivation

The Motivation

We should be able to ask a computer about our lives as easily as we ask it about the internet.

The story your father told at dinner. The place you went with someone years ago. The advice you recorded and only understood much later. You remember enough to ask, but not enough to know which file to open.

We have the photos, the videos, the conversations. I want to be able to talk to all of it. Ask a question in my own words and get back the moment I was looking for, with enough of what came before and after to make sense of it.

This is something we have wanted to build for a long time. And watching language models get so much better has made one question increasingly frustrating: why is it still so hard to give them an understanding of our own world?

you ask

What was the story Mom told at dinner about walking to school?

the moment, with enough of before and after to make sense of it

Before starting Graphon, I worked as an applied scientist on Amazon’s Customer Service team. Customer service gives you a particular appreciation for the distance between an answer that sounds reasonable and one that is actually right.

Closing the distance

Across the industry, the approaches to closing that distance have changed considerably.

Before ChatGPT, a common way to automate customer service at scale involved training classifiers. A customer typed “didn’t deliver,” a model identified the likely intent, and a predefined decision tree took it from there. A lot of engineering went into figuring out which branch someone belonged on.

Then language models changed everyone’s expectations.

You could take an off-the-shelf, open-source model, give it instructions, and have it interpret a request and generate a response. Zero-shot prompting made a compelling demo remarkably easy to build. Getting something consistently reliable enough for production was harder.

So the industry went deep into fine-tuning.

This was the day and age of model merging, low-rank adapters, and trying funny things with freezing different layers to see whether it made any difference. Many a PhD was burned—and is still being burned—babysitting data instead of inventing new layer-normalization techniques.

Fine-tuning helped. But enterprise knowledge refuses to sit still. Policies change. Products change. Something that was correct when you assembled the training dataset can be wrong by the time a customer asks about it. Continuously fine-tuning a model to keep up comes with its own problems.

Enter RAG.

The idea was sensible. Fine-tune the model for how it should behave—how to sound like a customer-service representative or a pirate—and use retrieval to find the latest information to feed into its context window. A policy change could go into the knowledge source without requiring another training run.

This opened up a new can of worms.

Now you had to make sure the embedding models worked on your data. You had to invent the right chunking strategies. Decide how much overlap to add. Figure out how much to retrieve and whether it would fit into the downstream model’s context window.

For the longest time, chunking felt like a pseudoscience. A recipe worked on one dataset and fell apart on another.

And semantic similarity could blur precisely the distinctions that mattered.

“Can offer a refund” and “can’t offer a refund” concern the same topic and share almost all their words. They can sit close together in an embedding space. But the difference determines what the agent is allowed to do.

“The correct voltage is 70 V” and “the correct voltage is 770 V” look almost identical. The number is the part you cannot afford to get wrong.

Of course, you can add rerankers, exact matching, filters, and checks. Then maintain and evaluate all of them as your data changes. You can retrieve more passages to improve your chances of finding the missing detail, then pay to have the model read them. Before long, you’re operating an elaborate retrieval stack just to get the right information in front of the model.

And even a relevant passage can leave out the thing that makes it useful. The exception is in another section. The warning comes before the procedure. The explanation is spoken while someone points to a part in a video.

Simplified illustration of common retrieval pitfalls, not a measurement.
Text version
  1. A short refund policy (“We can offer a refund within 30 days of purchase. Items must be unused, in their original box. We can’t offer a refund on sale items. Exchanges are always free.”) is cut into overlapping chunks. Someone has to choose the embedding model, the chunk size, the overlap, how many chunks come back, and whether they fit the model’s context window.
  2. The same settings on another dataset put a cut in the middle of the rule: “We can’t offer a refund on” lands in one chunk and “sale items.” in the next.
  3. In embedding space, “can offer a refund” and “can’t offer a refund” sit almost on top of each other, though they give opposite answers.
  4. So do “the correct voltage is 70 V” and “the correct voltage is 770 V”, one digit apart.
  5. To cope, the stack grows: a reranker, exact matching, filters and checks, each to maintain, and the model is given more passages to read.
  6. Asked “Can I get a refund on a sale item?”, the passage that comes back says refunds are offered within 30 days. The exception for sale items is in another chunk.

An analogy: storing a book in a trashcan

Here’s the analogy I keep coming back to.

I give you a book and ask you to store it. You tear each page out, crumple it into a ball, and throw it into a trashcan.

Then I ask you a question.

You search through the trashcan and hope you find all the crumpled-up pieces of paper needed to answer it. Maybe you find the rule but miss the exception. Maybe you find step four without the warning before step one.

The words are still there. The structure that made them useful is much harder to recover.

And we spent extraordinary amounts of effort building a bigger trashcan, a better crumpled ball, and a faster way to rummage.

Illustrative retrieval failure: relevant passages can still leave out essential context.
Text version

Mom’s five-page scrapbook about her school days is torn into pages, crumpled and thrown in a basket. Asked “How far did Mom really walk to school?”, a search through the basket brings back the three pages that look most like an answer and leaves two behind.

  1. Page 1 · School days. “Mom’s school. 1979. She was 12.” Retrieved.
  2. Page 2 · Bus pass. “Route 7. Two stops.” Left in the basket: the bus pass is missed.
  3. Page 3 · Mom’s version. “Five miles. Every day. Uphill, both ways.” Sunday dinner, 2019. Retrieved: Mom’s version is found.
  4. Page 4 · In the margin. “The school was across the road.” Her brother. Left in the basket: her brother is missed.
  5. Page 5 · Mom’s map. A long winding road over the hills from home to school, drawn for the grandkids in 2015. Retrieved.

The answer that comes back is five miles, uphill. A bigger basket and faster rummaging bring back more pages, but nothing ties Mom’s version to the bus pass or to her brother.

My objection is to the premise: why are we throwing away useful structure in the first place?

If we want AI to understand the information we accumulate—across our lives, our work, and all the different ways we record it—we have to take seriously how that information is organized. What happened before and after. Which explanation belongs to which demonstration. How a detail in one source changes the meaning of something in another.

That is the problem we’re building Graphon to solve.

02 · solution

The Solution

Two graph theory PhDs walk into a bar.

A painting, from a photograph, of Arbaaz explaining the Memory Augmented Control Networks poster to a visitor at a poster session, with Clark standing at the right of the board.
Clark and me, during our PhDs, presenting Memory Augmented Control Networks at ICLR 2018.

Clark and I spent the better part of our youth building graph-based solutions for robots: helping them remember where they had been, navigate places they hadn’t seen, and communicate in unknown, unstructured environments.

The graphs were sometimes explicit, sometimes implicit. But the thinking was consistent: exploit the structure of the problem. What a robot observes now relates to what it saw earlier. What one robot knows might fill a gap in another’s understanding. Those relationships are useful information in their own right.

Two ideas

We brought that thinking to Graphon.

We built around two ideas.

First, build a graph detailed enough to represent the information in the data, without having to decide every useful relationship in advance.

And yes, that means messy data. Videos, images, spreadsheets, recordings, Markdown files. The stuff people actually create.

A video has events within scenes. A spreadsheet has values whose meaning depends on row and column headers. A document has rules, exceptions, and references to other documents. A spoken explanation might only make sense alongside what someone is showing on screen.

Our hypothesis was that graphs could preserve and connect this structure far better than a collection of independently retrieved vectors.

But “put it in a graph” is where a lot of explanations stop, and where another difficult problem starts.

The more detail you preserve, the larger and denser that graph becomes. A question might require one precise fact. Another might require following relationships across several sources. You need a way to find the relevant evidence without wandering through every possible connection.

After all, the time complexity of Dijkstra’s algorithm is O(E + V log V).

That was our second idea: build a compressed representation of the graph—a graphon—to guide retrieval through it.

The graph captures the details and their relationships. The graphon gives us a way to reason about the larger structure and use it to guide where we look. These two pieces have to work together. A rich representation is only useful if you can retrieve from it effectively.

Conceptual illustration, not a live product result. Tab to a thread, or hover or tap it, to read the relationship.
Text version

The same scrapbook comes back, its pages intact, as one patch of a larger fabric built from forty years of family files. Four more sources join it: the 2019 Sunday dinner video with its moments, a photo of Mom outside her school in 1979, the index of home movies and her brother’s texts. Threads join specific parts of them:

    Asked “How far did Mom really walk to school?”, the compact overview points to the cluster about Mom’s school days, and the evidence that comes back is the bus pass, a 1979 letter (“I can hear the bell from bed”) and Mom’s own telling from 1998, when it was still “about a mile”, each linked to its source. By 2019 it was five miles, uphill both ways.

    From ideas to a system

    Then came the engineering.

    We spent the last year or so turning these ideas into a system that could ingest real data, build and maintain that structure, and answer questions over it at scale. The system has to handle different file types, incorporate new information, and trace retrieved evidence back to the source. It has to do this at a cost and speed that make it practical to use.

    The test is whether this work produces better answers.

    Can it find a detail buried in a video? Connect that detail to an explanation in another source? Recover enough evidence to answer a question completely? And how does it compare with a well-tuned retrieval stack on the same data?

    We think the results speak for themselves.

    the benchmarks

    Results

    The most accurate memory system on every benchmark, across video, audio and text, at a fraction of the cost of full context.

    ATM-Bench ↗

    The first benchmark for multimodal, multi-source personalized referential memory QA over 3.3 GB of raw multimodal data spanning ~4 years, with evidence-grounded retrieval and answering.

    Graphon is #1 and #2 on the leaderboard.

    ATM-Bench / memory systems better
    QA score (%)Recall@10 (%)
    Best run per system, from the public ATM-Bench leaderboard. The models behind each run and the full results are on the leaderboard. GraphonOthers
    Source: atmbench.github.io/leaderboard ↗

    These results are a checkpoint on a much larger ambition: making the information we accumulate useful long after the moment we first recorded it.

    Building with Graphon

    Developers shouldn’t have to understand the mathematics underneath Graphon to build with it.

    So we built an interface around concepts they already know: S3-style storage and search. Buckets, objects, files, queries. You put data in, and Graphon builds the structure that makes it searchable.

    From there, you can run keyword and semantic searches, search using an image, or ask questions that require an agent to follow connections across multiple sources. A straightforward lookup and a deeper investigation use the same underlying platform.

    bucket family14,926 objects
    • moms-scrapbook.pdf
    • school-1979.jpg
    • sunday-dinner-1998.mp4
    • new-year-2009.mp4
    • sunday-dinner-2019.mp4
    • brother-texts.txt
    • + 14,920 more
    Illustrative interface, not a live response or the actual API. The modes are the ones named above; the docs have the real calls.

    That means a developer can start with search over a collection of files and build toward something much more capable without assembling a separate system for every kind of question.

    For a person, the ambition is the one we started with: being able to ask about your own world and find the pieces that matter.

    Memory that persists.