Your AI Will Automate the Existing Mess

Conway's Law — formulated by Melvin Conway in 1967 and consistently vindicated in software engineering since — states that any system built by an organization will copy that organization's communication structure. Forrester applied it to AI agent deployments in a June 2026 piece, and the extension holds: AI agents deployed into a business process don't redesign that process. They execute it faster and at lower unit cost. If the approval chain has three unnecessary steps, the agent runs three unnecessary steps automatically. If the handoff between two teams is ambiguous, the agent reaches the same ambiguity and applies a deterministic default that's wrong for some percentage of cases. The agent inherits the operating model it's deployed into.

The observation is correct. The implicit conclusion most readers will draw from it is the wrong one: fix your processes before deploying AI, or the AI will automate the mess. That sounds reasonable. Applied consistently, it produces organizations that spend eighteen months on process improvement initiatives, achieve a cleaner operating model on paper, and still haven't deployed anything.

Processes get fixed by a forcing function

The practical problem with "fix the process first" as a prerequisite is that processes don't get fixed in isolation. Processes get fixed when there's a forcing function. An AI deployment that's coming in ninety days is a forcing function. A process improvement program that isn't tied to a specific deployment is a project that tends to run forever at low urgency, producing documentation of a better process that the organization then continues not to use. The cleanup happens in the context of the change, not in advance of it.

The right implication from Forrester's Conway observation isn't "don't deploy until the org is clean." It's "scope the first deployment to the workflow that's already clean enough to automate well, and use the wins from that deployment to fund the process cleanup required for the next one."

Every organization has a range of workflows. Some are genuinely messy: overlapping ownership, inconsistent data, informal escalation paths that nobody has written down because they rely on relationships and context that new employees take six months to accumulate. These workflows shouldn't be automated first. Automating them would do exactly what Forrester describes: inherit the mess and run it faster. But some workflows are relatively clean: single owner, consistent data inputs, well-defined decision boundaries, clear outputs. These are the right entry points. Not because they're necessarily the highest ROI opportunities, but because they're the ones where an agent can actually succeed without first requiring an organizational redesign.

Start with the cleanest workflow you have

The common mistake is letting perfect process be the prerequisite for starting. A VP of Operations who reads the Forrester piece and decides to audit and clean every workflow before deploying anything has, in practice, decided not to deploy this year. There's always another process that isn't clean enough yet. There's always another ownership ambiguity to resolve, another data field to standardize, another escalation path to document. The bar for "ready to automate" keeps moving because there's no external deadline forcing it to stop moving.

The entry-point strategy breaks this cycle. Pick the cleanest workflow you have. It doesn't need to be perfect; it needs to be clean enough that an agent can execute it without inheriting organizational design problems that will surface immediately in production. Automate it. Show the result. Use the result to build organizational confidence, internal credibility for further investment, and the political capital to ask other departments to clean up their processes before the next deployment touches them. The first win creates the conditions for the second deployment to go into a slightly cleaner environment than it would have found if you'd tried to automate everything at once.

Three questions to ask before scoping

The Forrester observation also has a useful pre-deployment diagnostic function. Before scoping any agent deployment, the relevant questions are: who owns each step in this workflow, explicitly, with a name? What does the agent do when it encounters an input it hasn't seen before? Where does ambiguity currently live, and what does a human do when they encounter it? These questions don't need to be answered perfectly before deployment. They need to be answered specifically enough that the agent specification can handle them without producing a wrong-default-at-scale problem.

An agency that asks these questions before writing a specification has thought about Conway's Law, whether or not they call it that. An agency that scopes from a description of the idealized workflow without examining the actual decision points, data structures, and ownership assignments is building for the process as it's described, not as it runs. The gap between those two is where the post-launch surprises live.

Forrester is right that your operating model matters more than your AI model. The implication isn't to wait for a perfect operating model. It's to find the part of your operating model that's already clean enough to automate first, and let the wins from that first engagement fund the cleanup that makes the next one possible.

---

If you want that question answered for your specific situation, the Forge Playbook does it. Answer a few questions about your business and we'll put together a tailored outline of which workflows are worth automating and what a realistic budget looks like for each. Free, no obligation, takes about three minutes.

Get your free Forge Playbook →