Cut Costs and Control Quality: A Team‑Level Multi‑Model AI Programming Framework

When a team uses AI programming tools frequently, delegating every development task—requirements understanding, code generation, debugging, testing, and self‑review—to a single "most powerful" model leads to three problems:

Cost mismatch : Simple tasks such as variable renaming, boilerplate completion, and test filling still invoke high‑cost models, causing waste.

Uncontrolled quality : The same model writes and reviews code without an independent verification mechanism, increasing the risk of hidden bugs.

Missing engineering system : No clear task boundaries, permission isolation, or objective evaluation makes AI‑generated changes hard to audit, roll back, or improve.

The solution is a runnable engineering system that routes tasks to appropriate agents, each with distinct responsibilities, minimal permissions, and objective verification.

Overall Architecture

The workflow splits AI programming into four agent categories:

flowchart TD
    A[User Requirement] --> B[Orchestrator Agent]
    B --> C{Task Classification & Risk Assessment}
    C -->|Requirement Clarification / Architecture Design| D[Planner Agent
Read‑only / Bash disabled]
    C -->|Cross‑file implementation / Debugging| E[Executor Agent
Writable / Bash controlled]
    C -->|Low‑risk mechanical tasks| F[Bulk Agent
Writable / Bash disabled]
    D --> B
    F --> G[Reviewer Agent
Independent context / Read‑only]
    E --> G
    G --> H{Objective Verification}
    H -->|Failure| E
    H -->|Pass| I{Risk Level}
    I -->|Low| J[Regular Review]
    I -->|Medium| K[Auto Verify + Code Review]
    I -->|High| L[Auto Verify + Manual Focused Review + Gray rollout if needed]

Configuration Styles (OpenCode reference)

Two ways to declare agents:

Markdown files : each .md placed in .opencode/agents/ (project level) or ~/.config/opencode/agents/ (user level). The front‑matter declares mode, model, permission, and the prompt.

Single opencode.json : a JSON at the project root declares all agents. Example:

{
  "$schema": "https://opencode.ai/config.json",
  "agent": {
    "build": {
      "mode": "primary",
      "model": "<provider>/<model>",
      "prompt": "{file:./prompts/build.txt}",
      "permission": {"edit": "allow", "bash": "allow"}
    },
    "code-reviewer": {
      "mode": "subagent",
      "model": "<provider>/<model>",
      "permission": {"edit": "deny"}
    }
  }
}

OpenCode loads the configuration once at startup; changes require a restart.

Agent Definitions

Orchestrator Agent

Decomposes requirements, routes tasks, aggregates results, and controls rework. It never edits code.

---
description: Orchestrator. Decompose requirements, invoke planner, dispatch implementation and review tasks, control rework and acceptance. Default does not modify code.
mode: primary
model: <provider>/<orchestrator-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash: deny
  webfetch: deny
  websearch: deny
  lsp: deny
  todowrite: allow
  task:
    "*": deny
    "architect": allow
    "executor": allow
    "reviewer": allow
    "bulk": allow

Planner Agent

Read‑only agent that produces a complete design plan: module division, interface changes, data flow, error‑handling boundaries, test matrix, and acceptance criteria.

---
description: Planning & Architecture. Used for requirement clarification, design, interface definition, data‑flow design, test matrix, or acceptance criteria. Read‑only, does not modify code.
mode: subagent
model: <provider>/<high-reasoning-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash: deny
  webfetch: deny
  websearch: deny

Executor Agent

Follows the planner’s plan, modifies code, and runs project‑specified verification commands.

---
description: Implementation & Execution. Used for cross‑file changes, debugging, building, running tests, or fixing rework. Modifies code and runs verification commands.
mode: subagent
model: <provider>/<execution-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: allow
  bash: ask

Reviewer Agent

Reads diffs, runs verification commands, and reports only blocking issues. It never modifies code.

