This week on Juejin, we found a rare in-depth architecture retrospective: an AI engineer documents in detail how a team restructured an investment-research Agent (an AI assistant that autonomously plans multi-step tasks) between January and September 2026, arriving at one judgment: the model owns semantics, the Runtime (the environment outside the model, responsible for scheduling and state) owns process, the MCP (the standard interface connecting models to tools/data) owns capability, and the Skill (reusable method packages) owns methods.
It's highly technical, but the signal matters more than the code: for building an Agent that "works reliably," the hard part has shifted from "is the model smart enough" to "who should own what."
What this is
In the early phase, the author's team had the model maintain a Runtime state mirror—remaining attempts, permissions, cancellation flags—alongside its next-action output. They found the model had to both understand the problem and repeatedly maintain "facts the system already knows." The latter is expensive and carries no authority.
Later, they pushed all deterministic logic (authorization, budgets, checkpoint, recovery) down to the Runtime—and found the Runtime getting heavier and heavier, beginning to take over business-capability definitions. The September 26, 2026 refactor used 438 files and 3,915 test cases to consolidate tool definitions previously scattered across three places into a single Tool Contract.
As of September 30, 2026, the article's takeaway: semantic decisions can go to the model; authority and recovery cannot.
Industry view
Retrospectives of this depth are uncommon in the Chinese tech community. Most Agent articles still discuss "switch to a bigger model" or "add more tools." Few address the boundary between Runtime and Model.
But three caveats are worth flagging. First, this is the experience of a financial-research Agent—with complex toolchains and dense state. An ordinary customer-service Q&A Agent has no need for this four-layer division; copying it would be over-engineering. Second, MCP as a protocol is still evolving rapidly; a call layer designed around MCP today may need to be rewritten next year. Third, an engineering effort of 438 files and 3,915 test cases is only sustainable by teams with comparable investment—small teams copying this approach will be dragged down by maintenance costs first.
Impact on regular people
For enterprise IT: when evaluating AI Agent vendors, ask directly, "How do you split state between your Runtime and the model, and how do you handle failure recovery?" Vendors who can explain this clearly are worth a serious look; those who can't, however flashy their demos, are paper-thin.
For individual careers: when everyday AI writing and Agent tools feel "almost usable but always falling short," the root cause is exactly these architectural issues—not your usage.
For the consumer market: consumer AI products should be as simple as possible. This heavy-duty architecture suits enterprise Agents; ordinary users don't need to pay a premium for "semantic clarity."