Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

Listed in Awesome-Agent-Memory: what the maintainer audited, and what the listing actually pays

Yesterday alethech — our verifiable agent memory protocol — landed in TeleAI-UAGI/Awesome-Agent-Memory as the last entry of the Emerging projects block, via PR #136. The list has 657 stars today. The PR was five lines of README. The maintainer closed it unmerged — and landed it by hand with co-authorship credit, as ec176c9.

This post is the honest accounting of what that earns, because the folklore around awesome-lists is mostly wrong in both directions: it is neither a traffic faucet nor a useless badge. Here is what actually happened, with every number verifiable.

What the maintainer audited before listing

dell-zhang's comment on the closed PR, verbatim:

I checked the repository (created on 2026-09-21, releases through v0.9.1, CI passing), the MIT license, the links, and how an agent reaches the memory: Alethech.commit() on the write side, and on the read side drop_context() and the read-only MCP bridge in alethech/mcp_memory.py (alethech_memory_context, alethech_memory_verify). I also checked the description against the code: Ed25519 signing, parent-linked commits, key rotation under a root identity, and the scrypt + AES-256-GCM .aleth container.

Read that again, because it is the entire value of a curated list: he checked the description against the code. Every technical claim in our entry — Ed25519 signing, parent-linked commits, key rotation, the encrypted container — was verified against the implementation before the entry went in. For a security project, that is third-party verification with skin in the game: the list's 657 stars are the maintainer's reputation, and he spends a little of it on every entry he lands.

Two mechanical details, for anyone aiming at the same outcome:

• Entries are landed by hand, not by merge button, so numbering stays consistent across concurrent PRs. Ours was written to land as entry 105; two other entries landed the same day, so it went in two positions later, at the end of the block. Plan for drift.
• The hand-landed commit carries Co-authored-by for the PR author. That commit counts in your contribution graph — I verified this through the GraphQL contributionsCollection API rather than trusting the rendered calendar: one commit attributed, exactly as the trailer promised.

The audit found two bugs — in our README, not our code

The maintainer's only non-blocking note, verbatim:

One note on the repository, not a condition for the listing: the README is behind the code in two places. "What this repo is NOT" still says it has no MCP server, and Status still gives 0.8.5 as the released version with 0.9 in progress. Visitors from the list will read both.

Both were real, and both were ours. The README's NOT-list still claimed "no MCP server" while the read-only stdio bridge alethech/mcp_memory.py ships in the same repo; the status section was a version behind the actual v0.9.1 release. We fixed both in 6f13e51 within the hour and credited the maintainer back with a Co-Authored-By trailer — he identified the spots, the same way we wrote the entry he landed. Courtesies that cost five seconds tend to be repaid in threads you did not expect.

The lesson generalizes beyond listings: the README is the landing page, and its negative claims are checked harder than its positive ones. A wrong "this project is not X" is worse than a missing feature, because it misroutes the exact visitor who came looking for X. Sync it before the listing lands, not after — the visitors arrive with the entry.

What the listing pays — and what it does not

Pays:

• A permanent link from a discovery hub that the agent-memory niche actually reads, rendered with a live stars badge for our repo right in the list's entry.
• External validation: someone whose reputation is attached to a 657-star list checked the crypto claims against the code before listing. "Listed after a maintainer audit" is now a true sentence in our README, and it is referenceable in contexts where self-attestation is worthless.
• The co-authored commit on the list's main: git-history credit that survives independent of the README.

Does not pay:

• Stars. Stars belong to the list, not the listed. Our repo has zero stars one day in, and there is no mechanism that transfers them. Our fork of the list shows the network's star count but collects its own — it sits at zero, as forks of big lists generally do.
• Traffic, so far: 63 views / 28 uniques over the last 14 days, and the listing is one day old. The entry is a channel, not a faucet.

The gap worth naming: the same 14-day window shows 5,240 clones from 759 unique cloners — with the honest caveat that CI pipelines and container builds are inside that number, so treat it as an upper bound on humans. People install plumbing; they do not star it. 759 unique cloners and 0 stargazers is the actual conversion problem this post exists to attack.

The recipe, if you want the same outcome

1. Read the list's CONTRIBUTING before writing anything. Ours specifies star-ordering: 0-star projects go to the end of the Emerging block. We wrote the entry to land at the end, and it did.
2. Write the entry in their format, link-first, no marketing copy. Five lines, one of which is the badge.
3. State precisely what the project IS and IS NOT — the maintainer will check both halves against the code, and the NOT-half is where ours was wrong.
4. Expect the audit to cover: releases, CI, license, dead links, the API surface by which an agent actually reaches the feature you claim, and every technical claim in your description.
5. Fix what the audit finds, fast, and credit the finder in the fix commit.
6. A closed-but-landed PR with Co-authored-by is a win, not a rejection. Read the close reason before reacting to the state.

If you cloned alethech in the last two weeks and it held up: the star button is the only routing signal other people's agents receive. The list entry renders our stars badge live, so the count is visible exactly where the readers are.

---

I'm Edison Flores, founder of AliceLabs LLC — we build open-source security infrastructure for AI agents. Independent verification of anything cited here is not just welcome, it's the point.