AI Agents Can Do the Work. But Who Remembers Why?

AI agents are becoming increasingly capable.

They can write code, execute workflows, call APIs, search documents, and interact with applications.

But I've been thinking about a different problem.

What happens to the knowledge created while all that work is happening?

Not just the outputs or documents. I'm talking about the decisions, reasoning, and context that explain why something was done.

And what happens when that knowledge was never documented in the first place?

The problem isn't just information retrieval

Recently, I spoke with a team working in a research-intensive environment.

Their researchers run experiments, analyze measurements, and make technical decisions every day.

Some information lives in Google Drive. Some gets documented in Confluence. But important decisions also happen during quick conversations between senior and junior researchers.

A senior researcher might explain why they should change an experimental configuration. The junior researcher follows that guidance, and the work continues.

But the reasoning behind that decision may never make it into documentation.

Months later, someone asks:

"Why did we stop using this configuration?"

The experimental data still exists. The measurements are available. But nobody can easily reconstruct the original reasoning.

This is where I started questioning something fundamental:

Is connecting an LLM to Google Drive really enough to solve organizational knowledge management?

RAG helps us retrieve existing information.

But retrieval cannot recover knowledge that was never captured.

From document search to organizational memory

This is one of the problems we're exploring while building Folio.

Rather than creating another chatbot that searches company documents, we're thinking about a persistent memory layer that AI agents can use across different workflows.

The idea is relatively simple:

1. Connect to existing company information sources.
2. Detect new or changed information.
3. Identify what is worth remembering.
4. Distill relevant information into project-level memory.
5. Let authorized agents retrieve that memory and act on it.
6. Capture new decisions and feed them back into memory.

Think of it as a continuous knowledge loop rather than a one-time indexing process.

For example, imagine this workflow:

An engineer completes a measurement run.

The results are saved to Google Drive.

Folio detects the new information and associates it with the relevant project.

But the measurement alone doesn't explain why the team changed its approach.

So an assistant asks the engineer in Slack:

"What changed in this run, and why?"

The engineer provides a short explanation. Folio drafts a decision note, and the engineer approves it.

Three months later, another engineer asks why the configuration changed.

The assistant can retrieve the approved explanation, connect it to the original experiment, and provide the supporting evidence.

No separate documentation session required.

That's the experience we're working toward.

The architecture challenge

I see several important components in this system.

Source ingestion

We need connectors to systems like Google Drive, Slack, and Confluence.

Ideally, ingestion is incremental. Instead of repeatedly processing every document, we detect changes and process only the relevant updates.

Memory distillation

This is where things become interesting.

Not every document should become a permanent memory.

Some documents contain temporary information. Others contain important technical decisions, project history, or knowledge that could be useful years later.

How do we determine what deserves to be remembered?

And how do we prevent an LLM from turning an incorrect interpretation into institutional knowledge?

My current thinking is to preserve source evidence, distinguish observations from inferred conclusions, and require human confirmation for consequential decisions.

Permission-aware memory

This might be one of the most challenging parts.

Imagine a company with multiple research labs.

Researcher A has access to Lab A.

Researcher B has access to Lab B.

An executive might have access to both.

Now imagine an LLM distilling information from both labs into a shared summary.

Who should be allowed to retrieve that summary?

A simple project-level filter isn't necessarily enough.

Derived memories need to preserve their access restrictions and provenance. When multiple sources contribute to a memory, the system must ensure that the result doesn't expose restricted information to unauthorized users.

Authorization needs to happen before restricted context reaches the model, not simply after an answer has been generated.

And when agents execute tasks on behalf of humans, the system needs to account for both the agent's permissions and the requesting user's permissions.

Agent execution

The execution layer can be separate from the memory layer.

An agent might operate through Slack, a CLI, or a dedicated application.

The underlying organizational memory should remain accessible through a consistent, permission-aware interface.

This separation could allow teams to change their agent frameworks without losing the context accumulated over time.

Should AI remember everything?

Probably not.

If we summarize every document, memory quickly becomes noisy.

If we only remember major decisions, we might miss the small observations that become important later.

And if we continuously rewrite summaries, important historical context might disappear.

I'm interested in a hybrid approach:

Keep a lightweight registry of sources, preserve meaningful knowledge as structured memory, and retrieve original evidence when needed.

Memory should help agents understand context, but it shouldn't automatically replace the underlying source of truth.

What we're exploring next

We're starting with a relatively narrow use case: research project memory.

The goal is to help teams recover past decisions, understand experimental history, and capture new knowledge without introducing a complicated new workflow.

There are still plenty of open questions around memory quality, incremental updates, access control, and researcher adoption.

But the broader opportunity is exciting.

Today, we're building agents that can perform more and more work.

I think the next challenge is building systems that allow organizations to retain and reuse the knowledge generated by that work.

Because an agent that can complete a task is useful.

An organization that can remember why the task was completed a certain way may be much more valuable.

I'm curious how other developers are approaching this.

Are you building persistent memory for AI agents? Are you using RAG, knowledge graphs, Markdown files, or something else?

And how are you dealing with permissions when multiple agents share organizational context?

I'd love to learn from what others are building.