---
description: Review & Verification. Reads diff, runs verification commands, reports blocking issues, does not modify code.
mode: subagent
model: <provider>/<review-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: deny
  bash:
    "*": deny
    "git status*": allow
    "git diff*": allow
    "git show*": allow
    "git log*": allow
    "npm test*": allow
    "pnpm test*": allow
    "yarn test*": allow
    "go test*": allow
    "pytest*": allow
    "mvn test*": allow
    "gradle test*": allow
    "make test*": allow
    "npm run lint*": allow
    "npm run typecheck*": allow
    "tsc*": allow

Bulk Agent

Handles clearly defined, low‑risk mechanical tasks such as variable renaming, boilerplate completion, and small‑scope test additions. Stops and returns control to the orchestrator on complex issues.

---
description: Cheap bulk. Used for variable renaming, boilerplate, test completion, etc. Handles clear mechanical changes; stops on complex problems.
mode: subagent
model: <provider>/<low-cost-model>
permission:
  read: allow
  glob: allow
  grep: allow
  edit: allow
  bash: deny

Quality Verification

AI‑generated changes must pass objective verification; model self‑evaluation is insufficient.

Minimum verification items (run after every change)

Relevant unit tests.

Project‑specified type checks or compilation.

Lint/format checks.

Critical‑path regression tests.

If a project lacks automated tests, add them first or limit AI‑driven changes.

High‑risk verification items

When changes involve permissions, billing, data deletion/migration, security policies, infrastructure configuration, CI/CD, multi‑tenant isolation, concurrency, or API compatibility, raise the verification level and require manual review with a rollback plan.

Performance & Cost Optimization

Compare two approaches:

Single high‑capability model handling all tasks.

Routing tasks to appropriate models based on type.

Beyond token price, consider hidden costs: rework after failures, review effort, context duplication, manual intervention, and defect fixing. If a cheap model causes significantly more rework, overall cost may increase.

Security & Permission Governance

Data boundaries (default conservative)

Prohibit external models for secrets, customer data, production data, and security configurations.

Define which repositories may use external models and which must stay internal.

Control model access to configuration files, logs, sample data, database exports, internet search, and internal documentation.

Permission defaults

Planner and Reviewer agents: no file writes.

Executor agent: bash commands require explicit confirmation.

Disallow high‑risk commands such as delete, clean, reset, force‑push, permission changes, and unaudited modifications to CI/CD pipelines or production DB scripts.

Auditing requirements

Record model and version used.

Record executed commands.

Record modified files.

Record prompt version.

Record review results.

Record human confirmation.

Mark AI‑generated or AI‑modified code in merge‑request templates for traceability.

Rollout Roadmap

Stage 1 – Small pilot : select 1‑2 non‑core repositories, build task samples and verification commands. Goal is to validate controllability, not immediate cost saving.

Stage 2 – Model candidate pool : maintain a pool of candidate models per task type, each vetted on internal task sets. Record model version, integration method, price, context length, compliance status, applicable and non‑applicable tasks.

Stage 3 – Routing & review : separate planning, implementation, review, and bulk handling into distinct roles. Run initially in human‑in‑the‑loop mode to confirm quality and permission boundaries.

Stage 4 – Engineering governance integration : store agent configurations, prompts, permissions, verification commands, skills, and commands in the codebase. Require review for any model upgrade, prompt change, or permission adjustment.

Stage 5 – Periodic re‑evaluation : quarterly re‑test the candidate pool because model versions, pricing, context limits, and tool support evolve.

Core Benefits of Multi‑Model Collaboration

Cost saving : cheap models handle simple tasks; expensive models are reserved for complex work.

Objective review : isolated reviewer agents avoid bias from self‑review.

Quality control : objective verification replaces vague "looks good" judgments.

Risk containment : minimal permissions limit impact of failures.

Evidence‑based selection : real business‑scene benchmarks, not leaderboard hype, determine the best model.