The Architect Has to Be in the Room

The email goes out on a Tuesday. After a six-month evaluation that included vendor demos, a security review, and a per-seat price negotiated down twice, the firm has chosen its AI platform. Training is scheduled for the following week. The note is signed by the managing partner and the head of innovation, and it is, by any fair reading, good news. The tool is capable. The diligence was real. The people who ran the process were careful.

Look at who ran it. A managing partner, an innovation lead, someone from IT, someone from procurement, almost certainly someone from risk. Now look at who was not in the room: the partner whose name will go on the first cross-border opinion the tool helps produce. She receives the system as a finished decision (a login, a training slot, a workflow already shaped by people who will never sign anything it generates).

Two years later, in an audit her client did not see coming, she is asked about a citation in that opinion. Where did this authority come from. Was it in force on the relevant date. She did not write it; the system surfaced it, and the process that governs how the system surfaces anything was settled before she first logged in. She can defend the conclusion; that is her judgment, and she owns it. What she cannot fully account for is the machine that helped her reach it, because she was handed the machine rather than asked to build it.

That gap — between whoever designs how a professional system reasons and whoever answers for what it produces — is the subject of this essay. The consulting world has been telling firms, correctly, that AI disappoints when run as a technology project. I want to travel almost all the way with that argument, and then point to the single place it breaks for a profession.

---

The diagnosis everyone now shares

The case is worth stating at full strength before I touch it. It is strong, and largely right.

Bain’s current guidance^[1] argues that AI fails when treated as a technology rollout rather than a redesign of the business that the technology makes possible. The repeated advice is to put people before tools, deciding deliberately where a human stays in the loop, and staffing the effort with teams fluent in both the business and the technology. By Bain’s own reckoning, most companies investing in AI have not seen a measurable impact; the ones that do, modernize the workflow and the workforce together.

BCG supplies the sharpest number.^[2] Asked where the effort of putting AI to work actually goes, the firm assigns rough weights: the algorithm is about ten percent, the technology and data twenty, and the people and process changes around it the remaining seventy. The model (the part everyone shops for) is the smallest slice.

Strip the house styles away and the two are saying one thing. The tool is not where the value is. The value is in who owns the work the tool touches, and in whether that owner will take the work apart and rebuild it rather than bolt the tool on. I agree. The problem is rarely the model. The problem is that the firm bought the ten percent and declared the project finished.

---

The assumption hiding in the prescription

Here is where I stop traveling with the consensus, and the gap is narrow but it runs deep.

Read the prescription again with one question in mind: who is the architect, and who does the work? For Bain the answer is bilingual teams placing bets across the enterprise. For BCG the seventy percent is people and process: roles redrawn, incentives reset, change managed through the ranks. Both pictures share an assumption so natural in a corporate setting that it never has to be stated: the enterprise owns the output. A company can design a system that thousands of other people operate, because the thing it produces (a forecast, a price, an approved loan) belongs to the company, not to any individual who touched it. Accountability is institutional. It can be designed by one person and discharged by another.

In a regulated profession that assumption fails, and it fails in a precise way I want to separate from a claim I have made before. An earlier essay argued that the conclusion of professional work needs a human name on it, and that responsibility cannot transfer to a system with no name to put on the file. I take that as settled. But it is not the claim here, and the two are easy to run together. You can put your name on a conclusion a machine reached. You can read it, test it, agree with it, sign it, and answer for it (satisfying every rule about whose name goes on the file) while having had no hand in how the machine reached it. Signing is necessary. It is not sufficient. The requirement this essay is about sits upstream of the signature: the person who signs has to own the design of how the system reasons, because that design is where the position is quietly won or lost, long before anyone reads it. A professional who inherits the reasoning and merely ratifies the result has satisfied the letter of the first principle and missed the one that decides the case.

This is not abstract for me. I built one.

Applied honestly to a profession, the consulting prescription mutates into something more demanding than either firm intends. “The accountable leader must be the architect” is sound advice when the leader and the accountable party are one office. In a profession they come apart. The managing partner is accountable for the firm; the signing professional is accountable for the opinion; and it is the opinion, not the firm, that gets tested in the room. The architect of how a professional system reasons therefore cannot be a CEO, an innovation officer, or a procurement committee. It has to be the person who will put their name on what the system produces, or someone who answers directly to that person. The seventy percent BCG locates in people and process is not, for a profession, change management aimed at adoption. It is the authorship of the system’s reasoning by the people who will defend it.

---

Filed under the wrong heading

There is a tell in how this advice is organized, and it sits in the most people-centered parts of it.

Bain files its strongest counsel, to put people first, under adoption and change. How to get an organization to trust a system and use it. Read the same advice from inside a profession and it is describing something more. The experts brought into the build are not there to be persuaded to use the tool. They are authoring its judgment: deciding what it should reason over, correcting what it concludes, ruling some outputs sound and others not. That is not a change-management layer resting on top of the real work. In a domain where being wrong has consequences, it is the real work. The model is the ten percent. The people deciding what it should reason about, and checking whether its reasoning survives contact with reality, are a large part of the seventy. Called trust-building, the more exact word is ownership.

The negative image is by now well documented. In late 2025 a major firm partially refunded a government client after errors (including invented citations) were found in an AI-assisted report.^[3] The instructive thing is not that a model produced a bad citation; models do that, and a system can be engineered so they cannot reach the page. The instructive thing is structural. A capable tool was placed into the delivery of professional work without the reasoning being owned by the professionals who signed the result. The ten percent was bought; the seventy percent was skipped, the part where someone who would answer for the output decides how the output gets made, and verifies that it holds. The work came out looking signed. It was not, in the sense that matters, owned. In a profession that produces a sharper artifact than a stalled pilot: a document shaped like an opinion that no one can fully stand behind.

---

How this gets built

ktAi exists because I could not, in honest practice, sign what general-purpose tools produced, and could not delegate the design of what would produce something signable to anyone but myself.

The system is an assembly line in the sense the consultants describe: an orchestrator, specialized analysis across Israeli law, US law, the treaty between them, and risk patterns, and a layer that pulls those readings into a single position. What it is not is a general-purpose tool handed to a professional with its reasoning sealed inside it. The architecture is built around the person who will sign: citations are rendered from authority actually retrieved rather than generated as fluent text; disagreement between the two legal systems is carried forward rather than averaged into a confident-looking number; the conditions under which the system declines to opine are deliberate rather than incidental. It issues nothing under its own authority, and it does not ask the signing professional to inherit reasoning they had no hand in shaping. There is a good deal it does not yet do well, and we name those gaps rather than paper over them. What is not negotiable is who the machine answers to.

---

The decision that actually matters

Return to the Tuesday email. The firm did a careful job of the wrong task. It treated the adoption of a professional reasoning system as a purchasing decision about which tool, at which price, with which security posture, and made it the way an organization buys software, through the people who buy software. The consulting consensus is right that this is not how AI pays off, and right that the answer is to make it a redesign owned at the level of real accountability rather than a technology project run beneath it. I would only add the correction the profession forces. The decision that matters was never which platform to license. It was who owns how the platform reasons, and whether that person is the same one who will be in the room when the opinion it helped produce is read by someone whose job is to find its weakest seam.

For a corporation, those can be different people, and the org chart absorbs the seam. For a licensed professional they cannot, because the seam is exactly what gets pulled at, and there is one name on the file. The architecture of judgment cannot be owned by anyone who will not answer for the judgment. Whether a system built on that principle holds up — against real authority, in the room where it eventually gets read — is not something a manifesto settles. It is something this company earns one report at a time.