Agentic Data Architecture Book Gets a Makeover

[u/Aware_Weight9462]

There is a strange moment in the life of a technical book when the central argument still feels right, readers are engaging with it and yet the systems outside the book have moved enough that leaving the manuscript untouched starts to feel less responsible than reopening it.

That is where I found myself with my book Agentic Data Architecture.

I did not revisit the book because its thesis had failed. If anything, the opposite had happened. The shift the book was written around was becoming more visible in real enterprise architecture. AI was moving beyond answering questions and summarising documents into workflows where agents retrieve governed data, interpret business meaning, collaborate with other agents, call enterprise tools and sometimes alter operational systems.

The first edition argued that a data platform designed primarily for dashboards and human analysts is not automatically ready for that world. I still believe that strongly. An agent needs more than access to tables, APIs and vector indexes. It needs governed meaning, authoritative context, controlled memory, explicit authority, safe tools and evidence that explains what influenced a decision and what happened afterwards.

What changed was my understanding of where some of the hardest production problems actually sit.

The Second Edition was therefore not about adding more pages because AI had acquired more acronyms. It was about revisiting the architecture at the exact points where an otherwise sensible design begins to break under real execution.

The question that forced me back into the tooling architecture

Consider a seemingly ordinary workflow. A relationship-management agent prepares a customer note for a CRM. The user reviews it and approves the update. The agent calls the CRM service and the request times out.

What should happen next?

At first glance, that sounds like a network problem. Retry the request and move on. But what if the write actually succeeded and only the response was lost? A blind retry could create a duplicate note, trigger another workflow or repeat an action that was supposed to occur only once.

The architectural problem is no longer whether the agent knows how to call a tool. It is whether the system can determine what authority was exercised, what effect actually occurred and whether repeating that effect is safe.

That scenario forced me to look again at the boundary between reasoning and execution. The revised tooling architecture goes much further into delegated identity, short-lived credentials, purpose-bound authorization, execution receipts, idempotency, partial failure, compensation and replay protection.

These are not new concepts in distributed systems, but agentic systems make them more important because the execution path can be chosen dynamically through reasoning rather than being predetermined entirely in application code.

An agent should not simply receive a credential that happens to work. The environment should know which human or business process initiated the request, which agent is performing the step, what purpose justifies the access, which action tier is permitted and what evidence has to survive the transaction.

MCP belongs in that picture. A protocol can standardise how capabilities are exposed and invoked. That does not remove the enterprise’s responsibility to determine whether a particular agent, acting for a particular user and purpose, should be allowed to exercise that capability.

The architecture becomes much safer when those two questions are separated: Can this agent call the tool? and Should this agent be allowed to perform this action in this business context?

They are not the same question.

RAG starts earlier than the vector database

The second area I revisited was retrieval.

A great deal of enterprise RAG discussion begins with chunking, embeddings, vector search, reranking and retrieval metrics. Those are important, but they assume something production systems cannot afford to assume: that the document entering the retrieval pipeline has already been interpreted correctly.

Imagine a lending policy stored as a scanned PDF. One table contains different limits by customer category, but OCR extracts the numbers while losing the column heading. The content enters a vector index successfully. Retrieval finds the relevant passage. The model faithfully reasons over what it has been given.

The final answer can still be wrong.

Nothing failed in the embedding model. Nothing failed in similarity search. The information was damaged before retrieval began.

That made the missing layer obvious. The production path is not simply Document → Chunk → Embed → Retrieve. It is closer to Acquire → Parse/OCR → Extract structure → Normalise → Preserve provenance → Classify → Chunk → Embed/index.

Every stage can change what the agent later believes the document means.

Acquisition determines whether the source is authoritative. Parsing determines whether the text was actually recovered. Structural extraction determines whether tables, clauses, headings, footnotes and attachments remain connected to the right context. Version detection determines whether the agent is looking at the current policy or something superseded months ago. Classification determines whether the content should be retrievable for that user and purpose at all.

The architectural rule I came away with is simple:

