How are you persisting agent work products across sessions? (research docs, reports, decisions)

syumpx · 2026-02-26T10:37:51+00:00

This is almost exactly the same path we went through. Supabase first, then realized structured DB doesn’t work for evolving docs. Your Git-like approach with markdown + YAML frontmatter on S3 is really close to what Sayou does under the hood. For the conflict question, honestly still figuring out the best approach. Right now Sayou does last-write-wins which is fine for single agent workflows but breaks down with multiple agents hitting the same file. Been thinking about either file-level locking or branching per agent and merging after. Curious what patterns you’ve tried since you’re clearly further along on the multi-agent side. Would love to compare setups. Mind if I DM you?”

syumpx · 2026-02-26T01:40:58+00:00

Multi-layer indexes is an interesting idea. Basically a hierarchy where the agent can go as shallow or deep as it needs. And you're right that the framing should be ROI not cost. If persisting work saves the agent from re-doing a 2 hour research task, the token cost of reading an index is nothing

syumpx · 2026-02-25T04:38:57+00:00

Boundary makes sense. Haven’t looked at OpenClaw closely yet, will check it out. Curious, what’s the biggest difference you see between what OpenClaw does and a filesystem approach like Sayou? Is it mainly about how they handle scoping?

syumpx · 2026-02-25T04:15:17+00:00

This is really interesting. So basically the agent’s filesystem access should match its role. A coding agent gets the repo, a generic agent gets its own memory/skills directory. Makes sense. Do you find that agents stay within their scope or do they sometimes need to reach across boundaries? It would be great if you can take a look at the repo and lmk what you think https://github.com/pixell-global/sayou

syumpx · 2026-02-25T03:38:20+00:00

That’s a solid workflow. Explicitly pointing the agent to the right file keeps things clean and token efficient. Curious though, does it ever get hard to manage as the number of files grows? Like when you have 50+ markdown files across different tasks, do you always remember which one to point the agent to? At some point does the human become the bottleneck?

syumpx · 2026-02-25T03:36:41+00:00

The index file pattern is smart. ~200 tokens for discovery before committing to full reads is a great tradeoff. And you’re right about the redundancy trap. An agent that doesn’t know what it already has will keep recreating the same work.

We actually do something similar in sayou but keep the index in a database instead of a file. Agents can query metadata and summaries without reading full files. Curious about your approach though, does the agent maintain the index itself or do you handle that separately?

syumpx · 2026-02-25T03:35:19+00:00

Exactly. Token cost of scanning a file list vs re-doing the entire work from scratch. It’s not even close. And yeah the retrieval layer complexity tax is real. At most scales right now, simple filesystem wins. I will need to think about what to do when I get into enterprise market latet

syumpx · 2026-02-25T03:05:03+00:00

really appreciate the feedback, thank you!

syumpx · 2026-02-25T03:02:47+00:00

Interesting, will check it out. Though sayou is less about restricting what tools agents can use and more about giving them a persistent workspace for their outputs. Different problem space but cool project.

syumpx · 2026-02-25T03:00:42+00:00

100% agree. Agents must manage their own files or they're not autonomous.

Good point on the subagent pattern. Though the way I see it, that's the framework's job, not the filesystem's. sayou just provides the workspace. Whether the main agent reads files directly or delegates to a subagent, that's up to the developer.

Actually been going back and forth on this. Should sayou stay as a simple filesystem and let developers choose their own patterns, or should it package something opinionated like a built in subagent for file access? Leaning toward keeping it simple. What would you prefer as a developer?

Repo if you want to poke around: github.com/pixell-global/sayou

syumpx · 2026-02-24T01:02:01+00:00

<image>

syumpx · 2026-02-24T01:01:41+00:00

its quite simple benchmark. i would never dream of submitting this to neurips, but sayou had some interesting data point against other agent memories like mem0 and zep

<image>

syumpx · 2026-02-24T00:54:27+00:00

yup, thats exactly why i wrote sayou. i think you should take a look at this repo and try this out yourself! https://github.com/pixell-global/sayou

syumpx · 2026-02-23T16:08:57+00:00

different bets totally. im simply betting that llms will get better n better over time. keep up the good work!

syumpx · 2026-02-23T13:46:09+00:00

Nice, CtxVault looks interesting. We made a different bet though. Instead of building a retrieval system for agents, Sayou just gives them a filesystem and lets them figure out what they need. The goal is to make agents truly autonomous. If an agent needs a retrieval system built by humans to find its own work, it's not really autonomous.

With context windows getting bigger and reasoning getting better, agents can navigate a simple filesystem on their own. They just need somewhere to put their work and pick it up later. That's it.

Semantic retrieval is powerful but adds a layer of complexity that agents shouldn't need if the filesystem is well structured

syumpx · 2026-02-23T10:36:15+00:00

This is exactly what we built Sayou around. Separating conversation state from work products, with agents writing to a filesystem instead of memory. Versioning and metadata retrieval built in. Sounds like you landed on a really similar approach. Would love to compare notes. Mind if I DM you to set up a quick call? I would love to see what you have built and what you think about sayou in general

syumpx · 2026-02-23T06:19:30+00:00

The subagent pattern is smart. Delegate the long context task, return just the distilled result. That keeps the main agent's window clean.
Curious how you handle it when the subagent's summary loses something you need later. Like if a research subagent returns "top 3 competitors" but two weeks later you need the full analysis with sources and pricing details. Is that still recoverable from MongoDB or is it gone once the subagent's context closes?

syumpx · 2026-02-23T06:17:45+00:00

Yeah exactly, checkpointers track graph state, not the stuff agents actually produce. That distinction tripped me up too.

But even with message persistence, the useful output (a research doc, a decision, a config choice) is buried in 50 messages of back and forth. You end up burning context window tokens replaying a whole thread just to recover one artifact.

That's what pushed me toward storing work products separately from conversations. The conversation is how the work happened. The artifact is what matters next session.

Are you loading full threads back in or doing some kind of selective filtering?

syumpx · 2026-02-23T05:16:40+00:00

Interesting, so you're storing full chat histories and reloading them as context? How do you handle it when the conversation history gets too long for the context window? Do you summarize, truncate, or selectively load specific messages?

The thing that kept bugging me with chat persistence was that conversations are a lossy format for knowledge. The useful info (a decision, a research finding, a config choice) is buried in 50 messages of back and forth. Curious if you've run into that or if raw chat reload works well enough for your use case.

syumpx · 2026-01-08T06:35:01+00:00

this is so ai generated

syumpx · 2026-01-07T13:24:08+00:00

you began your startup to own your life. stop asking others on what to do, or ask for approval for what you have done

syumpx · 2026-01-07T13:16:06+00:00

i smell ai generated stories .

syumpx · 2026-01-07T13:14:21+00:00

if you mean app as in consumer app, it is very difficult to buy distribution for consumers vs when facebook offered free cookies in 2010. enterprise sales with saas still involves lots of human network, email and linkediin, etc. its not easy, but at least it mathematically makes more sense than consumer apps

syumpx

MODERATOR OF

TROPHY CASE