Architecture Starts With a Clear Goal
AI agent orchestration is less about choosing a single powerful model than building the right system around it. Nick Saraev argues that instructions, memory, tools and a clear definition of completion can determine how well an agent performs. His demonstration runs several agents across separate browser tasks, showing how orchestration can expand the amount of work covered and the number of approaches explored instead of expecting one model to solve everything alone.
The core loop is observe, think and act. Results from one action become context for the next. Saraev stresses that a task needs concrete requirements and a definition of done; a vague request makes it difficult for the agent to decide whether it has succeeded.
What to Master First
- Define CompletionSpecify the result, constraints and failure conditions before the agent begins.
- Preserve Useful RulesRecord project instructions and corrections so later sessions can use them.
- Compare Independent AttemptsUse parallel work when alternative approaches are valuable, then review the differences.
- Route by TaskSaraev assigns models different roles based on his assessment of their strengths.
- Review IndependentlyGive a fresh reviewer the result and requirements, rather than relying only on the builder’s self-review.
Memory, Skills and Model Routing
Instruction files such as AGENTS.md, CLAUDE.md and GEMINI.md can carry project rules between sessions. In Saraev’s workflow, corrections become written instructions that later runs can use. Skills add documented procedures for recurring tasks, with short descriptions loaded before their full contents are needed.
The course compares Codex, Claude Code and Google’s agent tools, and proposes assigning different parts of a project to models with different strengths. Saraev favors Claude for orchestration, Gemini for visual and front-end work, and Codex for back-end implementation and testing. These are his assessments at the time of recording, not permanent rankings.
One demonstration uses video understanding to turn a tutorial into detailed instructions for another agent to execute. The broader idea is to make useful knowledge available through tools and procedures instead of expecting the model to know or remember every step.
Parallel Work and Structured Debate
Saraev recommends trying several independent approaches when a problem benefits from exploration. A parent agent can compare the answers, identify recurring conclusions and retain useful outliers. He also describes giving agents different perspectives and letting them debate before a final synthesis.
Parallel work has a cost: more calls consume more tokens, and an orchestrator must reconcile conflicting results. Saraev’s argument is that carefully chosen independent attempts can reveal options that a single run misses; simply multiplying agents does not replace a well-defined task.
Controlling Long-Term Expenses
- Load Context SelectivelyKeep common instructions concise and retrieve large files or reference material when needed.
- Use Model TiersReserve expensive models for work that benefits from them; test the quality of cheaper routes.
- Inspect Context UsageCheck how much of a session is consumed by instructions, memory and skill descriptions.
- Batch When Delay Is AcceptableConsider batch processing for work that does not require an immediate result.
- Limit ReworkClarify requirements and define review criteria before spending heavily on implementation.
Review Independently and Define Failure
A fresh reviewer can examine an implementation without inheriting all the builder’s assumptions and failed attempts. The course uses this separation to find correctness, security and simplification issues, then assigns fixes to a resolver. The point is an independent check, not a guarantee that another agent will find every defect.
Saraev calls the upfront specification a prompt contract: define the goal, constraints, output format and failure conditions before building. Clarifying questions can expose missing requirements early and reduce expensive rework later.
Control Context and Token Costs
The course’s iceberg analogy is to keep a small, relevant set of instructions in active context and retrieve larger files or reference material when needed. Saraev demonstrates that system instructions, memory and skill descriptions already consume part of a session’s budget before the user asks a question.
His illustrative 60/30/10 split assigns routine work to inexpensive models, intermediate tasks to mid-tier models and demanding coordination to a frontier model. In his example, tiering reduces a $500 workload to about $200. The savings depend on the task mix and the prices used; they are not a fixed discount. Batch processing is another option when delayed results are acceptable.