OpenCode 5 Ways: Which AI Agent Pattern Actually Wins?

Summary

The video compares five AI coding-agent workflows by building the same deliberately simple Python API 15 times. The API had three endpoints, API-key authentication, and OpenTelemetry instrumentation. Each run used the same specification, prompts, and MIMO 2.5 model, with a clean slate between runs. The main measures were token usage and elapsed time.

Approaches and results

1. Plan agent followed by build agent: About 26,500 tokens and 4.5 minutes on average. Results were consistent across runs, with less than 5% variation.
2. Build agent only (“YOLO mode”): About 25,000 tokens and just over 4 minutes. It was slightly faster and cheaper than separating planning and implementation.
3. Five specialists, switched manually: Architect, security, observability, testing, and documentation agents reviewed the plan before the build agent implemented it. This took about 195,000 tokens and 28 minutes. Agents sometimes acted outside their assigned roles: the documentation agent performed a security review, and the build agent later refused to code. The presenter attributes this to identity drift—agents following the conversation’s context rather than their own definitions.
4. Orchestrator with specialist agents: The orchestrator assigned work to the specialists, gathered results, and checked whether the team was complete and had reached consensus. It noticed that the team lacked a builder and created one after asking permission. It also chose to involve the architect before and after implementation. Results averaged roughly 36,000 tokens and 8–9 minutes.
5. Orchestrator with specialists invoked as sub-agents: Similar to approach four, but the specialists were configured as sub-agents. Token use increased slightly; the presenter suggests delegation and result-tracking overhead from the OpenCode harness may account for the increase.

Takeaways and practical guidance

• For this small API, the single build agent offered the best balance of speed, cost, and consistency. More coordination added overhead without a demonstrated benefit for this project.
• Orchestration reduced the need to call agents manually and showed useful behavior, such as detecting a missing skill and assigning an architect for multiple review stages. However, it took about four to five times as long as the simplest approach and used substantially more tokens.
• When defining specialist agents, specify both what they should do and what they should not do. Review the agent definitions rather than assuming the model will configure them appropriately. Clear boundaries may help limit identity drift.
• The presenter recommends measuring token usage and elapsed time on your own projects rather than adopting a workflow based only on general advice.

Limitations and future tests

The experiment did not measure code quality, bug rates, or whether the extra coordination produced better software. It also tested only five specialists on a three-endpoint API, and only with MIMO 2.5. Results could differ for larger projects, more agents, or other models.

The next planned experiment is a test of Ponytail, described as an approach focused on thinking like a senior developer and considering what not to build.

Source and model

• Main speaker/source: Adam Gardner, presenting his own OpenCode workflow experiment
• Model tested: MIMO 2.5