Continuity

Pick up tomorrow exactly where you left off today.

The best ideas arrive between sessions — in the shower, on a walk, the next morning. GoTo Agents is built around that rhythm: a project carries its own instructions, its own shared memory, and its own status, so any agent can pick up the thread cold. The thread is never in a chat scrollback.

The loop, in practice:

  1. Work a session. You and an agent iterate on real files in the project folder.
  2. Everything worth keeping is kept. Decisions land in shared memory. Drafts — and a running note of where things stand — land in the project files themselves.
  3. Step away. Hours or days — the length of the gap doesn't matter.
  4. Come back with the better idea. Any agent in the workspace — not just the one you talked to — reads the same memory, project files, and library, and you're immediately back in the work.

The three files that carry the thread

A project is a real folder on your machine. Two markdown files make it collaborative — plus the working files themselves — each with a distinct job and lifecycle:

FileJobLifecycleWho writes it
GOTOAGENTS.md Standing instructions: what this project is, conventions, constraints. Changes rarely. Mostly you.
.gotoagents/MEMORY.md Durable facts and decisions: "chorus stays in D minor," "client hates serif fonts." Accretes slowly, gets pruned. Agents, with attribution; you can edit anything.
The project's own files Where things stand right now: drafts in progress, plus a running TODO or status section you keep by convention. Churns every session. Both of you.

Keeping facts and status separate is deliberate — mixing "what we decided" with "what we're doing next" is how memory files rot. Memory stays small on purpose (it's loaded whole into every agent's context), which forces the useful kind of curation: if everything is remembered, nothing is.

Naming follows the ecosystem: GOTOAGENTS.md mirrors the cross-tool AGENTS.md convention (renamed so it never collides when a project folder is also a code repo), and MEMORY.md follows the convention modern models are trained to maintain — one fact per entry, update rather than duplicate, prune what's stale.

What goes where: one question

Agents sort what they learn with a single rule: "Would this still be true in a different project?"

  • No → project memory. "The bridge comes before the final chorus."
  • Yes → your profile's memory. "Prefers hearing two options, not five."

Profile memory has a higher bar: durable preferences you've stated or clearly demonstrated — not inferences about your mood or one-off choices. Memory about a person deserves more caution than memory about a song.

Curation: memory you can see is memory you can trust

  • Read it — project memory is surfaced in the project panel; profile memory in your profile. Always one click away.
  • Edit it — it's markdown. Fix a wrong fact, delete a stale one, reword a preference. Agents work from the corrected version immediately.
  • It travels — memory lives in the project folder, so copying, syncing, or archiving the folder carries the shared understanding with it. Nothing is stranded in an app database.

Where it lives

  • core/project_context.py — project bootstrap: GOTOAGENTS.md creation, the .gotoagents/ data directory, memory read/write.
  • core/prompt_builder.py — where memory is assembled into the agent's context, via editable system_template.md templates.