If you look at the picture below, it should basically cover the daily usage scenarios of ClaudeCode or Codex partners. These are some intermediate processes of a website I built using the recent dynamic workflow. As you can see, in this process it pulled up nearly 100 SubAgents to complete the collaboration. Not only can you beat ten like Ip Man, but now you can beat hundreds! In this process, models will be used to demonstrate capabilities similar to Wide Research, achieving a balance between depth and breadth, identifying a fake Salah channel, and confirming that Gucchon does not have a stable personal channel. (Both of them are Popping masters) This also explains why some new concepts and models have emerged one after another in recent months, but its essence does not seem to be particularly different from previous technologies. My personal understanding is that it actually represents a technical consensus, an increasingly refined consensus. It does not simply stay at the conceptual level, but unifies some engineering paradigms, whether it is skills, subagent, goal, loop, dynamic workflow, etc. It is meaningful. A standardized engineering paradigm can greatly reduce the friction between agents, people, tools, and environments. It can also reversely make the agent capabilities of large models more targeted and train more efficiently. In ScalingLaw stacking mode, it becomes more efficient, and the value is more focused and non-divergent. Coding is effective, so do its value thoroughly! I have also listed the new features currently in use and their combinations, so you can try them out. Guaranteed to make your token burn like crazy! ────────────────────────────────── Dynamic Workflows can automatically generate JavaScript orchestration scripts to implement complex logic such as multi-agent collaboration, parallel task processing, and adversarial verification. Suitable for long-term tasks such as in-depth code analysis, security audits, and large-scale migrations. The fireworks-design in the above example is essentially a Dynamic Workflow, you can try it: https://github.com/yizhiyanhua-ai/fireworks-design ─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────── bars both all all the same, Plan solves the problem: "What to do and in what order" Form: a markdown document, bite-sized steps + checkbox ───────────────────────────────── Subagent Problem solved: "Who will execute each step" Form: fresh subagent per task, isolated context, main agent only coordinates ──────────────────────────────────────────────── Loop Problem solved: "When to advance to the next step" Form: scheduled ticking, reading the plan file each time, checking the stage, and advancing ───────────────────────────────── Goal Problem solved: "How much does each step cost? "Money, what model to use" Form: goal card + budget envelope + routing decision ───────────────────────────────── High-quality Coding collaboration chain (from goal to completion) Four dimensions of division of labor Plan = Blueprint (What/Order): All three subsequent parties will read it, execute it, and advance it Subagent = Execution unit (Who): sub-agent assigned to the isolated context, the main context is not polluted Loop = time dimension (When): let long tasks automatically follow a rhythm Come back and advance to the next stage. Goal = Economic dimension (How much): When disassembling, decide which model is the most economical to use for each section. Typical collaboration scenario Scenario 1: Small changes - don’t use anything, just do it directly. Scenario 2: Medium task (30 minutes level) brainstorming → writing-plans → executing-plans (the main agent does it step by step) Scenario 3: Large multi-task project (requires quality) writing-plans → subagent-driven-development (each task dispatches implementer sub-agent → spec review sub-agent → code quality review sub-agent) Scenario 4: Multiple unrelated bugs/failures dispatching-parallel-agents (one for each independent problem) agent, runs in parallel, no complete plan is required) Scenario 5: Very long Task (several hours/across sessions) writing-plans → /loop 30m (each loop reads three sets of plans, advances to the next stage, and updates progress.md) Scenario 6: Cost-sensitive complex goals/goals are routed first → write-plans → subagent execution for parts that require high-order reasoning (goal makes economic decisions at the top level, and the saved tokens will be recorded) Several confusing points
- Plan ≠ Goal: Goal It is the "routing decision-making layer" (how to save), and Plan is the "execution blueprint" (how to do it). List of subtasks produced by Goal Can be fed to Plan.
- Loop does not create progress, it only advances: it reads the existing plan and moves forward according to the rhythm.
- Without a plan, the loop has nothing to push.
- Subagent is not necessary: executing-plans is done by the main Agent itself,
- Subagent-driven-development only sends sub-agents. When you have the Subagent ability, use the latter first, which is of higher quality.
- Plan is a contract: subagent’s prompt, loop, and goal routing results all reference the same plan file to ensure three-party alignment.
