When advancing complex projects with Vibe Coding, relying on a single Agent quickly hits a capability bottleneck. First, the context window fills up with low-value information, forcing task interruptions. Second, mixing different roles like search, planning, and coding in one process lowers efficiency and increases errors. Finally, security concerns arise: lacking a global plan leads to redo work, and no permission isolation risks dangerous operations.

An Agent Team separates roles—planning is planning, execution is execution, and reading is separated from writing—alleviating the first two problems significantly. Harness adds a layer of control: assigning permissions, matching models, managing context, and constraining behavior. However, off-the-shelf solutions rarely fit directly since each project’s tech stack, development standards, task types, and workflows differ. One-size-fits-all solutions struggle to meet real needs.

Fortunately, customizing your own system isn’t complicated. Open a multi-Agent-supporting IDE or CLI tool (like Claude Code or OpenCode) and follow three key steps: design architecture and roles, manage permissions, models, and context, and add a Plan workflow. There’s also a faster option: import a ready-made Team + Harness framework and tailor it to your project’s specific requirements.

Step One: Design Architecture and Roles

Start Simple

You don’t have to build a complete multi-role team from the start. Begin with a single Agent, hereafter called the Builder, roughly equivalent to a default Build Agent in most AI coding tools. As task complexity grows, gradually split roles as needed. Each role is effectively a Sub-agent that takes on specialized tasks delegated by the Builder:

• Builder handles all work initially; if context or efficiency bottlenecks arise, consider splitting duties.
• Add read-only roles Explorer / Researcher: responsible for search and information collection, offloading retrieval work from the main Agent.
• Add Coder: focused on code implementation and modification to improve code quality and consistency.
• Add Planner: manages planning and task breakdown for multi-file or multi-step complex tasks.
• Extend with roles like Reviewer or General as needed for review, general assistance, or permission isolation.

“The best agent architecture is the one you don’t need to build. Start simple. Add complexity only when metrics prove it helps.” —Reliable Data Engineering

Core Design Principles

• Separate Planning and Execution: Planning (deciding what to do and task breakdown) and execution (actual coding and modification) engage different cognitive processes and should be handled by separate roles to avoid frequent context switches and errors.
• Separate Reading and Writing: The risks and costs of reading/searching information versus writing code differ sharply. Reading errors mainly waste time; writing errors can break the project. Assign retrieval tasks to read-only roles and code modification tasks to roles with permissions and review workflows.
• Separate Internal and External Searches: Internal codebase search and external internet research require different tools and strategies. Codebase search relies on project structure understanding (like Glob/Grep/Read), while internet search focuses on keywords, source evaluation, and info synthesis. Combining both in one role leads to bulky tools or conflicting strategies. Design and manage them separately.

Builder’s Routing Decisions

The Builder is the team’s decision-maker, using the most capable general-purpose model (e.g., Claude Opus). It rarely codes directly; its core duty is routing tasks to the most suitable roles.

A common routing schema looks like this:

Humans must clearly describe each Agent’s responsibilities and let the Builder’s underlying model decide whom to delegate. Adjust routing rules and thresholds based on performance. Over time, introduce quantitative metrics like delegation success rate, rollback count, and task completion time to iteratively optimize the division of labor.

Additional Behavioral Rules

These can be initially added to the Builder’s prompt, with specific numbers left for the model to decide and refined later:

• Prefer Delegation: When uncertain, delegate first to avoid Builder becoming a jack-of-all trades swamped by context details.
• 3-Failure-Stop: Stop and ask the user after 3 consecutive failures on the same subtask; avoid infinite retries.
• Plan Before Action: For tasks involving more than five files or multiple steps, assign a Planner to create a plan first instead of rushing to finish.
• Confirm Before Declaring Done: Before declaring completion, verify all parts are handled, code is reviewed, and tests pass.

Overview of Roles

Roles are realized as Sub-agents that take delegated tasks from Builder. There’s no fixed number of roles; if a task type occurs frequently and needs distinct capability or permissions, it’s worth creating a dedicated role:

Coder (coding executor): Uses a capable, cost-effective model to implement analyzed tasks. Cannot call Task (no recursive delegation) or use Skill. Hard constraints include: cannot pass tests by deleting existing ones, cannot deliver code with TODO or empty functions, must run tests and report results.

Explorer (internal analyst): Read-only codebase search. Tools: Glob / Grep / Read. Output must include a Not found section listing searched but unhit items explicitly.

Researcher (external researcher): Read-only info gathering on the internet. Tools: web search / URL fetch / GitHub browsing. All URLs and references must appear in the final report. Search language affects quality; English is recommended due to richer, more reliable tech content. Cross-verify to avoid hallucination and misinformation.

