AI Agent

Conclusion first: the value of multi-agent doesn’t come from more models; it comes from the right structure. Multi-agent without structure is just more expensive concurrency — burn 2 to 3 times the tokens to watch a group of models nod at each other. Multi-agent with structure is an execution system that can delegate, parallelize, and verify. Why a Single Agent Fails at Long Tasks # Diagnosis first. A single agent executing complex tasks has five structural defects — blame the execution structure, not the model’s intelligence:

Let me start with something that actually happened. In early 2025, I added a feature to an internal system: export to Excel. Small requirement — I didn’t even write it up, just typed “add an export button to the list page” into the chat box. The AI delivered in ten minutes. Frontend changes, new endpoint, SQL — all in one pass. I was pleased when I opened the PR, right up until review revealed: the export columns didn’t match the list page, a hundred thousand rows would hang the service outright, there was no permission check, and the tests only covered the happy path.

Thoughts on Dynamic Intervention in AI Agent Runtimes # A few weeks ago, late at night, I stared at the agent logs scrolling through my terminal, frustrated enough to want to smash the keyboard. It was dutifully generating a requirements analysis report — it had been running for a dozen-plus minutes, pulling loads of data and drawing charts, clearly on the verge of wrapping up — when I suddenly realized the requirements were missing a key dimension: “Don’t split by region, split by user age group.” If I interrupted it now, all the context, intermediate results, and tool call state would be thrown away and it would start over. If I didn’t, it would soon produce a wrong report that would cost me just as long to fix by hand.

Conclusion first: plenty of tools out there can be installed, but most of them sit there gathering dust after installation. Below is what I filtered out of the things I actually use, sorted into five scenario categories, with a few genuinely used picks in each. First, One All-Rounder Recommendation # If you want a single install that covers most scenarios, take a look at this one:

Twelve articles, from the Think-Act-Observe loop all the way down into the 500,000-line engineering abyss. Now, standing at the end of the series and looking back over the whole evolutionary path, a bigger question surfaces: What will AI coding tools ultimately evolve into? A better Copilot? A more powerful IDE plugin? Or something new that we haven’t named yet? Three Evolutionary Paths # Looking back at the development of AI coding tools, you can see three clear stages of evolution:

The claude-code-from-scratch project implements a “mini Claude Code” in roughly 3,000 lines of TypeScript. It has the Think-Act-Observe loop, a tool system, a system prompt, permission control, memory, Skills, multi-agent, MCP — every core concept we tore down over the previous ten posts. And the official Claude Code source? Roughly 500K lines of TypeScript/TSX. That’s a 100x+ gap between 3,000 lines and 500K. What’s in it? The gap isn’t “number of features”. from-scratch already covers every core concept. The gap is the road each concept travels from “it runs” to “it’s usable” — that road is called productionization.

Autoregressive large language models operating in unconstrained environments suffer from an inherent tendency toward myopic mutation and runaway divergence. Claude Code’s Plan Mode attaches an external discrete Finite State Machine (FSM) that projects the action space onto a strictly side-effect-free subset, using an interactive human barrier to prune catastrophic physical backtracking branches from the decision tree. In disciplined software engineering, experienced developers instinctively value structural planning: mapping dependency graphs, deriving type signatures, and scoping blast radiuses before modifying a single line of code. Large language models possess no such innate restraint. Shaped by reinforcement learning to generate immediate answers, an agent granted unrestrained write permissions will instinctively mutate files without global context, precipitating an architectural cascade across complex repositories.

Before MCP, every AI tool integration was a custom build. Want ChatGPT to reach a database? Write a plugin. Want Claude to call the GitHub API? Write a Function Calling definition. Want Copilot to access your internal systems? Write a Custom Tool. Every time, the same thing: define an interface, write adapter code, handle auth, manage errors. The wheel, reinvented countless times. The problem MCP (Model Context Protocol) solves is simple: give AI agents a standard protocol for connecting tools. Just as USB-C gave electronic devices a universal connector, MCP gives AI agents a universal tool interface.

There’s a counterintuitive phenomenon: take the same model, split it into multiple independent instances, and have them collaborate — the result is often better than a single instance. Not more compute (three instances burn more total tokens than one), not more capability (every instance is the same model). The gain comes from role separation — when each agent attends to only one facet of the problem, it works with more focus and more depth than a “do-everything agent”.

If you’ve used Claude Code, you may have noticed the /skills command listing installed “skills”. Writing standards, architecture design methods, TDD workflows, code review strategies — it sounds like a plugin marketplace. Skills are not plugins. That’s the first and most important thing to understand about the Skill system. A plugin is code — it extends what the program can do. A Skill is a prompt — it extends what the model knows.