Stale Documentation
The initial plan recommends WAL because it usually lets reads and writes to proceed concurrently.The Context Layer for Software Engineering
'a-gə-rə
In ancient Greece, a central public space where people gathered to exchange knowledge, debate ideas, and make decisions.
Great software starts with shared understanding. Agora preserves the rationale, operating constraints, and accumulated judgment behind your code, then brings the right context to every engineer and agent so each task starts aligned instead of starting over.
the problem
Code quality depends on carrying your team's judgment behind good software from one task to the next. Today that knowledge is scattered across pull requests, tickets, docs, and people’s heads. Coding agents create another private layer: each session uncovers valuable insights that disappear when the session does.
If every interaction with an agent happens in a private window, the only person who learns anything is the person at the keyboard.
example task
Migrate the user identity store to SQLite
one quality constraint scattered across multiple sources
Tribal Knowledge
Testing uncovered one hard rule: a user change in identity.db and its history in audit.db must either both save or both fail.
Buried Resolution
The migration kept journal_mode=DELETE. With WAL, a crash can save one file but not the other; DELETE keeps the two-file update all-or-nothing.
Undocumented Decision
The identity migration shipped and the ticket closed. It recorded that the tests passed, but not why DELETE was required.
New Migration Planned
A fresh session starts the employee directory migration. It recommends WAL, unaware that the same separate-audit-file rule applies.
constraint rediscovered
The next session rechecks how workforce.db and audit.db save together, tests the crash case, and arrives at DELETE again.The code can be generated again. The rationale cannot. Because this constraint never entered a shared record, the next agent repeats the investigation.
the solution
AGORA turns scattered engineering work into a living context graph.
Agora turns organizational knowledge into durable infrastructure. Humans and agents shape one governed context graph where constraints, accepted choices, open questions, and discoveries stay connected to their evidence and the code they explain.
- comment
- ask
- accept
- review
- </>
- </>
- </>
how AGORA learns
Each interaction strengthens the graph.
Raw evidence becomes shared understanding through discussion, earns trust through accountable review, and returns as practical guidance for the next task.
01Capture
Architecture constraints, open questions, debugging breakthroughs, and technical decisions are captured where the work happens and structured into durable records.
02Discuss
Engineers and agents challenge assumptions, clarify ambiguous requirements, and turn scattered perspectives into shared understanding.
03Govern
Named reviewers, accepted answers, corrections, ownership, and lifecycle status keep knowledge current and trustworthy. Every change preserves its provenance and history.
04Reuse
Plans inherit prior constraints. Implementations carry settled choices. Reviews surface precedent. New teammates start from the team’s accumulated knowledge.
internal benchmarks
Same task.Different starting point.
We use Agora to build Agora. In our internal benchmarks, tasks grounded in previously verified knowledge outperform the same tasks starting without it.
50%fewer tokens4.5×faster
⏺ I’ll trace both stores and reconstruct the migration’s failure modes.⏺ Read(src/stores/SessionsStore.ts) ⎿ Writes the session, then persists its participant joins⏺ Read(src/stores/ParticipantsStore.ts) ⎿ Two SQLite stores coordinate the paired commit⏺ Grep(pattern: "journal_mode|ParticipantsStore", path: "src") ⎿ Found journal settings across six files; no migration rationale⏺ Session and participant commits must stay atomic. Can WAL span both stores?⏺ Bash(npm test -- session-store-crash) ⎿ Failed: participant row missing after simulated crash⏺ Re-derived decision: use DELETE journaling to preserve the pair.⏺ Edit(src/stores/SessionsStore.ts)⏺ Bash(npm test -- session-persistence) ⎿ Passed: session migration keeps participant joins consistent✓ Resolved after re-derivationtime 45m · 545K tokens⏺ I’ll search Agora for earlier migrations matching this paired-store path.⏺ agora.search("paired-store migration consistency precedent") ⎿ Graph traversal
[SessionsStore.migrate()]
├─syncs────▶ [ParticipantsStore.upsert()]
└─similar──▶ [ThreadsStore.migrate()]
└─syncs──▶ [MessagesStore.upsert()] └─ knowledge captured during previous migration 2026-02-14 Decision Parent + child commits stay atomic 2026-02-16 Discussion Can WAL span two SQLite stores? 2026-02-18 Note Crash test loses the dependent row 2026-02-19 Decision Use DELETE journaling · verified⏺ Previous migration matches. Applying its verified decision to both stores.⏺ Edit(src/stores/SessionsStore.ts)⏺ Bash(npm test -- session-persistence) ⎿ Passed: session persistence · prior migration cited✓ Resolved from migration precedenttime 10m · 272.5K tokenspricing
Born local. Shared by choice.
Shared context should not mean shared by default. Every capture begins on your machine. Publishing knowledge to the team is a deliberate action, not the default destination.
Fully Local
Free
Your private context layer for capturing and reusing engineering knowledge on your machine.
- Capture and search knowledge locally
- Dashboard, MCP, CLI, and REST access for your SDLC workflows
- Discuss, verify, and reuse on your machine
- Give local agents scoped access to trusted knowledge
Shared layer
Enterprise
The multiplayer space we are building for knowledge your team explicitly chooses to publish.
- Publish selected knowledge from local workspaces
- Bring humans and agents into shared discussion and review
- Keep verification state, source, and change history attached
- Use reviewer queues to keep shared knowledge accountable
The next session should not start from zero.
Give every engineer and agent the knowledge your team has already learned.