Reviewer (review and quality control): Uses code-specialized model with reasoning capabilities. Review priority: Completeness > Correctness > Quality. Output must be one of PASS / WARN / FAIL. Also used to review Plan.

Common design for read-only roles: Explorer, Researcher, and Reviewer have no edit or bash permissions to isolate side effects and prevent accidental file changes during read operations.

General (generalist): Has the highest allowed independent steps, full toolset, and can schedule Sub-agents. Used for tasks that are dividable but hard to categorize or cross-domain complex tasks.

Compaction (context compression): Uses long-context models with reasoning enabled to decide which messages to keep.

Step Two: Manage Permissions, Models, and Context

Permissions: Least Privilege

Each role should retain only the minimal permissions needed to perform its tasks:

Many AI Agents tend to “do as much as possible.” If given edit permission, they may modify files during research; if given task permission, they may further delegate even simple problems. Explicitly restricting permissions ensures each role sticks to its job.

Typical example: If Coder has task permission, it might delegate tough problems to Researcher or Explorer instead of solving them directly. This breaks Builder’s routing logic, wastes tokens, and keeps Builder unaware. Correct practice: Coder handles what it can by coding; if stuck, returns the problem to Builder.

Model Matching

Different tasks require different intelligence levels. The most expensive models go to tasks needing the most judgment.

When configuring, also consider multi-provider mixing and fallback strategies to benchmark performance, cut costs, and mitigate single points of failure.

Context Management and Information Isolation

Context is the scarcest resource; a tight context window quickly degrades model performance. Every bit of context should be used efficiently:

1. Sub-agents communicate with Builder only via final messages; intermediate steps are invisible to Builder. Builder just needs “task done, result is XXX”; detailed process info is provided only on exceptions.

2. Compaction can use three strategies simultaneously: auto (automatic triggers), prune (active trimming), and reserved (reserved space).

Step Three: Add the Plan Workflow to Handle More Complex Tasks

Why Plan Before Execution?

For complex tasks, invoking Builder directly without planning leads to four typical problems:

1. Insufficient context window (already discussed).
2. Lack of global view: Agent changes first file, then mid-way discovers conflicts in file three, requiring rework.
3. No recoverability: interruption or context exhaustion causes progress loss; must start over.
4. No auditability: Humans don’t know Agent’s intent until after execution, risking costly misdirection.

The two-phase Plan-Execute workflow addresses these issues. We add a dedicated Planner responsible for crafting structured Plan files.

Planner Agent

Planner takes complex tasks and outputs structured Plan files. Plans are persisted as files, bringing four benefits:

• Global view isn’t lost due to context exhaustion.
• Progress can resume after interruption.
• Both machine and human can review and adjust plans before execution (human-in-the-loop).

Planner has read/write access restricted to a specific directory (e.g., ./plans/<name>.md), physically isolating planning from execution.

Structure of the Plan File

The Plan file is a structured execution checklist with three core design points:

• Batch Thinking: Tasks in the same batch are independent and can run in parallel; batches have dependencies and must run sequentially. Parallel execution drastically speeds things up but requires logic to identify true independence—this judgment is the Planner’s responsibility.

• Five Elements of a Task:

  1. Assigned role: which Sub-agent executes it.
  2. Description: executable task explanation including files and expectations.
  3. Involved files: list of files to create, modify, or read.
  4. Verification criteria: clear checks.
  5. Status flags: pending / in-progress / completed / blocked

• Mandatory final verification batch: The last Batch must include integration tests and final review. Passing individual tasks doesn’t guarantee overall correctness—e.g., Task A changes an interface, Task B still uses old interface; each test passes alone but combined fails.

Executing the Plan

Executing the plan is managing a state machine to drive tasks from pending to completed. A simple Skill can describe this.

Core execution steps:

1. Load the Plan file and scan all task statuses.
2. Find the first incomplete Batch and start executing it.
3. For each task: mark as in-progress and write to file → delegate to Agent → on response update status and write immediately.
4. Batch gate: only after all tasks in current batch finish can the next batch start.
5. Execute the final verification Batch.

Checkpoint recovery: If tasks marked in-progress remain on load, it means last execution was interrupted. Recovery steps:

1. Locate interrupted tasks.
2. Assign Explorer to assess damage: Are files complete? Are there TODO placeholders? Does the project compile?
3. Based on assessment: completed → validated by Reviewer; partial → continued by Coder; damaged → fixed by Coder.

Core principle: Never assume interrupted work is done.

Additional Behavioral Rules

