The mental model

One studio. Many collaborators. One memory of the work.

Everything in GoTo Agents fits in one picture: you (a profile) work inside a studio (a workspace) with AI collaborators (agents) on the work (projects — real folders of real files). The collaborators share the studio's library and one notebook per project. All of it is plain files you can open.

You PROFILE.md · MEMORY.md WORKSPACE — the studio Agents AGENT.md each Skills SKILL.md dirs Library reference docs Tools & MCP capabilities, local or connected PROJECT your real folder your files… GOTOAGENTS.md MEMORY.md works in on
The whole model: a profile works in a workspace, with agents, on a project. Every box is a folder or a markdown file on your machine.

You: the profile

A profile is who's at the keyboard. It carries two files that follow you across every workspace and project:

  • PROFILE.md — what you declare: who you are, how you like to work. You write it; agents read it; agents never edit it.
  • MEMORY.md — what agents learn about you over time: durable preferences you've stated or clearly demonstrated. Agents write it; you can review, correct, or delete any line.

That separation is deliberate: your self-description never drifts because an agent editorialized it, and everything agents believe about you is one click from view.

The studio: workspaces

A workspace is an isolated container — agents in one workspace can't see the skills, tools, or documents of another. Inside the studio:

  • Agents are your collaborators: a co-writer, an editor, a researcher — each defined by an AGENT.md you can open and edit, with its own skills, references, and tools.
  • Skills are packaged how-to, following the cross-vendor Agent Skills standard — an agent picks a skill up when the task calls for it and puts it down after.
  • The library (reference docs) is shared source material: the handbook, the style guide, the product spec. Agents see an index of what's there and read documents in full when relevant.
  • Tools & MCP servers are capabilities — file access, shell, external services — attached where they're needed.

The work: projects

A project is a real folder on your machine — your lyrics, chapters, plans, designs. Agents read and write those actual files. Two small additions make the folder collaborative:

  • GOTOAGENTS.md — standing instructions for this project, the same idea as the ecosystem's AGENTS.md convention.
  • .gotoagents/MEMORY.md — the shared notebook. Decisions, preferences, key facts: "the chorus stays in D minor," "client hates serif fonts." Every agent reads it before working and records what you decide together.

This is the heart of the collaboration model: memory belongs to the work, not the worker. Switch from your co-writer to your editor mid-project and nothing is re-explained — they share the notebook, like collaborators in the same room. And because the memory lives in the project folder, the project is portable: copy the folder, the shared understanding comes with it.

It's also what makes day-scale iteration work. Close the laptop with a half-formed idea; come back tomorrow when it's whole. The thread isn't in a chat scrollback — it's in the memory and the files themselves. Any agent picks it up cold.

No hidden state

The rule underneath all of this: if it shapes what an agent does, it's a file you can read. Agent definitions, skills, reference docs, both memories, even the system prompt templates themselves — plain markdown, in the UI and on disk. Nothing an agent believes, knows, or is instructed to do lives in opaque state.

For developers, this has a useful corollary: the file layout is the API. Everything above maps to a directory you can inspect — and a core/ module that owns it. Workspaces → core/workspace_manager.py, agents → core/agent_manager.py, skills → core/skill_manager.py, projects and memory → core/project_context.py, prompt assembly → core/prompt_builder.py. Point a coding agent at any of those and it has the owner of that behavior.