Introduction: When AI Is No Longer a Plugin, but the Skeleton

On March 31, 2026, Anthropic’s Claude Code’s entire source code—over 1,900 TypeScript files, 510,000 lines—was officially open-sourced through a .map file that was accidentally left included in an npm package.

Claude Code lead Boris Cherny’s characterization: “plain developer error.”

But Boris himself said something else on another occasion: 100% of his contribution to Claude Code was written by Claude Code itself.

In other words, the world’s most advanced AI company, using its most advanced AI to write its own product code, still stumbled at a link that “should have been reviewed.”

This is not a story about AI being unreliable. This is a story about system architecture needing to be rethought.

01 From Three-Tier Architecture to Three-Tier Intelligent Architecture

We’re all familiar with the evolution path of traditional software architecture:

The driving force behind each evolution is the same: system complexity has grown beyond what the current structure can bear.

In the AI era, this driving force hasn’t changed, but the source of complexity has. Previously, complexity came from business scale and team scale; now it also comes from AI’s uncertainty.

image

An AI that can write code might produce perfect code, or it might quietly delete a critical configuration line. An AI that can query databases might retrieve precisely, or it might accidentally delete production data. An AI that can access external networks might fetch useful information, or it might send sensitive data outside.

So system architecture in the AI era is forming a new three-tier structure:

Layer Traditional Architecture AI Era Architecture
Decision Layer Business Logic / Rule Engine Orchestrator + Planner Agent
Execution Layer Services / Microservices Worker Agent + Tool Registry
Infrastructure Layer Database / Message Queue / Cache Memory System + State Persistence + Observability

This isn’t simply “replacing microservices with agents.” The design principles for each layer have fundamentally changed.

02 Decision Layer: From Rule Engine to Orchestrator

In traditional architecture, decisions are driven by code logic: if-else, state machines, rule engines. Logic is deterministic—same input, same output.

In AI systems, decisions are driven by models. Models are probabilistic—the same input may produce different outputs. This creates a fundamental problem: who makes the final decision?

Many teams write it so that the Planner Agent decides which Agent to call, whether to continue, whether to retry, whether to end. In the short term, this is flexible; in the long term, it’s dangerous. Because LLMs are fundamentally not reliable schedulers—they lack natural cost awareness, concurrency awareness, permission awareness, or global consistency awareness.

The production-grade principle is only one sentence:

Agents handle local intelligence; the Harness handles global control.

Specifically, the Orchestrator must exclusively hold five decision rights:

  1. Task Lifecycle: Every task needs a clear state machine, from creation, planning, execution, review, completion, to failure
  2. Execution Plan Arbitration: Plans can come from the Planner Agent, but once generated, the Orchestrator must take over
  3. Agent Routing: Not every Agent can handle every task; routing must combine task type, Agent capability, permissions, and historical quality scores
  4. Failure Handling: When an Agent fails, do you retry, degrade, skip, or terminate? This must never be left to the failing Agent to decide
  5. Hard Termination Conditions: There must be four hard limits: max_steps, max_tokens, max_duration, and max_tool_calls

image

There’s also a detail that engineers often overlook: the Planner should output “declarative plans,” not “imperative calls.”

Declarative: {step: 1, intent: "research", agent: "researcher", input: "..."}

Imperative: directly await researcher.run("...")

The benefit of declarative is that the Harness can intervene: it can reorder, parallelize, reject steps, or perform security reviews before execution. Imperative is like handing the steering wheel to the Agent.

Don’t let the Agent drive; let the Agent navigate.

03 Execution Layer: From Microservices to Agent + Tool Registry

In microservices architecture, services communicate via APIs with clear interface contracts, version management, and circuit breakers.

In Agent systems, Agents interact with the world through tools. But the more powerful the tools, the greater the destructive potential.

A qualified Tool Registry should register at least nine metadata items for each tool:

Metadata Description
Tool Name Unique identifier
Tool Description Description for the LLM
Input Parameters JSON Schema Used for validation
Allowed Agent List RBAC
Call Timeout and Rate Limits —
Risk Level Low/Medium/High
Requires Human Confirmation —
Output Result Structure —
Audit Log Strategy What to save, how long to retain, who can view

