The Organization Is the Human Harness

Why patches pile into the agent, why the charter comes before the meeting, and why acceptance follows what the user sees — AI amplifies the bias of poor communication.

"Stop the weekend promotion," a merchant tells the store-operations agent. The agent replies at once: "It has been stopped." The next day, member coupons are still going out.

The promotion was created by a legacy system, and "ended" on its dashboard does not mean coupon delivery stopped — the team that truly knows this rule is the promotion system's team. Yet the problem was handed to the agent team: the merchant asked through the agent, and the agent team was the one rushing to ship, so they used AI to patch in a rule — for this kind of legacy activity, stop the coupons separately too. The first store's problem was solved; the next kind of legacy activity had another rule, so another patch went in. After a few rounds, the agent carried a set of legacy-system rules nobody could fully explain.

This is not one team's mistake; it is structural. AI makes patches faster to write, and keeps the faulty boundary alive longer — the bottleneck has moved from individual execution back to the organization: who owns the rule, who confirms the outcome, whether the same word means the same thing. The Mythical Man-Month locates the root of large-project failure in "communication, and its result — the organization"; now that everyone works with their own agent, fast execution amplifies exactly the bias left by insufficient communication jiecuozhe-mythical-man-month. This article covers how each of the three lands.

After reading, you should be able to answer:

• Why do patches keep piling into the agent instead of going to the resource owner?
• When two teams' agents must collaborate, what should exist before the meeting?
• Why is "operation succeeded" not acceptance evidence?

Why patches pile into the agent

Start with ownership. The historical rules stayed in the promotion system while the patches piled into the agent — because "knows the rule" and "gets found" are two different things: the request came through the agent, the agent team was the one rushing to ship, and the team that owned the rule was never brought in. Each problem then looks solved faster than the last, while the root never moves.

The Mythical Man-Month has a name for this shape — the tar pit: "the harder they struggle, the more entangled they become." One department solves its own problem, and the cost may land on the user or another department; fixing one legacy activity only shows that one problem is solved. All activities, old and new, handled under the same agreement — that is a service a merchant can depend on. Without a single owner, the whole product becomes a growing pile of patches.

Rules and patches belong to the owner of the resource. How a legacy activity is closed, and whether it actually closed, is confirmed by the promotion system; the operations agent's job is to understand the merchant, hand the request to the promotion system, and report the confirmed result back — it does not need to copy every legacy activity's internal rules. When the next legacy-activity problem appears, it still goes to the promotion system, because the complete history lives there.

The corresponding engineering move is to write this boundary into the project file so every agent can see it: the AGENTS project contract covers how to fix conventions in place. When responsibility boundaries are blurry, the LLM can only guess rules from the material in front of it, and carry those guesses into later actions.

Write the shared charter before the meeting

Two teams need to agree on an interface but cannot read each other's code. What actually happens today: one agent has read this team's code and documents, another sees a different set of materials — the two sides can ask the same question in collaboration and get different answers. One more role for people at this stage is to be the A2A protocol between teams.

Before the organization can be restructured outright, one ideal working order is: before the meeting, each side has its agent organize an interface description from its own implementation, spelling out what each side is responsible for, how problems are handled, and what counts as a successful integration; in the meeting, only the differences between the two descriptions are reconciled; after the meeting, the conclusions are written into a version both sides adopt, then handed to each side's agent to execute jiecuozhe-mythical-man-month.

This shared charter need not be long, but it must answer six questions: who ends up with what result? Who explains the key rules? Who can actually change the outcome? What can people and agents do right now? When must work stop or escalate to a person? What evidence proves the thing is done?

Look back at the promotion case: what it lacked was exactly this shared material — what "stopped" means, and who confirms the result. Messages were connected, yet the final outcome still had no owner. A shared charter is the same kind of artifact as handoff that holds — only what is written down can be picked up by people and agents alike.

Acceptance is judged by what the user sees

Conceptual integrity is another judgment from The Mythical Man-Month that has not aged: key concepts must keep one meaning and work under one set of rules. When different teams' agents see only their own team's materials, the same word gets written into several different rule sets; those rules each run, and the conflict eventually shows up in front of the user.

The operations agent replies "the promotion has stopped," and the merchant naturally understands that the activity produces no further discounts. If the backend only ended the activity status while coupon delivery continues, then both the system and the agent may show success, yet the product has not kept its promise. So "stopped" needs one agreed definition with a clear maintainer; the owner coordinates each module's implementation and accepts against what the merchant ultimately sees.

"Operation succeeded" only means the command was issued; acceptance evidence must come from the system that owns the resource. This is the other half of the same requirement as define done before the first line of code's "look at evidence, not declarations": that article covers the shape of evidence; this one covers who produces it.

Scheduling cannot escape this either. Forcing a deadline with backward planning is no substitute for decisions like "what does stopping include, and who confirms it": once the date is locked, scope and responsibility keep changing, and vague questions get handed straight to development; the agent quickly fills in the planned code, and the missing premises become even harder to see. Code gets written faster; disagreements surface later.

Who changes the rules, and how bad news travels up

The organization is the human harness: it decides what people can see and do, and it slowly changes behavior through rewards and penalties — people put more effort into whatever the assessment metrics value. The harness itself does not act; its value statements only tell everyone which behaviors cost less effort and which will be punished; over time, the organization keeps getting the same kind of choice jiecuozhe-mythical-man-month.

There is an asymmetry here: people and agents hide bad news for different reasons. Punish only errors, and people choose silence; reward only good news in evals, and the agent drops bad news. Both roads lead to the same place — the organization stops seeing the real situation. A reliable organization admits that people get tired, forget, and misjudge; the role of institutions is to surface problems early and hold the line when individuals slip. If a project can only avoid incidents through overtime, arguments, or a sudden burst of conscience, conscience has already been treated as infrastructure.

The owner cannot be an absentee either: not knowing every system's details is fine, but they must know the rules and be able to change and confirm outcomes. New business cannot have every answer written on day one; moving fast in small steps is fine, but every step must state who is responsible, and the real result decides the next step — write the goal together with responsibility into the work system, let people and agents see the same progress, then accept against real results and revise the rules.