Drawing Organizational Charts for AI Agents: Mapping Agents to Business Capabilities

In 2016, Yao Anfeng translated Jez Humble's *The Lean Enterprise* into Chinese—a book about how companies scale innovation using lean and agile methods. Ten years later, on his podcast "Jichuan She" (霁川社), he released a new episode: how enterprises should scale their planning of AI agents. A decade apart, the two projects follow the same thread—how organizations absorb a new capability.

The episode's core claim can be compressed into one sentence: the essence of an agent is not software, it is capability. An agent is a capability unit. So when an enterprise introduces agents, it should not start with "which model to buy." It should start with an old, familiar diagram—the business capability architecture.

An Old Map from Management Science

Business capability architecture is not new. Enterprise architecture has used it for decades: break down what a company can do into a list, where each cell is a capability—"process returns and exchanges" is one cell, "risk approval" is another. The cells are relatively stable; the systems and departments implementing them underneath can change freely. Consulting firms have drawn countless such charts.

Yao's update is here: every cell can now be mapped to an agent. He calls this process the "distillation" of capabilities—extracting the know-how scattered across people, processes, and institutional rules into independently runnable capability components, each carried by an agent.

From Informatization to Agentic Workflows: Where Is the Dividing Line?

One judgment from the episode deserves to be singled out: the essential difference between informatization, intelligentization, and agentic workflows is that AI has gained the ability to complete uncertain tasks within a process.

Informatization solved deterministic tasks—expense reimbursement, inventory records—where rules are clear and systems simply follow them. Software ate those jobs decades ago. The new territory of agentic workflows is what remains: judging how to handle a particular complaint, deciding whether an anomaly in a supplier report signals risk, choosing which lead to investigate next. These tasks previously had no hard-coded rules; only humans could do them. Now there are machines that can make judgments.

This dividing line quietly matches a consensus that has formed in the technical community over the past year: in a mature agent system, the parts requiring judgment go to the model, and everything else is deterministic engineering—anything that can be written as a rule should never be left to the model. What management calls "uncertain tasks" and what engineers call "work that should go to the model" are the same territory.

Eight Cells, One Agent

The episode defines a capability with eight elements:

1. Accountability (responsibility ownership) 2. Core entities 3. Sensing (perception) 4. Expertise (professional knowledge) 5. Judgment 6. Action capability 7. Output/deliverable capability 8. Capability evaluation

Translated into a technology stack, these map to familiar components:

| Element | Technical equivalent | |---|---| | Sensing | Input interfaces, context collection | | Expertise | Knowledge bases, retrieval | | Judgment | The model | | Action | Tool calling | | Output | Deliverable formats | | Evaluation | Test sets, evaluation pipelines | | Core entities | The objects the system operates on | | Accountability | Governance |

The model occupies only one of the eight cells. The remaining seven are all engineering outside the model. This breakdown aligns with many practitioners' approach: an agent's ceiling is the model, but whether it is usable and trustworthy depends on the other seven cells. The accountability cell in particular—who is to blame when something goes wrong, who can sign off on taking an agent offline—is an organizational problem, not a technical one, and it is often the last cell anyone thinks about.

Blueprint vs. Checklist

Yao places this methodology inside his own "OED (Organizational Effectiveness Development) framework," and the domain capability map is what he calls the blueprint for organizational capability building.

One boundary needs to be made clear: a blueprint is planning language, not a delivery guarantee. A capability map can tell you which agents to build and what each should govern, but whether agents actually work in practice comes back to the most labor-intensive of the eight elements—capability evaluation. With rigorous evaluation, each cell on the map can be safely handed to machines; with sloppy evaluation, even the most beautiful architecture chart is just a slide deck. This is a common weakness of all methodology content, not a flaw specific to this episode.

But the value of methodology lies not in guarantees—in sequencing. It translates the slogan "the company should use AI" into a checklist that can be filled in cell by cell: which capability to build first, which to evaluate first, who is responsible when something breaks. For managers pushing agents into their organizations, a checklist they can actually follow is more useful than ten predictions that "AI will change everything."

---

*This post is organized from the podcast script and summary; the episode is in audio form. The "OED framework" is the author's own creation with no independently retrievable publication. Yao Anfeng is also the author of "Adaptation: A Practical Guide to Enterprise Digital Business Management" (Tsinghua University Press).*