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.
DAY 1 · COLD START
198k tokens
Agent reads the whole repo to answer one question.
DAY 30 · WARM START
4.2k tokens
Architecture summary + the relevant decision + one prior task. Same answer.
Same task. ~50× cheaper. Better answer.
01 · Architecture maps

Eight sections. Five interactive views. Generated, not written.

Architecture pages render eight standardized sections per project: overview, tech stack, entry points, flowchart, surfaces, data model, integrations, file tour. Five interactive views on top: Components, Schema, Flows, Workspace, Timeline. Diagrams are deterministic. Same source, same view. No LLM at render time.

  • Ask AI on any component for a grounded summary based on neighbours and recent related tasks.
  • Diagrams are derived from the source, not generated. They don’t hallucinate.
  • Regenerate on demand from Station; the backend stores the result.
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.

Paired writer and reviewer agents produce prose with citation footnotes. Every claim links to a file, decision, or task. Provenance and metadata sit in the margin so a human can trust (or correct) what the system wrote. Auto-refresh, token budgets, and producer choice are workspace settings.

  • Writer agent drafts; reviewer agent grounds citations against the source.
  • Standardized section vocabulary: overview, data model, API surface, auth, deploy, recent changes.
  • Per-card regenerate. AI-written content is visually distinguished from scanner facts.
OVERVIEWARCHITECTUREDECISIONSPROSEAI-WRITTEN

Auth flow

The web client requests a JWT from POST /auth/token using a refresh token stored in an HttpOnly cookie[1]. The decision to store refresh tokens server-side rather than in localStorage was made in Q1 2026 after a security review[2].

[1] Citation
apps/web/src/auth/refresh.ts:42-58
↳ verified by reviewer agent · 2026-04-22
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 · The learning loop

The system gets sharper as it works.

Approvals reinforce matching knowledge entries. Entries that nobody touches decay. Capability profiles track which task types and labels each agent has been handling. Over weeks the platform builds a picture of what each agent is good at, useful for manual routing and for sizing custom agents.

  • Knowledge confidence is reinforced on approval (+0.1 per signal, cap 0.95) and decays without reinforcement.
  • Capability profiles track per-agent label performance over rolling windows.
  • Useful for manual routing decisions and for retiring custom agents that aren't pulling their weight.
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.
+ Docs are written and reviewed by paired agents, with citations.
+ 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.