Configuration

Multi can be configured through several layers, each with a clear purpose:

Feature	Scope	Purpose
Personas	Global (user)	Identity and communication style
AGENTS.md	Workspace	Project-specific build, test, style, and workflow instructions
Skills	Workspace or user	Reusable, activatable workflows loaded on demand
.multiignore	Workspace	Steer Multi away from sensitive paths
Custom agents	Workspace or user	Your own agents, defined as markdown files with a system prompt and tool list

Communication Style with Personas

Customize Multi’s personality and communication style with Personas. Personas live in ~/.multi/soul/ and affect how Multi expresses itself - not its capabilities or available tools.

You pick the active persona when starting a task. See the Personas guide for details.

Project Context with AGENTS.md

For project-specific instructions - build commands, code style, testing conventions, and other context Multi needs to work effectively in a repository - add an AGENTS.md file at the root of your project.

Multi loads a single AGENTS.md from the workspace root - there’s no global override and nested files are not traversed.

See the AGENTS.md reference for details and examples.

Reusable Workflows with Skills

For focused, reusable workflows you want Multi to activate on demand - code reviews, refactoring playbooks, deployment checklists, team conventions - use Skills.

Skills live in .multi/skills/ or .agents/skills/ (project) or ~/.multi/skills/ or ~/.agents/skills/ (user) and are loaded into the agent context when activated. See the Skills guide to learn how to create one.

Protecting Sensitive Paths with .multiignore

To steer Multi away from files it shouldn’t touch - secrets, credentials, generated output - add a .multiignore file at your project root. It uses .gitignore syntax and blocks access to matching paths.

Note that .multiignore is a guardrail, not a sandbox. See the Ignoring Files guide for its limits and how to combine it with real isolation.