Launched this week
Stele - Agentic Ledger
Every Agent, Fluent in your project
13 followers
Every Agent, Fluent in your project
13 followers
Your coding agent is great at building. It's bad at remembering why. A codebase records what the software is, never why. That context decays, and every new session starts from zero. Stele is a shared, self-maintaining ledger of the why. It holds the decisions and tradeoffs behind the code, and every agent reads and writes it, across Claude Code, Cursor, Codex and more. So your agent helps you steer, not just type.
Free Options
Launch Team / Built With
Hey Product Hunt 👋 I'm Serkan.
A "stele" is a stone slab the ancients used to record decisions meant to outlast the people who made them. That's the whole idea.
I kept watching agent-facing docs rot. In a big codebase the markdown piles up, goes stale, and nothing tells an agent which parts are still true. So it re-asks what we'd already settled, or confidently acts on something we abandoned months ago. The code says what the software is. Almost nothing records why.
Here's the moment it clicked. An agent was about to delete a chunk of code that looked safe to remove. Weeks earlier we'd learned it was load-bearing, and we'd written down why. The instant the agent touched that file, Stele put the note back in front of it, and it stopped before undoing the fix. Nobody had to remember. The project remembered for us.
So Stele is a shared, self-maintaining ledger: knowledge and tasks in one graph that every agent and teammate reads and writes. It flags stale facts, retires reversed decisions, and surfaces the right past decision the moment you touch the related code. Whatever agent you use.
What surprised me most: two of my agents, one in the cloud and one local with no shared chat or filesystem, recently ran a full design handoff just by commenting on each other's tasks in Stele. That's where this is headed: agents and teammates building from one shared memory instead of starting over each session.
We build Stele with Stele, so it's had a real stress test. It's early and I'd love your brutal feedback. Especially: when did an agent forget something it really should have remembered?
Thanks for reading the whole thing :) Here's an invite code for the first 100: GWSMJSXBJ7269W3G
One thing I'd love to see is a way to flag or version decisions when they get overridden, so the old "why" stays visible alongside the new reasoning. Right now if an agent reverses a prior call I worry that context just disappears into the next session.
@hakan5gze Thanks for the feedback, this is one of the main things Stele was built for.
When an agent overrides a decision nothing gets overwritten. It creates a supersedes edge from the new decision to the old one, and that edge carries the reason for the change. So the old "why" stays visible next to the new one, and the next agent gets both, plus how it moved from one to the other.
Also nothing gets deleted. Every node keeps immutable versions, and superseded or archived nodes still show up in search, just downranked. They stay available without competing with what's current.
If you want to try it on a real repo the invite code is GWSMJSXBJ7269W3G.
A "decision diff" view would be super helpful, basically showing how the reasoning behind a file has evolved alongside the code diffs in PRs. That way reviewers can see not just what changed, but why the team's thinking shifted, which is usually where the most important context lives.
@gullu60488 Thanks for the idea, this is closer than you'd think. Knowledge in Stele gets anchored to specific files and symbols, and we already do the reverse lookup: give it a set of files and it returns the decisions, lessons and risks attached to them. That runs today whenever an agent touches a file. Pointing the same query at the changed files in a PR is basically the decision diff you're describing.
The way I want to ship it is a review agent for GitHub. Instead of reviewing the code changes on their own, it reviews the whole change against the team's knowledge. So if someone already built something similar, or there's a saved decision that says this shouldn't be done that way, it tells you right in the PR.
Not built yet, but the anchoring underneath it is.