Building

Agents: collaborators you can read.

An agent is an AI collaborator with a job: a co-writer, an editor, a researcher. Everything that makes it what it is — identity, instructions, skills, tools, references, model choice — is declared in files you can open, edit, and version. Building a good agent is writing, not programming.

AGENT.md

Each agent is a folder under the workspace's goto_agents/ with an AGENT.md: identity and configuration in YAML frontmatter, instructions in the markdown body. Skills and tools are attached by name; the agent can carry its own reference docs and task definitions alongside.

goto_agents/co-writer/
  AGENT.md              # frontmatter + instructions
  system_template.md    # optional: agent-local prompt template
  documents/            # agent-scope reference docs
  TASK_*.md             # agent-scope tasks

The prompt is a template you own

The system prompt isn't assembled from hidden strings. It's rendered from editable system_template.md files that resolve down the scope chain — global default, workspace override, agent-local override. Behavioral rules live in the template where you can read and change them; PromptBuilder only supplies data. If you want your studio's agents to behave differently, you edit a markdown file, not Python.

The debugging wow: the render-prompt view shows the exact, fully-assembled system prompt any agent will receive — skills index, reference docs, memory, activity context, all of it. When an agent behaves oddly, you look at what it actually saw. The prompt is never a secret. See The Prompt System.

Subagents and collaboration between agents

Agents can define subagents — scoped helpers loaded from markdown definitions — and can consult another agent for a one-off answer or hand the conversation over entirely (with an automatic summary brief). The collaboration primitives mirror how you'd work with people: ask a colleague, bring in a specialist, hand off the draft.

Model choice

Model and provider are per-agent configuration. Run your co-writer on one provider and your researcher on another; the workspace doesn't care. Provider-specific handling (schema sanitization, prompt caching) is isolated in the model adapter layer, not spread through agent definitions.

Where it lives

  • core/agent_manager.py — agent definitions and lifecycle.
  • core/agent_runtime.py — the conversation runtime.
  • core/subagent_loader.py, core/consult_agent_tool.py, core/switch_agent_tool.py — collaboration primitives.
  • core/chat_model_factory.py / core/model_resolver.py — provider and model resolution.