• Scope Per Delegation: No delegating to Coder tasks involving more than 5 files at once; split bigger tasks.
• Done Means Verified: Completion criterion is meeting verification checks, not just “code written” or “all tasks delegated”.
• Persist Progress Eagerly: Write status changes to file immediately.
• Specification Drift Check: After all batches, re-read Goal and Verification Criteria word by word, compare with outputs to detect any silent feature creep, missing requirements, or deviations.

Advanced Concept: Ralph Loop

For even more complex projects needing long AI autonomy with clear goals, you can introduce the Ralph Loop method.

In March 2026, Anthropic accidentally leaked all 512,000 lines of TypeScript source code for Claude Code. A Korean developer, Sigrid Jin, rewrote the entire codebase from TypeScript to Python in two hours using Ralph Loop, without writing a single line manually—fully relying on Agent-driven iterative development until success.

Ralph Loop’s key idea: break requirements into independent items, process one per iteration, proceed only after passing validation; each iteration starts a fresh Agent context. Memory between iterations is passed through files (git history, progress files, requirement status), avoiding context degradation from long runs.

The flow:

1. List all requirements, mark each as passed or failed.
2. Launch fresh Agent context and pick the highest priority unmet item.
3. Implement and validate it; if pass, mark done.
4. Append experience to progress file for next iteration’s reference.
5. Repeat until all pass or reach max iterations.

Ralph Loop can be implemented as a Skill, invoked and driven by the Builder to repeatedly execute the existing Agent Team.

Summary

Building an Agent Team is fundamentally architectural design, not just Prompt engineering. It’s like designing microservices or team workflows. Interestingly, once you start splitting roles, defining permissions, and designing state transitions, you realize these insights reflect how human teams work: why clear responsibility boundaries matter, why persistent workflows matter, why review and testing can’t be skipped. Agents hold up a mirror, reflecting your understanding of organizing work.

A more reliable approach treats tool selection like workflow design: first break down your workflow into clear, distinct scenarios—such as daily Q&A, in-depth research, coding execution, code review and merge—and then for each scenario, match the most appropriate tools and models rather than searching for a one-size-fits-all solution. This makes your decisions explainable, replaceable, and stable over the long term—even if specific products change often, the framework remains valid.

Therefore, I recommend a three-step process when selecting AI tools: clarify the responsibilities and boundaries of each tool → match model capabilities to tasks → design layered procurement and redundancy. The combinations below are based on my personal experience from late 2025 to early 2026.

General AI Assistants: Q&A and Research

These tools don’t interact directly with your code repositories; their roles include answering daily questions, searching information, and supporting deeper, longer-chained research. Separating them from development execution tools helps clarify later selection decisions.

Development Tools (IDE/CLI): Execution and Delivery

Once you’re in the core development workflow, you need tools that directly interact with code, repositories, and your review process. This layer determines delivery efficiency.

OpenCode’s key is the oh-my-opencode plugin, a multi-agent collaboration system with fine-grained role division. Although this design leads to frequent agent interactions, longer task chains, and high token consumption, it ensures delivery quality in complex technical scenarios. Once familiar with interaction patterns and matching models to roles, it supports hours-long, continuous autonomous technical discussions.

GitHub Copilot Web represents a different path: highly integrated, scenario-closed, striving for end-to-end automation. It minimizes multi-turn deep interactions and focuses on one-stop solutions from issue description to code merge. For clearly bounded medium-complexity tasks, it delivers extremely high efficiency and integrates seamlessly with GitHub’s development review flow—experience-wise, it’s close to contributing full code to open source projects.

Each has its strengths: OpenCode emphasizes control and depth, GitHub Copilot prioritizes automated closed loops. In practice, teams often use both complementarily—OpenCode for complex architectural discussions, Copilot for specific bug fixes.

Model Selection: Matching Capabilities by Scenario

After fixing tools, the next step is selecting models tailored to each task scenario.

Domain/business understanding tasks are special: they depend entirely on user-supplied context (business docs, historical code, decision records). Here pretrained model knowledge can cause hallucinations, so model choice is less sensitive—window size matters more.

Aside from domain understanding, typical scenarios get assigned different models and strategies:

To set expectations quickly: Opus resembles an experienced senior engineer whose outputs still require end-to-end verification; GLM-5 acts like a competent but less stable engineer; Kimi K2.5 and MiniMax M2.5 are cheap interns reliable only on deterministic tasks; Claude Sonnet/Haiku have many better cost-effective Chinese market alternatives and are generally unnecessary.

Cloud Service Procurement

Once models and tools are chosen, the final question is procurement. Key rule: don’t put your entire budget on a single vendor; diversify purchases by task risk level and keep redundancy on critical paths.