The mindset shift behind this is crucial:

Tools are not function calls—they are external authorization points for production resources.

Giving an Agent a tool is like giving it a permission key. How many doors can this key open? Does it have a time limit? Does it leave traces? Who can audit it—these things must be considered from Day 1.

The emergence of MCP (Model Context Protocol) has standardized tool integration, but standardization doesn’t equal security. Quite the opposite—the easier tools are to integrate, the more the Harness needs to serve as a security gateway in the middle.

MCP makes tool integration cheap; Harness makes tool invocation trustworthy. The two must work together—you can’t favor one over the other.

image

04 Infrastructure Layer: From Database to Memory System

In traditional architecture, data storage is deterministic: what you write is what you read. Transactions have ACID guarantees, queries have index optimization.

In AI systems, “memory” is a term that’s been severely romanticized. Many articles say Agents should accumulate experience like humans. But in production environments, memory is first and foremost an engineering problem, not a romantic one.

It has four typical failure modes:

The correct approach is to separate “state” from “memory”:

State is data needed for current task execution, with a short lifecycle, concerned with consistency. It has three layers:

  1. Working State: Temporary context for the current step, discarded when the task ends
  2. Session State: Information shared among multiple Agents within one session, stored in Redis with TTL
  3. Execution Log: Immutable execution log; not necessarily used in reasoning, but essential for auditing, replay, and evaluation

Memory is experience and knowledge reused across tasks, with a long lifecycle, concerned with relevance. It has two categories:

  1. Episodic Memory: Pitfalls encountered, user preferences, experience handling certain types of problems
  2. Semantic Memory: Domain concepts, business rules, tool constraints

image

Claude Code’s seven-layer memory architecture is currently the most sophisticated implementation: from millisecond-level tool result storage, to micro-compression before each conversation round, to real-time session memory maintenance, to emergency compression when context nears capacity, to cross-session long-term knowledge extraction, to a “dreaming mechanism” similar to human brain sleep for memory consolidation, and finally to cross-agent communication among multiple Agents.

Memory is not a warehouse—it’s a garden. It needs regular pruning.

05 From Single Agent to Multi-Agent: The Return of Separation of Concerns

Over the past two years, the mainstream AI Agent product form has been “one omnipotent assistant.” This form is basically sufficient for simple tasks, personal tools, and early-stage small products, but as task complexity increases, the cost of lacking structure becomes increasingly apparent.

Having the same AI instance play PM, engineer, and legal counsel simultaneously doesn’t actually result in all three roles performing well. It constantly switches contexts between the three roles and loses context continuously. It’s not collaborating—it’s having a conversation with itself. And self-conversation naturally tends not to raise objections to oneself.

Claude Code’s newly launched /goal feature separates the referee from the athlete: at the end of each round, the system sends the goal conditions and conversation records to an independent small model, which judges whether the conditions are met.

The workers handle the work; the validators handle the validation.

The most important thing about collaboration between Agents isn’t being flashy—it’s putting back the “separation of concerns + cross-validation” that humans spent a hundred years inventing.

Products like Helio are betting on this direction: letting AI join organizations as team members, with independent identity, independent email, independent memory, and independent roles. Each AI has clear responsibility boundaries, just like job descriptions in real companies—things it should manage and things it shouldn’t, things to focus on and things to let go.

The benefits of structure, without the costs of structure.

06 Cost Control: Token Budget Is the Lifeline

When many teams first get an Agent running, the most surprising thing isn’t the model’s capabilities—it’s the bill.

Why is Multi-Agent so expensive?

A production-grade Harness must have a Token Budget—it’s not a post-hoc statistic, but real-time scheduling:

Zone Budget Remaining Strategy
Green Zone >50% Normal execution
Yellow Zone 20%-50% Compress context
Red Zone 5%-20% Switch to smaller model + skip CoT
Circuit Breaker Zone <5% Force convergence, return partial result

Three core strategies:

  1. Model Routing: Not every step needs the strongest model. Use smaller models for classification, summarization, and format conversion; use stronger models for complex reasoning and final synthesis
  2. Context Compression: Keep the last few rounds raw + compress earlier history into structured summaries
  3. Budget-tier Degradation: From green zone to circuit breaker zone, gradually tighten constraints

