Agentic Coding Tools Are Converging on the Same Handful of Design Choices

Agentic coding tools are converging on a common control plane: give the model repository context, separate planning from mutation, gate tools with explicit permissions, connect external systems through MCP, and delegate bounded work to specialist agents. Recent OpenCode V2 documentation makes that pattern unusually explicit, but the same pieces are now visible in Claude Code and Codex guidance.

What changed is less about a new model capability than the product shape around models. OpenCode now documents primary Build and Plan agents, plus subagents such as Explore. Its permission rules are expressed as an action, a resource, and an effect: allow, ask, or deny. That applies not only to file reads, edits, and shell commands, but also to web access, skills, subagents, external directories, and MCP-provided tools. Plan mode is designed to inspect and propose without editing the repository.

Claude Code exposes much the same boundary from the command line. Its CLI supports a plan permission mode, allowlists and blocklists for tools, a maximum number of agentic turns for non-interactive runs, and MCP configuration. Codex guidance likewise advises developers to define an autonomy policy that permits in-scope local work and non-destructive validation while requiring confirmation for external writes, destructive operations, purchases, and material scope expansion. The names differ; the operating assumptions do not.

The emerging default architecture

• A repository-level instruction layer that tells the agent how to build, test, and make changes.
• A planning or review path that can read and analyze without modifying code.
• A write-capable path that can edit files and run commands within defined boundaries.
• A policy layer that distinguishes routine local actions from consequential operations.
• An extension layer for MCP servers, reusable skills, and subagents with narrower roles.

This affects teams choosing between agents as much as teams building internal tooling. A coding agent is no longer only a model endpoint with a terminal attached. It is a small execution environment with an authority model. The useful comparison questions are therefore becoming: Which commands run without prompts? Can permissions be scoped by path, command, or tool? Are external directories and secrets treated separately? Can the agent call third-party MCP tools? Can a review agent be prevented from editing even when a build agent can?

Teams should write their operational policy before tuning prompts. Define which local edits and test commands are routine; which commands, paths, and credentials require approval; and which systems an agent may access through MCP. Keep planning, implementation, and review as separate modes or roles where practical. Give each role the least tool access needed, especially for shell execution and external services. Then test that policy against ordinary tasks, failed commands, repository secrets, and a request to publish or deploy.

The likely result is less tool-specific workflow design. Engineers can move between hosted and open-weight coding agents while preserving the controls that matter: instructions, validation commands, approval boundaries, and integrations. Model quality will still determine how often an agent gets a change right. The increasingly shared agent architecture will determine how safely it is allowed to try.