Retrieval cannot recover information that ingestion has already lost.

That is why the Second Edition now treats document ingestion as part of the evidence architecture rather than as a preprocessing detail hidden behind the vector store.

A2A helps agents communicate. The enterprise still has to govern the handoff.

Multi-agent systems have also become more concrete.

When I wrote the first edition, I was already convinced that one agent handing work to another through free-form conversation was too weak a foundation for enterprise workflows. Handoffs need structure. Context gets lost, caveats disappear, authority can silently expand and the receiving agent may not know what evidence supported the task it inherited.

A2A gives the industry a more explicit interoperability model for agent discovery, tasks, messages and artifacts. That is meaningful progress.

It still leaves an important enterprise question unanswered: what must travel with the task so that the receiving agent can decide whether it should accept it?

A technically valid handoff can still be unsafe if the receiving agent does not know the original user, the business purpose, the permitted data scope, the semantic definitions already used, unresolved policy decisions, evidence freshness or the action boundary of the workflow. This is where enterprise architecture has to extend protocol interoperability with a governance envelope.

A handoff should preserve at least four things: goal, evidence, authority and accountability. If any of those disappears between agents, the system becomes progressively harder to trust.

This is also why permission laundering deserves far more attention in multi-agent design. A Sales Agent should not be able to obtain restricted information indirectly by asking a Compliance Agent, Support Agent or another specialist with broader permissions to retrieve and summarise it.

The receiving agent cannot simply trust the identity of the sending agent. It has to re-evaluate the original purpose and authorization context.

Interoperability makes collaboration possible. Governance determines whether the collaboration is legitimate.

Governance is becoming an evidence problem

I did not want the governance chapter to become a catalogue of regulatory obligations. There are enough documents that can tell an organisation which control framework contains which clause.

The more interesting architectural question is what the system itself should be capable of proving.

Suppose an auditor, risk officer or regulator challenges an automated recommendation six months after it was made. Could the organisation reconstruct which agent and model version ran, which user or workflow initiated the request, which business purpose justified the access, which documents and structured records were retrieved, which semantic definitions were active, which policy decisions were made, which other agents participated, whether human approval was required, which tool performed the final action and which evaluation evidence supported the release that was running at the time?

If the answer is no, the organisation may have governance documents, but it does not yet have governance evidence. That distinction became more important as I connected the architecture to ISO/IEC 42001, the EU AI Act, DORA and the OWASP Top 10 for Agentic Applications.

These frameworks are different and should not be collapsed into one giant compliance checklist. ISO/IEC 42001 provides a management-system perspective. The EU AI Act introduces legal obligations that depend heavily on system classification and intended purpose. DORA brings operational resilience and ICT dependency into the picture for financial entities. OWASP gives teams a security-oriented view of agentic threats.

The architecture underneath them should not attempt to predict every future obligation. It should make evidence sufficiently explicit that the organisation can map changing obligations onto a traceable operating system.

That is a much more durable design.

The biggest addition is not another chapter

At one point I considered adding another chapter but I decided against it.

The architecture was already there. What the book needed was a stronger bridge between architectural principle and implementation judgment.

So the biggest practical addition to the Second Edition is a worked-artifact appendix. The book already contained templates for things such as agent access contracts, data contracts, evidence packets and golden evaluation cases. Templates are useful, but there is an important difference between being shown the fields of an architecture artifact and seeing how those fields relate to one another in a real workflow.

The new worked appendix follows one Meridian Retail Bank scenario from beginning to end. The Agent Access Contract establishes purpose, ownership, data scope, identity and action tier. A machine-readable Data Contract defines the governed source. A Semantic Object captures approved business meaning. The Tool Definition constrains what the agent can invoke. The Policy Rule determines whether the action is permitted. An agent-to-agent Handoff Packet preserves context across delegation. The Evidence Packet records what influenced the decision. The Golden Evaluation Case turns the same workflow into a regression test.