image

07 Evaluation System: Don’t Just Look at the Answer, Look at the Trajectory

Evaluation of Multi-Agent systems is currently the most underestimated aspect.

If you only look at the final answer, you’ll miss many danger signs:

A production-grade Eval Pipeline should have at least four layers:

  1. Component Eval: Did the single Agent select the right tool? Are parameters compliant?
  2. Trajectory Eval: Were steps necessary? Was the order reasonable? Were there repeated calls?
  3. Task Completion Eval: Did it meet the user’s goal? Are there factual errors?
  4. End-to-End Eval: Did the user adopt it? What’s the manual rework rate? What’s the cost per task?

image

Eval must enter CI. Every time you change a Prompt, swap a model, add tools, or tune parameters, run regression. For Agent systems, Prompt is code, tool Schema is an interface, execution trajectory is a log, and Eval is the test suite.

08 The Return of Development Methodology: Specification-First

Interestingly, AI is not only changing system architecture but also development methodology itself.

Agile emerged in a world where planning was difficult, building was slow, and requirements felt unknowable. In that world, it was a reasonable adaptation. But AI has changed two premises:

  1. Humans are not good at comprehensive planning → AI can help you plan, with a level of consistency and detail that was previously impractical
  2. Building is slow and expensive → AI has increased build speed by 10-100x

AI is greedy for context and rewards significantly better outputs with comprehensive specifications. Give it a two-sentence user story, get a two-sentence solution; give it complete architecture documentation, data models, and dependency graphs, and the output is completely different.

Agile was designed around human cognitive limitations—humans cannot hold large complex systems in their heads. AI is not bound by these limitations. Feeding it small, context-free snippets isn’t “agile”—it’s crippling your most powerful tool.

The new approach is Specification-First, Iteration-on-Feedback:

image

What’s dying is planning aversion and the ceremony economy. What’s surviving is feedback loops, minus the useless formalism accumulated over the years.

09 Implementation Roadmap: Evolve in Three Phases

Don’t try to reach the destination in one step.

Phase 1 — MVP: Get one end-to-end business loop running. Minimum Orchestrator + Tool Registry + simple state + basic Trace + evaluation dataset. Don’t start with dynamic Planner, ten Agents, or complex long-term memory. First, get one chain running stably.

Phase 2 — Hardening: Turn the demo into a controllable system. Add Budget, permissions, retry, compression, trajectory evaluation, auditing, and regression tests. Focus on solving “why it fails, where it’s expensive, where it’s slow, where it’s unsafe.”

Phase 3 — Scale: Support more scenarios and concurrency. Introduce distributed queues, multi-tenant isolation, dynamic model routing, Agent quality leaderboards, A/B testing, long-term memory governance, unified MCP integration platform, and cost dashboards.

image

Practical recommendations for technology selection:

Conclusion: Being Reliable Is More Important Than Being Clever

Returning to the Claude Code source code leak story. That .map file was forgotten because it wasn’t excluded—not because AI wasn’t smart enough, nor because the programmer wasn’t careful enough—but because the process was missing a role that would ask that question based on their own job responsibilities.

System architecture in the AI era isn’t about eliminating structure—it’s about reinventing structure.

Traditional architecture solves deterministic problems: deterministic input, deterministic logic, deterministic output. AI architecture solves indeterminate problems: fuzzy input, probabilistic reasoning, variable output.

image

So we need Orchestrators to take over decisions, Tool Registries to constrain tools, memory systems to manage experience, Token Budgets to control costs, Eval Pipelines to ensure quality, and Multi-Agent to achieve separation of concerns.

These are not optional embellishments, but essential steps for AI systems to move from demos to production.

A great engineer does not tune models, but designs environments.

A model can be extremely powerful, yet without a Harness, it is like a skilled craftsman with no workbench — even the finest skills cannot be put to use.

In the engineering world, reliability matters more than cleverness.

This article draws on in-depth analyses of AI architecture, Agent engineering and Multi-Agent Harness, combined with personal practical insights.

← Back to Articles