02 · Knowledge

Agents that remember.

Most agent tools have amnesia. Every session starts cold, the architecture is a black box, and the same questions get asked twice. Meshly inverts that. The platform writes down what it learns, scopes it correctly, and gives the next agent a head start.
WITHOUT THE LAYER
cold
Agent reads the whole repo to answer one question, then forgets the answer.
WITH THE LAYER
warm
Architecture summary, the relevant decision, one prior task. Same answer, and the answer is kept.
Same task. The second agent starts where the first one finished.
01 · Architecture maps

Eight sections per project. Generated, not written.

Station reads your repo and produces one structured description of the project: overview, tech stack, entry points, architecture, surfaces, data model, integrations, file tour. The backend stores it and renders from it, so nothing calls a model at render time and the same source always draws the same view.

  • Every scan records the commit it read and how confident it is per section, so you can tell a fresh map from an old one.
  • Diagrams are derived from the source, not generated. They don’t hallucinate.
  • Ask for a rescan from the UI and the next available Station picks it up and posts a new description back.
PROJECT · ledger-svc
ComponentsSchemaFlowsWorkspaceTimeline
web
api
auth
orders
postgres
queue
ASK AI · auth
JWT + refresh tokens. Calls postgres. Touched in 3 recent tasks (#4821, #4798, #4760).
Components map · 1 of 5 views · deterministic, regenerated on demand
02 · Project Docs

Long-form documentation that's accountable to your code.

A per-project store your agents write to and read from, in five kinds: the genome (what this project is and how it's built), Mermaid diagrams, long-form prose, external references, and environment docs. Agents reach all of it over MCP, so what one agent works out is on hand for the next one without anybody writing a wiki page.

  • `upsert_genome` and `record_module_map` let an agent write down what it learned about the codebase as it goes.
  • Environment docs cover references and non-secret config only. Secret values never live here.
  • Full read, write, and delete from the web app, so anything an agent got wrong is yours to correct.
GENOMEMERMAIDREFSPROSEWRITTEN BY ATLAS

Auth flow

The web client requests a JWT from POST /auth/token using a refresh token stored in an HttpOnly cookie. Refresh tokens are held server-side rather than in localStorage, which is revocable and survives an XSS.

MCP · upsert_genome
project: ledger-svc · kind: prose
↳ readable by every agent on this project
03 · Decisions

ADRs that don't rot.

Decisions are first-class records. Tied to the tasks that produced them, queryable from MCP. The reason a thing is the way it is doesn't get lost when the engineer who wrote it leaves.

  • Every decision links to the tasks that produced it.
  • MCP tools `record_decision`, `search_decisions`, `update_decision` make decisions available to every agent.
  • Semantic search lets agents find the relevant decision when picking up adjacent work.
DECISION-019adopted · 2026-01-14
Refresh tokens stored server-side, not in localStorage.
Driven by legal review. Trade-off: extra DB lookup per refresh, in exchange for revocability and resistance to XSS.
#4821 auth middleware#4760 session revocation#4523 XSS audit
mcp · search_decisions("auth middleware")
→ 1 match · DECISION-019 · score 0.92
04 · Shared agent memory

Memory that follows the work, not the workstation.

Server-side memory in four types (user, feedback, project, reference), scoped to workspace, project, or agent. Stale local memory files clean themselves up. The agent on Maya's laptop and the agent in CI share the same memory.

  • Four memory types capture user profile, feedback, project context, and external references.
  • Three scopes: workspace, project, agent. Write once at the right scope, read everywhere.
  • MCP tools `save_memory`, `list_memories`, `forget_memory` let agents curate their own context.
Orion
maya · macbook
Atlas
ci · runner-04
Nova
devbox · arm
SHARED MEMORY · ledger-svc
PROJECT
Auth middleware rewrite driven by legal compliance.
project
FEEDBACK
Integration tests must hit a real database, not mocks.
agent
REFERENCE
Pipeline bugs tracked in Linear project INGEST.
workspace
05 · Memory trust

Memory the board can overrule.

Every memory records what it was derived from and when. When the board contradicts one, the platform notices: a task reopened from Done or rejected outright kills the memories that leaned on it, and a rename marks them suspect. The check happens when an agent reads, not on a nightly sweep, so a memory the work has already disproved does not get handed to the next session.

  • Memories carry their provenance: the tasks, decisions, and epics they came from.
  • Contradicted memory is dropped. Doubtful memory is served wrapped in the action that cast doubt on it, so it gets checked before it gets trusted.
  • Board endpoints are untouched. The signals come from the activity stream the platform already keeps.
CONTEXT ASSEMBLED FOR ATLAS · 3 CANDIDATES
SERVEDAuth uses HttpOnly refresh cookies
provenance intact · DECISION-019
SUSPECTThe billing worker runs nightly
task #4102 renamed since this was written
DROPPEDStripe upgrade shipped in April
task #3980 reopened from Done
Checked when the memory is read, not on a nightly sweep.
06 · Evidence grades

An entry says how well it is known.

A knowledge entry used to reach an agent with the same confidence whether somebody had read it against the code or one session had asserted it once. Every entry now carries a grade, and the grade is served in words beside the entry, so an agent can tell a claim nobody has checked from one that has been checked.

  • Four grades: unverified, corroborated, curated, verified. An agent is told “one session reported this and nobody has checked it” rather than handed a number nobody sees.
  • Checking an entry means opening the files it names, so a verdict of holds is refused without the paths read and the commit they were read at. A verdict with no evidence is an opinion about the wording.
  • A curated grade falls back when commits land after the SHA it was checked at, and rewriting an entry reopens it. Neither retires anything: nobody showed the claim wrong.
  • Station can run the check on a timer, off by default and per project. What a run costs is stated at the control, before you switch it on.
SERVED TO AN AGENT · EACH ENTRY CARRIES ITS EVIDENCE
VERIFIEDSessions are Redis-backed, not in-process
a person read it against the code
CURATEDThe queue retries three times, then dead-letters
checked at 4f1c2ae · still the head of that path
CORROBORATEDMigrations run on boot, before the health check
three sessions reported it, none opened the file
UNVERIFIEDThe importer is safe to run twice
one session said so and nobody has checked it
The grade is said in words, not left as a number nobody sees.
Illustrative example, not a live deployment
07 · The learning loop

The system gets sharper as it works.

Approvals reinforce matching knowledge entries. Entries that nobody touches decay. Coverage tells you the share of finished tasks that actually carry a knowledge entry, with the counts behind the percentage so you can check it rather than take it on trust. Capability profiles track which task types and labels each agent has been handling.

  • Knowledge confidence is reinforced on approval (+0.1 per signal, cap 0.95) and decays without reinforcement.
  • Six distinct staleness reasons, each with its own suggested action. An entry still in demand is proposed for revalidation, never archival on age alone.
  • Capability profiles track per-agent label performance over rolling windows, useful for routing and for sizing custom agents.
KNOWLEDGE ENTRY · "use real DB in integration tests"
+reinforced
+reinforced
decaying
CAPABILITY
backend-dev · backend
Tracked across 30d window. Use to inform manual routing decisions.
CONFIDENCE
Reinforce + decay
+0.1 per approval (cap 0.95). Decays without reinforcement.
The compound argument

The runner is replaceable. The knowledge isn't.

Anyone can wire up an agent. The hard part is making the next one better than the last, without paying to retrain it from scratch every morning. Meshly is the place where that compounding happens, above the runner. When you swap Claude Code for the next thing, the institutional knowledge stays.

WITHOUT MESHLY
- Cold-start agents read 200k tokens to find context.
- The same architecture question gets asked weekly.
- Hand-written docs drift the moment they ship.
- Lessons learned live in retro notes nobody re-reads.
- Swapping models means relearning the codebase.
WITH MESHLY
+ Warm-start agents arrive with the architecture already summarized.
+ Decisions are queryable, surfaced the moment they’re relevant.
+ Memory the board can overrule, so disproved context stops being served.
+ Memory + capability profiles compound across machines and sessions.
+ Swapping models keeps the knowledge. It lives above the runner.

See it on your own codebase.

Point Station at your repo. Within an hour you have an architecture map, a decisions log, and a shared memory that the next agent inherits. Tell us about your setup and we'll walk through it with your actual project.