Custom Modes in Cline: Defining Specialized Agent Personas
Autonomous coding assistants work best with clear boundaries between planning and execution. While discussions around cline custom modes often focus on third-party forks, upstream Cline provides a native Plan and Act dual-mode architecture paired with version-controlled rules. Configuring specialized personas in Cline allows teams to separate architectural design from code modification, preventing accidental edits.
Why Autonomous Coding Agents Need Execution Boundaries
Point an autonomous coding agent at a multi-repository workspace without operational boundaries, and it will begin refactoring core libraries before identifying how tests are run. The agent treats exploration and execution as a single continuous loop, attempting to fix perceived syntax issues or restructure directories while it is supposed to be inspecting dependencies. When an agent possesses unrestricted write access during discovery, a developer asking a basic architectural question risks having working code silently rewritten across dozens of files.
Custom modes in coding agents allow developers to define specialized operational personas with constrained tool access, dedicated system prompts, and scoped permissions for tasks like architecture design, code review, or Q&A.
In complex software systems, the cognitive demands of high-level system design conflict with line-level code generation. An architectural assessment requires broad repository indexing, dependency mapping, design pattern validation, and macro-level reasoning. Granting write access during that phase creates immediate operational hazards. An unconstrained model may attempt to resolve an ambiguous requirement by modifying production configuration files, introducing unvetted third-party packages, or breaking API contracts before a human engineer reviews the approach.
Developers managing complex codebases consistently favor read-only architect modes during initial task evaluation, ensuring the agent understands repository relationships before granting authorization for automated edits. Scoping tool access to read operations during discovery prevents unintended file modifications, suppresses hallucinated refactors, and protects established project conventions.
The Failure Modes of Unconstrained Agent Execution
Unbounded agents fail in predictable ways when exploration and execution share the same permission scope:
First, context pollution occurs when an agent generates extensive code changes during an exploratory query. The model fills its active context window with speculative file diffs, crowding out critical repository instructions and dependency graphs.
Second, accidental file overwrites happen when an agent assumes missing context indicates absent functionality. Rather than asking clarifying questions, the agent drafts new implementations over existing modules, wiping out subtle edge-case handling.
Third, human oversight breaks down. When an agent executes terminal commands and edits files simultaneously during planning, developers cannot distinguish between preliminary discovery steps and finalized production changes. Establishing strict persona boundaries ensures the agent stays confined to its intended task.
Related guides
- Claude Code Subagents: How to Create and Use Specialized AI AgentsMost AI coding sessions degrade after an hour because file reads, search results, and test output flood the context...
- How to Build Custom Agents in OpenClawOpenClaw hit 3.2 million monthly active users in April 2026, yet most deployments still run a single default agent...
- Best Cline Alternatives for AI Coding AgentsCline reports 8.0M+ installs and a free open-source product for individuals, so cost alone rarely drives a switch....
- How to Set Up MCP Servers in Cline: Configuration and Remote SetupsWhile most developers configure Model Context Protocol (MCP) servers locally, local setups restrict AI agents to a...
- Cline vs Cursor: Comparing the Top AI Coding ToolsAccording to the JetBrains AI Pulse Survey, 18% of developers report using Cursor at work, while GitHub Copilot...
- The Best MCP Servers for Cline: Top Model Context Protocol IntegrationsThe Model Context Protocol reached approximately 97 million monthly downloads by March 2026 [Digital Applied 2026...
More on this subject: Cline (104 guides)
How Cline Dual-Mode Architecture Compares with Roo Code Custom Modes
Much of the online discussion surrounding custom modes in Cline stems from confusion between official upstream Cline and Roo Code, a popular community fork. In late 2024, Roo Code diverged from the original Cline codebase specifically to introduce a feature branded as Custom Modes. Roo Code allows developers to create arbitrary operational roles stored in a .roomodes configuration file, assigning each persona specific tool groups (read, edit, command, browser, mcp) and file regex restrictions.
Official upstream Cline, maintained by Cline Bot Inc. and hosted on the official Cline repository, takes a different architectural approach. Instead of exposing an arbitrary dropdown menu of user-defined modes, upstream Cline structures agent interactions around a native Plan & Act dual-mode architecture:
- Plan Mode: A dedicated exploration and strategy environment. In Plan mode, Cline can read files, inspect directory trees, search codebases, and discuss technical approaches. File modification tools (
write_to_file,replace_in_file) and terminal command execution tools (execute_command) are physically disabled by the extension. Cline cannot alter repository state while in Plan mode. - Act Mode: The implementation environment. Once an engineer approves the architectural proposal developed during Plan mode, switching to Act mode unlocks write access and command execution, subject to granular user confirmation prompts.
How Upstream Cline Solves Persona Specialization
While Roo Code separates operational personas into distinct named modes with custom tool toggles, upstream Cline achieves the same safety guarantees through its structural Plan/Act separation combined with two native features:
The first mechanism is per-mode model selection. Cline allows developers to assign different language models to Plan mode and Act mode independently. For instance, a team can designate a high-reasoning model like Claude 3.7 Sonnet or Gemini 2.5 Pro for Plan mode, ensuring deep contextual analysis during discovery. They can then assign a faster, cost-efficient model to Act mode for mechanical code edits.
The second mechanism is custom instruction engineering via rules. Cline reads workspace-specific guidelines from .clinerules, allowing developers to define explicit behavioral personas, output constraints, and review protocols without needing an external custom mode engine.
How to Define Specialized Personas in Cline Using Rules and Model Profiles
To create specialized personas in upstream Cline, developers configure .clinerules files. Cline checks for project-level rules in a .clinerules file located at the root of the workspace directory. For cross-project defaults, Cline reads global rules stored in ~/Documents/Cline/Rules on macOS and Windows, or ~/Cline/Rules on Linux.
By pairing structured rule files with Cline's native Plan and Act modes, teams can establish three foundational agent personas:
1. The Architect Persona
The Architect persona focuses on high-level system design, boundary mapping, and implementation planning. When running Cline in Plan mode with Architect rules, the agent is instructed to produce Markdown specifications rather than raw code.
Add the following persona block to your .clinerules:
### Architect Persona Guidelines
When operating in Plan Mode:
- Act as a Principal Software Architect.
- Never suggest code modifications without first mapping module dependencies.
- Structure all proposals with: Context, Problem Statement, Proposed Changes, Impacted Files, and Rollback Strategy.
- Formulate questions to clarify edge cases before finalizing any specification.
- Output plans as clear Markdown checklists that can be executed sequentially.
2. The Ask and Exploration Persona
The Ask persona functions as an interactive technical guide and codebase tutor. It explains system architecture, traces execution paths, and documents existing endpoints without proposing refactors.
### Ask Persona Guidelines
When answering codebase queries:
- Explain how components connect using file paths and symbol names.
- Trace data flows through controllers, services, and repositories step by step.
- Provide illustrative code snippets in response text rather than staging file edits.
- Cite relevant internal documentation when explaining system behavior.
3. The Strict Code Reviewer Persona
The Code Reviewer persona activates during Act mode, inspecting diffs against team standards before changes are committed.
### Code Reviewer Persona Guidelines
When reviewing or modifying code in Act Mode:
- Check all modified functions for explicit error handling and input validation.
- Verify that new endpoints include accompanying unit tests with boundary checks.
- Reject any change that introduces unvetted external dependencies.
- Ensure variable naming matches existing repository patterns.
Model Allocation Strategies for Planning and Execution
Specialized personas perform best when paired with model architectures suited to their operational profile. In the Cline panel, click the model selection dropdown while in Plan mode to assign your analytical model, then switch to Act mode to assign your execution model.
For Plan mode and the Architect persona, prioritize models with high reasoning benchmarks and large context windows. These models excel at evaluating conflicting requirements, identifying architectural debt, and structuring complex migrations.
For Act mode and the Developer persona, select models optimized for tool use, low latency, and precise syntax generation. Fast execution models reduce turnaround times when applying diffs across multiple files and running automated unit tests in the integrated terminal.
Coordinate Cline agent personas in shared team workspaces
Connect Cline, Claude, and your engineering team to persistent, versioned workspaces with remote MCP access and built-in semantic search. Every organization starts with a 14-day free trial.
Restricting Tool Groups and MCP Integrations for Role Safety
Personas require more than prompt instructions; they depend on tool restrictions. While prompt guidelines encourage a model to behave like an architect, hard tool boundaries prevent the model from executing destructive operations if it experiences instruction drift.
Cline manages external integrations through the Model Context Protocol (MCP). Settings are defined in cline_mcp_settings.json, located within the extension's global storage directory:
- macOS:
~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json - Windows:
%APPDATA%\\Code\\User\\globalStorage\\saoudrizwan.claude-dev\\settings\\cline_mcp_settings.json - Linux:
~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json
Inside cline_mcp_settings.json, external capabilities are registered under the mcpServers object. Teams can connect Cline to remote workspaces using Streamable HTTP at https://mcp.fast.io/mcp/code. Setup guidance is available in the Fast.io MCP documentation. The following configuration connects Cline to Fast.io for agents for persistent team context:
{
"mcpServers": {
"fastio": {
"type": "streamableHttp",
"url": "https://mcp.fast.io/mcp/code"
}
}
}
Cline authenticates using OAuth in the browser rather than an API key in configuration. During sign-in, a Review Permissions screen prompts the user to select Read Only or Read & Write permissions and choose which organizations and workspaces the connection can reach.
Through this remote MCP connection, Cline gains access to a consolidated MCP toolset. An Architect persona can query shared team documentation, inspect product requirements, and check architectural standards stored in Fast.io without needing direct file write permissions on production repositories.
Isolating Local Tool Execution from Shared Workspace Assets
A frequent operational error in AI-assisted development is keeping all context local to a single engineer's machine. When an Architect persona drafts a comprehensive system design specification in a local VS Code session, that context remains trapped on that developer's laptop. Other developers running separate Cline instances cannot reference the spec, leading to divergent implementations.
Connecting Cline to shared cloud workspaces through MCP solves this fragmentation. Local agents can read design blueprints, API contracts, and schema definitions from a centralized storage layer. By configuring read-heavy MCP access for planning and restricting shell execution tools to explicit human confirmation, teams maintain a secure boundary between local code editing and shared company knowledge.
Persisting Multi-Persona Context in Shared Team Workspaces
Configuring individual personas inside Cline solves task-level execution safety, but team-level development requires coordinating multiple personas across different machines. In a production workflow, one engineer might use Cline in Plan mode as an Architect to draft an implementation spec, while a second engineer uses Cline in Act mode to build the code. Without a shared storage layer, handing off context between these personas requires copy-pasting Markdown files across chat windows.
Teams often attempt to solve this handoff using commodity cloud storage like Google Drive or Dropbox. However, standard sync drives are designed for manual office document sharing, lacking developer-centric APIs and real-time agent access. Object storage services like Amazon S3 provide raw programmatic access, but they lack built-in semantic search, live document co-editing, and human-friendly audit trails.
Fast.io acts as an intelligent workspace platform designed for agentic teams, providing the persistent coordination layer where agent personas and human engineers collaborate. By integrating Cline with /storage-for-agents/, development teams centralize project context in shared, organization-owned workspaces.
Fast.io maintains per-file version history on every asset. When an Architect persona publishes an Architecture Decision Record (ADR) and a developer agent updates related interface specs, Fast.io records each modification as a distinct version. If an automated run produces incorrect documentation, team leads can review the diff and restore earlier versions instantly.
The platform also features an append-only audit log, recording which agent or human touched each file and when. Collaborative Notes allow engineers and agents to co-edit live implementation checklists in real time. Fast.io also includes Intelligence Mode, which automatically indexes uploaded files for semantic search. When a Cline agent connects via MCP, it can query the entire workspace using natural language, retrieving relevant architecture guidelines with verifiable source citations.
Every organization starts with a 14-day free trial, which requires a credit card. Plans include Starter at $9.99/mo, Business at $49.99/mo, and Enterprise at $199.99/mo on Fast.io pricing.
Designing a Clean Handoff Between Architect and Coder Personas
A structured multi-persona handoff follows four concrete stages:
First, the Architect persona operates in Cline Plan mode, analyzing the local codebase and querying existing specifications from the shared Fast.io workspace via MCP. The agent produces an implementation plan with clear file boundaries.
Second, the engineer verifies the plan and saves the specification into a shared Fast.io folder using Collaborative Notes. Human team members review the document, leave comments, and refine scope.
Third, the Coder persona runs in Cline Act mode, pulling the finalized specification from the Fast.io workspace. With explicit task constraints loaded, the agent generates code, executes local test suites, and applies lint fixes.
Fourth, upon project completion, ownership transfer allows developers to hand completed workspace deliverables, specifications, and project assets to human stakeholders while retaining administrative management.
Sources
References used to verify factual claims in this guide.
-
Plan mode can read and search but cannot modify files or execute commands; Act mode implements with retained conversation context; dual models and structured development are documented.
-
Cline structures autonomous development using a Plan and Act workflow to inspect code before applying modifications.
Frequently Asked Questions
Does Cline have custom modes?
Official upstream Cline does not offer an arbitrary custom mode dropdown menu like its community fork, Roo Code. Instead, Cline provides a native dual-mode architecture consisting of Plan Mode for read-only exploration and Act Mode for code execution. Developers create specialized personas in Cline by defining instructions in `.clinerules` and assigning distinct AI models to each mode.
What is the difference between Plan mode and Architect mode in Cline?
Plan mode is Cline's built-in operational state that physically disables file modifications and terminal command execution, allowing agents to explore code and design systems safely. Architect mode is either a specialized custom mode in the Roo Code fork (which restricts writes to markdown files) or a conceptual persona configured in upstream Cline using Plan mode paired with architectural instructions in `.clinerules`.
How do I create a custom mode in Cline?
In official Cline, you configure specialized roles by creating a `.clinerules` file in your repository root or in your global Cline Rules directory. Within that file, define explicit persona guidelines, task constraints, and review steps. You can then toggle between Plan mode for read-only architectural tasks and Act mode for code generation. If you require `.roomodes` configuration files with custom tool group toggles, that feature is specific to Roo Code.
Can you configure different AI models for Plan mode and Act mode in Cline?
Yes. Cline supports per-mode model selection directly in the extension interface. You can assign a high-reasoning model like Claude 3.7 Sonnet or Gemini 2.5 Pro to Plan mode for deep architectural planning, and select a faster, lower-cost model for Act mode to handle repetitive code generation and test execution.
Where does Cline store rules and persona instructions?
Cline stores repository-specific rules in a `.clinerules` file at the root of your project workspace. Global rules applied across all projects are stored in `~/Documents/Cline/Rules` on macOS and Windows, or `~/Cline/Rules` on Linux.
Related Resources
Coordinate Cline agent personas in shared team workspaces
Connect Cline, Claude, and your engineering team to persistent, versioned workspaces with remote MCP access and built-in semantic search. Every organization starts with a 14-day free trial.