One team · nine ninjas · no standup
How we use Recallium to build Recallium.
Six engineers, a performance lead, a security reviewer and a go-to-market lead, on different branches, at different hours, in different tools. Nobody briefs anybody. Here is one day. The ninjas are made up; the mechanics are the ones we use.
- 0 meetings
- 7 min to feedback
- 0 engineers interrupted
- 0 “where were we?”
Rate limiter moved to a token bucket per organization. Rejected: a bucket per key. Parked: the load test is next.
The agent opens on last night’s note: what changed, what was rejected, what is next. Read with the coffee still pouring.
✗ the standupBefore the first edit, Recallium finds NINJA#2’s constraint and feeds it to the agent: cursors must stay stable under writes. Offset pagination is dead before it is proposed.
✗ the rewriteAn SDK bug stored at 09:41 is in NINJA#1’s session by 09:48 and fixed by NINJA#4 at 10:20. Three people, three tools, zero messages.
✗ the “hey, FYI” messageThe PR opens with the design, the rejected options and the load-test numbers already in view. The finding becomes a team rule.
✗ the “so what is this?” hourIn Claude Desktop, with no repository: “what shipped this week that pilot customers can use?” Drafted by 13:30.
✗ the “what shipped?” threadThe trailer points at the decision and the finding behind the change. “Why is this here?” is answered in six months.
✗ the archaeologyWhat is mid-way, what is next, which decisions it rests on. Whoever opens the project first continues.
✗ “where were we?”- DEV NINJA#1 · the API
- DEV NINJA#2 · the engine
- DEV NINJA#3 · this website
- DEV NINJA#4 · the SDK
- DEV NINJA#5 · infra
- UI NINJA · design
- PERF NINJA · the numbers
- SECURITY NINJA · reviews
- GTM NINJA · Claude Desktop
What the team gets back.
Not a nicer log. Time, and fewer mistakes. These are the things that stop happening when every agent on the team reads and writes the same memory.
A bug found on the website at 09:41 is in front of the API engineer's agent at 09:48, before a line changes. Nobody forwarded it. By 10:20 the SDK fix is shipped, tied to the finding.
DEV NINJA#3 → DEV NINJA#1 → DEV NINJA#4, three tools, zero messages.
Every session opens on what changed overnight, what was rejected and why, and what is next. It interrupts nobody.
The latest decision wins and the old one stays on record with the reason it changed. Agents stop proposing what the team walked away from.
GTM asks the memory in Claude Desktop what shipped this week and gets the why in plain words. Features reach customers the day they merge.
The security review opens with the design, the rejected options and the numbers already in view. Its finding becomes a rule every session loads.
A trailer ties each commit to the decision and the finding behind it. “Why is this here?” has an answer that does not depend on who is still around.
Work parked at 18:05 is picked up by whoever opens the project first, person or agent, from exactly where it stopped.
Claude Code, Codex, Cursor and Claude Desktop all read and write the same thing. Switch tools, switch models, keep the team's memory.
One day, nine ninjas.
Every moment below is something that happens in a normal week here. The agent does the remembering; the people do the work.
The standup happened while NINJA#1 was asleep.
Restored last night's note, the working state and the two open workstreams before the first prompt was typed.
Read it with the coffee still pouring, then started on pagination. Four seconds, no meeting.
At 11:52 PM, DEV NINJA#2 changed the shape of the rate limiter and went to bed. At 07:40, NINJA#1's agent opens on that note: what changed, what was rejected and why, what is next. Nobody wrote a summary. Nobody waited for 9:30.
Rate limiter: fixed window → token bucket per organization. PR open. Rejected: a bucket per API key, because a team shares one key. Next: the load test.
A mistake that never got made.
Was handed NINJA#2's constraint by Recallium before editing, and dropped offset pagination from its own plan.
Described the task in one line, read the plan, approved cursors. Never had to remember the constraint.
The task is cursor pagination for the search endpoint. Before the agent writes a line, Recallium finds what NINJA#2 recorded last week after a bad night in the pilot, and feeds it to the agent.
Cursors on the search endpoint must stay stable while memories are being written. Offset pagination skipped rows under load. Files: api/search/list.go
Offset pagination is dead before it is proposed. Nobody had to remember to mention it.
Found on the website. Felt in the API. Fixed in the SDK. Before lunch.
NINJA#3's agent stored the root cause and the fix mid-session. Recallium put the finding in front of NINJA#1's agent before it touched the limiter. NINJA#4's agent shipped the SDK fix tied to the finding.
NINJA#3 kept wiring the form. NINJA#1 kept working on the limiter. NINJA#4 reviewed one diff. Nobody wrote a message.
NINJA#3 is wiring the waitlist form and sees the SDK retry a 429 instantly, ignoringRetry-After. The agent stores the root cause while NINJA#3 is still typing.
Root cause: the SDK's retry helper treats 429 like a network error. Fix: honour Retry-After, cap at 30 s. Why it matters: the new per-organization limiter will see a burst from every client with this bug.
09:48: NINJA#1's agent, about to touch the limiter, is handed the finding by Recallium. 10:20: NINJA#4's agent, in the SDK repo, ships the fix tied to the finding. Three people, three tools, zero messages.
Numbers that cannot get lost.
Stored the load-test setup and results next to the limiter decision they measure, so the next proposal reads them first.
PERF NINJA ran the test. DEV NINJA#5 watched the cluster. Neither wrote a wiki page.
PERF NINJA runs the load test against the new limiter, on the cluster DEV NINJA#5 stood up for it. The numbers go in next to the decision they measure, with the setup that produced them. The next agent that proposes a limiter change reads them before it proposes anything. A result nobody can find is a result that gets re-run. These are found by the thing they are about.
A review that starts at the interesting part.
Opened the PR with the design, the rejected options and the numbers in view, stored the finding during the review, and proposed the team rule.
Read the interesting part, judged the risk, approved the rule. Skipped the “so what is this?” hour.
SECURITY NINJA opens the limiter PR. The agent brings the design, the rejected per-key bucket and the reason, and the load-test numbers, before a single file is read. The review skips the “so what is this?” hour.
Organization IDs are written to the debug log on every limiter decision. Log a hash, keep the raw ID out of the pipeline. Blocks merge until fixed. Files: api/limiter/bucket.go, api/limiter/log.go
NINJA#2's agent sees it the next time it opens the PR. And it becomes a rule for the whole team, loaded in every session from now on: no raw identifiers in debug logs.
The release note writes itself, from the same memory.
Answered “what shipped this week?” from the memory, in plain words, with the why behind each change.
GTM NINJA wrote the release note by 13:30 without asking an engineer anything.
GTM NINJA has never cloned a repository. In Claude Desktop, connected to the same memory, one question: what shipped this week that the pilot customers can use?
Rate limits are now per organization. A busy script on one key no longer slows the rest of the team.
Search pages stay stable while memories are being written. No more skipped rows on long lists.
SDK retries respect the server's wait time. Clients back off instead of hammering.
The release note is drafted by 13:30. Features reach the customer story the day they merge. No engineer was asked what they did this week.
Every number remembers which build it belongs to.
Tagged the benchmark results with the build, the reader, the judge and every miss, next to the engine change that caused the re-run.
PERF NINJA read the numbers and picked the next target.
The engine changed, so PERF NINJA re-runs the memory benchmark. The results are stored with the build they measure, the reader, the judge and every miss. Six weeks from now, “did the limiter change cause this?” is a question Recallium answers, not a dig through CI logs.
A commit that can explain itself long after everyone forgot.
Wrote the trailer pointing at the decision and the finding, and a checkpoint recording what was verified and how.
DEV NINJA#3 and UI NINJA reviewed the page together. Once.
The website change ships, UI NINJA's design and DEV NINJA#3's code in one commit. The commit carries a trailer pointing at the reasoning behind it, and a checkpoint records what was verified and how.
Recallium-Memory: 01a1…c67, 01a1…c6a · the decision that shaped the change, and the finding that triggered it
“Why is this here?” is answered by the commit, not by whoever is still around.
Parked, not lost.
Wrote the working state: what is mid-way, what is next, which decisions it rests on, and the memories to resume from.
Closed the laptop.
Pagination is half done. Before the laptop closes, the agent writes down what is mid-way, what is next and which decisions it rests on. Tomorrow, whoever opens the project first picks it up from there: NINJA#1, NINJA#2, or either one's agent. Which is where this day started.
This page was built the same way: Recallium handed the agent what the team had already decided, kept the design before the first edit, and tied every commit to its reasoning.