# Occam Has His Work Cut Out When agents can read shared code, state, and results directly, structures built for broken context have to earn their keep again. Purpose, boundaries, evidence, and reversibility are harder to cut. ## Metadata - HTML: https://glenzli.com/en/notes/occam-is-busy/ - Markdown: https://glenzli.com/en/notes/occam-is-busy.md - Collection: Notes - Language: en - Published: 2026-07-26 - Updated: 2026-08-17 - Tags: ai, software-engineering, agents, architecture, protocols, judgment ## Content I have been putting several agents to work on a complex desktop application, pushing different parts of the same codebase forward in parallel. Talk about multi-agent work, and protocol design arrives almost immediately: message formats, task states, scheduling, conflict handling. Ideally, all of it gets settled before the agents touch the same file. I have never been eager to start there. The collaboration has not happened yet, but the protocol already knows exactly how it should work. Without a real project underneath it, the design tends to collapse into a collection of nouns: roles, messages, states, schedulers. The details that actually decide whether people can work together only appear after they enter the same repository and begin changing the same files. So I did not hand the agents a finished protocol. I gave them a relationship and a few boundaries. They shared one project. The other agents were collaborators. They should maintain a small working contract, then revise it when the work exposed a reason to do so. The contract was thin. Everyone served the same goal. Changes to shared files affected other participants. Overlapping work had to be adjusted. A finished task had to leave something another participant could inspect. It said little about how to claim work, hand off shared files, or decide when a conversation was necessary. Let the collaboration happen first. ## Coordination Lives in the Work Coordination here does not mean assigning agents the roles of product manager, architect, and engineer, then asking them to stage a meeting. Human teams need meetings, reports, and explicit roles partly because context lives in separate heads. People have to step away from the work and reconstruct, in language, what everyone has done, what they are doing, and what they intend to do next. Agents work under different conditions. Given the right permissions, they can inspect the same repository, task state, test results, and change history. A work claim reveals scope. A patch reveals actual intent. A test result says more than a polished status update. An updated claim, a revised patch, or a new test result may already complete the information exchange. Coordination does not always need its own conversation. It can live inside the work. During that project, two agents collided. One held a lock that temporarily blocked the other. Had I designed the entire recovery process in advance, I would probably have added polling, timeouts, cancellation, and resumption rules. What happened was simpler. The waiting agent used Codex's existing cross-task notifications. When the state changed, it received a message and resumed. No polling. No exit. The agents later formed more specific handoff patterns around the work itself. If one needed a small edit while another would occupy the same area for a long time, the first handed the task over. If one needed a file that still contained another agent's unfinished requirement, it could claim that requirement and finish both pieces together. These were not job titles in disguise. They came from the size of the change, the duration of the claim, and the state of the repository at that moment. The environment also exposed a boundary. An agent may finish its own task without waking the collaborator whose work still needs to continue. The chain is not broken. Nobody necessarily picks it up. That leaves real questions: which state must persist, when waiting is safe, and when an explicit handoff is required. Those choices still need judgment. That miss taught us more than an imaginary recovery mechanism would have. Notifications were reusable. Continuity after an interruption could not be assumed. I did not remove myself from the process, either. Agents can revise local working habits. The shared goal, permission boundaries, and approval conditions for high-impact actions do not get to drift because one handoff happened to go smoothly. Across vendors, organizations, and trust boundaries, identity, authorization, message provenance, and failure semantics should be standardized in advance. Inside a shared repository with a common goal, the amount of protocol should be shaped by known risks, environmental constraints, and failures that actually occur. The protocol can arrive late. The boundaries cannot. ## The Conditions Changed Zoom out from this one experiment and the same question appears across AI software engineering. Implementation is cheaper, so front-loaded process built to prevent expensive rework needs a new cost calculation. Feedback is faster, so requirements, development, and use do not always need to remain in a fixed sequence. Agents are becoming software users, so interfaces, manuals, and onboarding flows no longer define every practical use. Model capability keeps moving, and scaffolding built around a temporary gap may expire before the paint is dry. The structures did not suddenly turn bad. What supported them changed. Many familiar structures were built for expensive implementation, slow feedback, fragmented context, and components that could barely interpret intent. They had a history. They solved real problems. Once the conditions change, history is no longer a justification. What risk did this process once reduce, and does it still reduce it? What information did this document preserve, and can that information now be recovered from the code and its history? What change did this interface once isolate, and is it isolating risk today—or merely isolating understanding? Old does not mean obsolete. Familiar does not mean exempt. ## Judge the Job, Not the Label The same structure can do several jobs at once. A document may merely restate the code, or it may preserve a decision that cannot be reconstructed from the current state. A workflow may force tasks through an inherited sequence, or it may assign responsibility, confirm risk, and leave audit evidence. A schema helps systems exchange data, but it also keeps meaning intact across teams and versions. An agent's ability to read code does not make documentation useless. Natural language can express intent, but that does not make deterministic interfaces disposable. Labels do not decide what stays. Jobs do. Some structures organize the work in front of us. They move information, impose an order, or compensate for a temporary capability gap. Once every participant can reliably recover the same context, those structures can shrink, become temporary, or disappear. Other structures protect reality. They draw permission boundaries, preserve evidence, fix responsibility, and stop one mistaken interpretation from crossing the whole system. The more capable the executor becomes, the less vague those structures can afford to be. The division is not clean. A single file may coordinate today's work and preserve a decision that must not be lost. Calling it permanent or temporary settles nothing. The useful question is: > What, exactly, disappears if we delete it? If the answer is one layer of format conversion, it can probably go. If authority, facts, and responsibility become ambiguous, it should stay—and may need to become clearer. ## What the Blade Must Spare AI likes to invoke Occam's razor. The usual shorthand is simple: do not multiply entities beyond necessity. In software, those entities become APIs, documents, workflows, protocols, and architectures. The blade is already out. We still need to know what it must spare. Set those forms aside for a moment, and only a few things are truly difficult to remove. Purpose and judgment must stay. A system needs to know why it is acting, which results deserve to survive, when to continue, and when to stop. Cheap execution should not discount judgment. Otherwise, rapid production only repeats mistakes faster. Authority and boundaries must stay. Which data may be read, which systems may be changed, and which actions require human approval cannot rest on the line, "the model should understand." Greater capability gives a single misjudgment a larger blast radius. Facts, evidence, and necessary history must stay as well. Participants need to know what happened, what can be trusted, and why a decision was made. Code, tests, runtime records, and observed state usually beat anyone's eloquent memory of the process. Finally, there must be rollback and responsibility. As long as interpretation can fail, errors must be detectable, containable, and reversible. Irreversible actions need stronger approval. When something does go wrong, responsibility cannot vanish into a chain of agent calls. APIs, documents, workflows, protocols, and architectures have a reason to exist when they still protect these things. If they protect nothing and remain only because they have always been there, they should make room. ## Occam Has His Work Cut Out Occam's razor was never an instruction to delete without limit. It only asks every entity we introduce to explain why it exists. The razor will be busy in the AI era. Inherited software structures need another inspection. New A2A protocols, agent workflows, and model scaffolds do not earn permanent residency merely because AI appears in the name. Does a structure organize the work in front of us, or protect a boundary that cannot be negotiated away? Does it preserve a fact we cannot recover, or repeat information we already have? Did it grow out of a failure that happened, or out of the anxiety that every possible case should be covered in advance? Some structures will disappear. Some will shrink. Some will move from permanent infrastructure to scaffolding assembled for the task at hand. At the same time, boundaries connected directly to real-world consequences will need to become sharper. AI is not taking software engineering toward a world without structure. It is taking away more structures' automatic claim to permanence. Minimal order does not mean the fewest rules. It means making what must be settled in advance unmistakably clear, while leaving room for the rest to form through practice. As the conditions of implementation, interpretation, and collaboration change, software engineering does not need another argument about whether APIs, processes, documents, and architectures should exist. It needs to ask: > What are they still protecting today? ## Related Materials - [The Half-Life of AI Scaffolding](https://glenzli.com/en/notes/half-life-of-ai-scaffolding) - [When Software Time Begins to Loosen](https://glenzli.com/en/notes/software-time-loosens) - [Beyond the Manual](https://glenzli.com/en/notes/software-beyond-the-manual) - [When Speed Changes the Shape of Exploration](https://glenzli.com/en/notes/speed-matters) - [AI Software Engineering Notes](https://github.com/glenzli/ai-software-engineering-notes)