Agents that remember.
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.
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.
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.
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.
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.
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.
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.
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.
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.