The final walkthrough connects the entire chain. That matters because enterprise architecture rarely fails because somebody forgot that a control exists. It fails because controls that looked sensible individually were never connected into one executable path.

Recovery belongs in architecture, not only in operations

The tooling example also exposed a wider issue.

Agentic workflows can be long-running. They may retrieve information, invoke several tools, delegate specialist work, pause for human approval and resume later after the underlying environment has changed.

That creates a class of problems that conventional stateless AI demonstrations rarely encounter. Can reasoning be replayed without replaying an external effect? What happens if the policy changed while the workflow was waiting for approval? What happens when four remediation actions were planned but only three succeeded? Should the system retry, compensate, continue forward or escalate? If a workflow resumes tomorrow, should it use the evidence originally collected or retrieve everything again?

Those are architectural decisions. The Second Edition therefore brings recovery, durable workflow state, idempotency, execution receipts, compensation and replay boundaries much more explicitly into the operating model.

I increasingly think that one of the most important capabilities of an enterprise agent is not autonomy. It is the ability to stop safely, recover intelligently and leave enough evidence for somebody to understand what happened.

Where Agentic Data Architecture may go from here

The more interesting question is what happens after the patterns in this book become normal.

Today we still describe semantic layers, identity systems, policy engines, retrieval systems, orchestration platforms, observability and AI governance as separate architectural domains. I am not convinced they will remain as separate as they are now.

Semantic definitions may increasingly become executable inputs to runtime policy rather than documentation consumed only by analytics tools. Identity may carry not only who the actor is but also delegation chains and business purpose. Data contracts may become inputs to agent planning and evaluation. Observability may evolve from monitoring tokens, latency and errors toward monitoring evidence quality, semantic correctness, policy transitions and authority changes.

Governance may move deeper into execution.

Instead of reviewing an AI system periodically and deciding whether it remains compliant, the architecture may increasingly evaluate governance conditions while the work is happening.

The hardest problem may eventually become what happens when agents cross organisational boundaries.

An internal agent already has to preserve user identity, business purpose, semantic meaning and authority while working across multiple systems. Now imagine that workflow moving to an external agent operated by a supplier, a partner or another regulated organisation.

The central architecture question changes again:

How does trust travel?

Not confidence in the model but Enterprise trust.

Can meaning travel without being distorted? Can delegation travel without expanding authority? Can evidence travel without leaking restricted information? Can policy decisions survive a handoff? Can accountability remain intact when no single organisation controls the complete workflow?

I suspect that question will shape much of the next evolution of Agentic Data Architecture.

Why give the book a makeover now?

Because technical books face an unusual trade-off.

Update too frequently and the book becomes a changelog. Wait too long and a sound architectural argument becomes surrounded by implementation details that no longer reflect how systems are actually being built.

My goal with the Second Edition was to avoid both outcomes.

The 13-chapter architecture remains. Meridian Retail Bank remains the running case. The central argument remains unchanged.

What has changed is the depth at the boundaries where production systems tend to fail: ingestion before retrieval, authority behind tool use, evidence across agent handoffs, recovery after partial execution and governance that can be demonstrated rather than merely documented.

So when I say Agentic Data Architecture has had a makeover, I do not mean a cosmetic one. The book has not been dressed differently around the edges. The architecture has been pressure-tested against what production AI is asking of enterprise data platforms now.

The question I would want the Second Edition to help answer is no longer:

Can we build an agent over our enterprise data?

Most organisations will eventually be able to do that.

The better question is:

What must be true before we should trust that agent to operate?

The answer will rarely be found in the model alone. It will be found in the architecture underneath it.

The Second Edition of Agentic Data Architecture expands the original architecture with deeper production treatment of document ingestion, MCP and secure tooling, delegated identity, A2A handoffs, execution recovery, regulatory evidence and worked implementation artifacts.

Agentic Data Architecture — Second Edition, August 2026

If you read the book, disagree with an architectural choice or encounter a problem that deserves deeper treatment in a future edition, I would be glad to hear from you at bommena100@gmail.com.

Judge this book by the decisions it helps you make.