Conclusion

Efficiency gains come not from chasing the strongest model but from continuously decomposing workflows and matching tools/models to scenarios. You don’t need to get everything perfect initially—starting by separating general AI assistants and development execution tools and clearly distinguishing scenarios already beats intuition-based tool selection. Later, refine model division and procurement based on actual pain points and budget.

Note that using multiple tools and models involves switching costs and learning curves, so factor in adaptation time.

If this lasts a week, it’s just a busy stretch. If it persists for months, you need to step back and solve the problem differently.

Why This Happens

The internet industry moves fast, so this isn’t a one-week problem: organizations constantly restructure and chase new growth, iteration cycles are short, and business dependencies are complex. Demands are generated faster than any individual can absorb them. The harder you chase, the further behind you fall. Eventually you’re stuck in the weeds, unable to discover new value.

Since you can’t finish everything, the real question isn’t how to finish it all — it’s deciding what to do and what to skip, so you can carve out time for long-term, high-value work.

How do you break out? My recommendation: build a working principles document. Below is what it should contain, why, and how to use it.

How to Do It

The document isn’t complicated. Call it “Working Principles” or something softer like “How to Work With [Your Name].” Put the link in your team wiki or chat profile so anyone with a request can find it.

Section 1: Define your scope. State what you’re responsible for and what you’re not. This lets requesters quickly determine whether they’ve found the right person.

Section 2: Prioritized short-term requests. This is what requesters care about most.

First, lay out your priority principles by category. For example: production incidents > committed deliverables > items blocking others > new business requests > internal optimization and exploratory work. This establishes the overall ordering.

Then within each category, rank by value and urgency, and place them in a table:

Four key points:

1. The most important column is “Estimated Value.” If something has no value, urgency alone doesn’t justify doing it.
2. The ordering commits to delivery sequence — items higher up will be completed before items lower down — but it does not promise that everything will eventually get done.
3. Always estimate expected delivery dates, and include some buffer, because higher-priority requests may arrive at any time.
4. When a new request comes in, re-sort according to your principles, update delivery estimates, and notify anyone affected.

Section 3: Reserve time for high-value work. Short-term requests carry built-in urgency. If you can never finish them, you’ll never have time for long-term work. So the document must explicitly state when long-term work happens. Two common approaches:

1. Block two hours every day.
2. Block one or two full days per week.

Defend the time allocation as a hard floor. If high-value work falls short in a given period, make it up at the start of the next day or week.

Section 4: Handle trivial requests on the spot. For anything solvable in under ten minutes without a context switch, just do it immediately. Ten minutes is a reference threshold — adjust to your situation, but you must have a concrete number, otherwise everything becomes “trivial.” For must-do-today trivial items, commit to batching them in a fixed time slot before end of day.

With these four sections, the document is complete.

Make It Public

Principles that aren’t shared don’t resolve conflict — they just defer it. But once the document is public, the dynamic flips. As long as the principles are reasonable, requesters will read Section 1 and self-filter, then look at Section 2 to understand your reasoning and timelines.

If someone insists their request is more important, they now need to argue why it should jump the queue — which means making a case against every item ranked above theirs. The burden of justification shifts to the requester, not you. This also gives you a defensible way to push back when your manager drops in something unimportant.

Applying It

People stuck in execution mode share a common habit: they accept every request without weighing it. Their first reaction to any incoming task is “what is this and how do I solve it” — skipping the prior question of “should this be done at all, and how important is it?”

So for every incoming request:

1. Invest the effort to determine exactly which section and category it falls into, and where it belongs in the order. This requires communicating around the principles you’ve established, understanding the request deeply, and explaining the reasoning to the requester when needed.
2. Identify where the document doesn’t fit reality, and continuously refine both the document and the principles. Turn exceptions into standard cases, and make the standard cases more effective.

Measuring Effectiveness

You need a set of metrics to verify the system is actually working. I recommend three layers, from low to high:

The three layers are progressive. But the one that truly matters is the value layer — the other two exist to diagnose which link failed when something goes wrong. Looking only at execution is misleading: high throughput might just mean you’re rapidly processing low-value requests. Looking only at structure isn’t enough either: spending time on long-term work doesn’t guarantee you produced anything new.

Closing

Before this document exists, you and your requesters have no shared frame of reference — every new request triggers a fresh priority negotiation from scratch. Once the document is published, disputes have a ruleset to reference, and communication shifts from repeated one-on-one explanations to collective trade-offs against a shared set of principles. The work still won’t all get done, but the feeling of being dragged along will stop. You can step back and focus on value.