By Nandakumar Balasubramaniyan and Archana Yadav · ISOVIA founding partners
Book in progress. This article explains ideas the authors have already shared publicly. It is not an extract from the unpublished manuscript, a launch announcement or an offer to buy or download the book.
A working AI pilot is easy to mistake for a changed organisation. The demonstration shows that a model can do something; it does not settle where the data comes from, who may act on its output, how an exception is handled or who will keep the process fit for purpose six months later. Those are architectural and operating questions. They are the questions behind our forthcoming book, The Kinetic AI Transformation Framework.
The premise is deliberately practical: enterprise AI has to connect existing systems, bounded data access, a considered mix of AI capabilities, controlled orchestration and work that people can govern. The point is not to make every decision autonomous. It is to know which decisions are safe to delegate, which require review and which remain human-led.
Five architectural layers, not five more silos
In our publicly shared reference architecture, the five layers form a way to examine how an AI capability will enter the enterprise. They are interdependent: a sound agent workflow cannot compensate for data nobody can account for, and a strong data platform cannot make unclear authority disappear.
Legacy substrate
Start with the applications, workflows and responsibilities the organisation actually has. A credible AI architecture must meet the existing business somewhere; a clean-sheet diagram is not a migration plan.
Walled data garden
Define what information is permitted to cross the AI boundary, who owns it, how its origin can be checked and what happens when access or quality is inadequate.
Custom AI mix
Select models and techniques against the task, evidence, cost, integration and exit requirements. One general-purpose model is not automatically the right answer for every decision.
Orchestration layer
Coordinate tools and agents inside an explicit execution boundary: what they may do, where approval is required, what is logged and how an exception reaches a person.
Agentic workflows
Put the design into work people can own. Some steps may be automated within approved limits; others need a human in the loop, or a human-led decision assisted by AI.
The authors have also referred publicly to a phased approach to transformation. This short preview does not name or reproduce those unpublished phases, nor does it prescribe a universal sequence for every client.
The execution boundary is a business decision
Imagine a customer-service team evaluating AI-assisted request triage. The demonstration classifies enquiries accurately enough to attract interest. Before it becomes an operating service, someone still has to decide which data the model may read, which requests can be routed without review, how staff correct a mistake and what happens when the system is uncertain. Those answers depend on the use case and its consequences, rather than on how polished the demo looked. This is an illustrative situation, not an ISOVIA client case study.
An execution boundary makes these choices explicit. A narrowly defined, low-consequence step may be automated after evaluation and approval. A sensitive or ambiguous step may require human review. Some decisions should stay human-led, with AI providing evidence rather than authority. Whichever mode applies, ownership, escalation and evidence should travel with the work.
How the thinking relates to ISOVIA's services
The book's five architecture layers are not ISOVIA's five commercial services in another order. The services are entry points for a specific buyer decision; the architecture is a way to reason across the system. An engagement begins where the uncertainty actually sits:
- AI Strategy & RoadmappingWhich use case deserves investment?
- Data Strategy & ReadinessWhich data can actually support it?
- Technology & Vendor AdvisoryWhich technical route preserves choice?
- AI Governance ArchitectureWho can approve, intervene and record the decision?
- Operating Model & ChangeWho will own the work when the pilot ends?
ISOVIA's Aegis governance approach can help structure ownership, risk, controls and evidence within such work. It is distinct from the book's architecture; neither is a promise of a turnkey platform or an outcome without a separately agreed scope. The engagement model explains how a client decision may progress from discovery to a scoped piece of work and, when contracted, into delivery or ongoing support.
Follow the work as it develops
This page will distinguish public ideas from the still-unpublished book as the authors refine and release more material. For the original public architecture and co-author context, read Nandakumar's reference architecture post and Archana's co-development note. Publication and availability details will be added only when confirmed by the authors.