REWIRE
A practical method for making AI useful inside a real company
Adapted from a book in progress on AI, crypto, and the machine-readable company.
For the last five posts, I have been making the same argument from different angles: most companies do not have an AI problem. They have an illegibility problem. This is the practical answer to that diagnosis.
I have seen the same underlying issue from three very different vantage points: around business process reengineering in the 1990s, inside the decision-preparation machinery of Deutsche Telekom, and now at Blockdaemon, building in a world where AI is no longer a side topic but part of the operating environment itself. The lesson across all three is consistent. Technology does not fix broken operating design. It reveals it, accelerates it, and occasionally makes it sound more coherent than it really is.
That is why I think the right question is not, “How do we deploy AI?” The right question is: what does the company have to become for AI to be useful, trustworthy, and worth scaling? My answer is a six-part method I call REWIRE:
Reframe the business around value flows
Externalize tacit work
Wire the system of truth
Insert AI at the decision edges
Reorganize around flows, not functions
Enterprise-harden the new system
Most companies try to start at step four. That is how they end up with demos instead of operating leverage.
One more point matters before the method itself. Making a company machine-readable does not mean making everything visible to everyone. In the old software world, access control mostly answered a static question: can this user open this system? In the AI world, the question gets much harder. What can this identity see, retrieve, combine, summarize, infer, and act on through the model? AI readiness is not just a workflow problem or a data problem. It is also a permissions problem.
1. Reframe the business around value flows
The first move is to stop looking at the company through the org chart. Customers do not buy reporting lines or internal departmental boundaries. They buy an outcome. That was true in the reengineering era, and it is even more true now.
At Blockdaemon, this has been obvious for a long time. Institutional customers do not want one answer from product, another from engineering, a third from security, and a fourth from delivery. They want one accountable surface and one coherent answer they can trust. Once you see the business that way, AI stops looking like a collection of local productivity tools and starts looking like part of the company’s ability to sense, interpret, and improve the path from customer demand to delivered outcome.
That distinction matters. If you frame the business by function, sales gets an AI assistant, engineering gets another, and support gets a third. The company becomes a federation of smarter silos. If you frame it by value flow, you start asking a different question: where does value slow down, distort, or lose accountability? When an institution asks whether you can support a workflow under a particular security posture by a particular date, that is not just a product question or a security question. It is a flow question touching commercial commitments, product readiness, engineering capacity, security review, runtime reliability, and delivery ownership all at once. If that flow is fragmented, AI will only make each local answer sound cleaner. It will not make the company more coherent.
2. Externalize tacit work
This is the step most leadership teams underestimate because so much company life runs on hidden labor. Large organizations depend on tracing, filtering, summarizing, framing, and context stitching long before anyone calls it AI.
I saw that clearly at Deutsche Telekom. Significant decisions did not arrive at the top in raw form. They were prepared by layers of people whose job was to make the company legible enough for executives and board members to act. In other words, serious companies already had a human intelligence layer. AI is now being asked to compress part of that layer, but it cannot compress work that the company never made explicit in the first place.
That is why so many AI efforts feel thin. The real process often lives in meetings, side channels, unwritten rules, copied spreadsheets, and the heads of the few people everyone calls when something breaks. At Blockdaemon, that became concrete during the konstant.cloud journey. The difficult part was never getting a model to produce words. The difficult part was getting enough of the company’s real context into a form that could be grounded, queried, and trusted. That means externalizing what companies usually leave vague: who owns the decision, what was actually decided, what changed since last week, where exceptions happened, why a customer issue took the path it did, and which source is canonical versus merely conversational. Until that work is done, humans keep rediscovering context and AI keeps guessing. Neither is an operating model.
3. Wire the system of truth
Once tacit work is surfaced, the next move is deciding where truth lives. This is where many AI programs quietly collapse, because the company has one version of reality in tickets, another in CRM, another in Slack, another in meeting notes, another in spreadsheets, and a sixth in people’s heads. Then leadership asks AI for a summary as if there were one coherent ground truth underneath it all.
At Blockdaemon, one of the clearest lessons has been that “AI strategy” is actually at least two different problems that companies often muddle together. The first is the AI layer itself: copilots, retrieval, workflow support, agents, decision prep. The second is the data foundation beneath it: where truth lives, how systems connect, how stable the sources are, and whether the model is being fed something coherent enough to reason over. Those two tracks are linked, but they are not the same.
A useful AI layer needs at least four kinds of readable state: work state, decision state, runtime truth, and permission state. Work state tells you what is in flight, who owns it, what changed, and what is blocked. Decision state preserves what was decided, by whom, with what assumptions, and what would change the call. Runtime truth connects live system behavior to commercial and operating reality. Permission state determines who is allowed to see what, retrieve what, combine what, and act where.
This is one reason I keep coming back to a fairly unglamorous point: a better view is useful, but a second truth is dangerous. For execution tracking, the logic inside Blockdaemon has been straightforward. Jira holds the operating truth; other layers can visualize it more elegantly, but they cannot compete with it. The moment the presentation layer starts pretending to be a separate source of truth, ambiguity returns precisely where AI needs clarity most.
The same discipline applies to AI integrations. Sensitive systems cannot just be connected directly to whichever model interface happens to be fashionable that quarter. The stronger architecture is controlled connectivity: a gateway boundary where data can be filtered, normalized, permissioned, and logged before it reaches the model. That is what an adult AI data layer looks like. Not maximal connectivity. Controlled connectivity.
4. Insert AI at the decision edges
Only after the first three steps does AI enter the picture directly, and that order matters. AI is most useful where work is high-volume, context-heavy, ambiguous, and expensive to prepare manually. That usually means strategic summaries, decision prep, issue triage, account context stitching, escalation support, first drafts, and source-grounded retrieval across fragmented information.
That is a very different posture from “put AI everywhere.” The first job is not replacing judgment. It is improving the quality and speed of decision preparation. That distinction matters to me because I have seen how much human labor large organizations already devote to preparing leaders to decide. AI changes the economics of that layer dramatically, but only if the company has already done the earlier work.
At Blockdaemon, the valuable AI use cases were never the flashy ones. They were the moments where AI could take dispersed context and turn it into usable clarity without severing the link to underlying truth. That is also where the MCP conversation becomes interesting. The point is not MCP as novelty. The point is MCP as a forcing function. Once you accept that models and agents will increasingly interact with systems through structured interfaces, you stop treating AI as a bolt-on after the APIs are done. You start designing the interface layer with machine use in mind from the beginning.
That is a bigger shift than it sounds. It means new APIs increasingly need to be machine-ready by default, not because protocol terminology is the story, but because the company no longer wants one layer for humans and a second incompatible layer for machines. Still, sequencing matters. Agentic workflows sit downstream of good interfaces. Good interfaces sit downstream of clean systems. Clean systems sit downstream of clear ownership and readable truth.
The same applies to engineering work. AI can accelerate migrations, repetitive implementation, and first-draft code generation, but the real pattern is still prompt, plan, verify. AI compresses effort. Humans review the result, check the edge cases, and decide whether the code is actually fit for use. That is not caution for its own sake. It is how real systems stay real.
5. Reorganize around flows, not functions
Once AI starts exposing where context breaks, a more uncomfortable truth appears. Many company problems are not technology problems at all. They are ownership problems.
If work crosses too many teams, AI will not rescue the flow. It will simply produce better summaries of the delay. If the handoff between sales, product, engineering, security, and delivery is structurally weak, AI will accelerate the distortion before it fixes the outcome. This is where the old reengineering lesson returns with fresh relevance. A company that wants real AI leverage has to reduce unnecessary handoffs, clarify end-to-end ownership, and organize more of its execution around flows instead of isolated functional excellence.
That does not mean functions disappear. It means the value flow becomes the thing leadership watches most closely. This is especially visible in institution-facing businesses because the customer experiences one promise. If the internal system fragments that promise across too many owners, trust degrades quickly.
This is one reason Blockdaemon is such a useful example for the broader argument. In our world, the institutional test and the machine-readability test are nearly the same test. Can the company produce one coherent answer? Can it connect commercial promise to delivery reality? Can it surface risk early enough to act on it? Can it carry the same truth from customer conversation to engineering action to runtime operation? If the answer is no, the customer feels it first. The AI layer just exposes the weakness faster.
6. Enterprise-harden the new system
This is the step that separates serious AI from clever demos. A real AI operating layer needs permissions, provenance, source traceability, human review paths, fallback behavior, clear boundaries around what the system knows and does not know, and auditability around high-consequence outputs and actions.
In a consumer app, getting 80 percent of the way there can still feel magical. In an enterprise, that missing 20 percent is where trust dies. If AI prepares a strategic summary for leadership, people need to know where the underlying facts came from. If it flags a delivery risk, the owner needs a way to inspect the signal. If it drafts an answer for a customer, the system needs to know whether it is allowed to use that context, whether it is crossing a boundary it should not cross, and whether a human review gate sits in front of the action.
That is why hardening is not cleanup. It is part of the design from the start. It is also where the policy-agent idea becomes genuinely interesting in AI terms. The question is no longer just whether a user can open an application. The harder question is what the model can see, retrieve, combine, infer, and act on, and under whose authority it is operating while it does those things. That is a different category of control. It is not screen-level access control. It is reasoning-aware and execution-aware permissioning.
This matters because once AI sits between people and systems, the policy layer is no longer guarding a page. It is governing how intelligence moves through the company. That means selective legibility: enough context to be useful, enough constraint to be trusted, enough authority to help, and not enough authority to quietly become dangerous. Without that architecture, AI centralizes visibility and action in ways that get reckless quickly. With it, AI becomes much more usable inside companies that actually care about trust, auditability, and controlled execution.
This is one reason I think Blockdaemon’s path is instructive. In our world, reliability is not ornamental and trust is not a branding exercise. If a system cannot be explained, governed, permissioned, and inspected, it does not matter how elegant the interface looks. That is true for infrastructure. It is also true for AI.
What REWIRE really means
A company does not become an AI company because it launches a chatbot, an assistant, or an internal prompt library. It becomes an AI company when intelligence is embedded into the operating system of the firm in a way that is readable, permissioned, governable, and tied to reality.
That is the standard behind REWIRE. Reframe the work around value flows. Externalize tacit work. Wire the system of truth. Insert AI at the decision edges. Reorganize around flows. Enterprise-harden the result. Do that well and AI becomes useful. Skip the first three steps and the rest is theater.