Dhivya Nagasubramanian, VP of AI Transformation and Innovation – Interview Series

Dhivya Nagasubramanian, VP of AI Transformation and Innovation at a major U.S. financial institution, has authored 'Agentic AI for Engineers' (Apress/Springer Nature), a practical guide to building production-grade autonomous AI systems, which has recorded over 6,000 institutional accesses on SpringerLink and holdings in over 260 libraries worldwide. The book addresses the gap between AI research and enterprise deployment, emphasizing that in regulated finance, the most dangerous failure is a wrong number that looks right, and that agents take action based on outputs, raising the stakes.

Interviews https://www.unite.ai/series/interviews/ Dhivya Nagasubramanian, VP of AI Transformation and Innovation – Interview Series Add Unite.AI to your preferred sources on Google https://www.google.com/preferences/source?q=unite.ai Dhivya Nagasubramanian https://www.linkedin.com/in/dhivyanagasubramanian/ is VP of AI Transformation and Innovation at a major U.S. financial institution, where she leads the design, deployment, and governance of production agentic AI systems. She is the author of Agentic AI for Engineers https://link.springer.com/book/10.1007/979-8-8688-2361-9 Apress/Springer Nature , a practical guide to building autonomous AI systems that can be trusted in production. Since its release, the book has recorded more than 6,000 institutional accesses on SpringerLink, holdings in over 260 libraries worldwide, and adoption across universities. She is a USPTO-granted patent holder in applied machine learning. Her research interests include building applications that are resistant to adversarial jailbreak attacks and contributing to broader industry efforts to develop better models for multicultural safety and security. She is a sought-after expert speaker and panelist across multiple industry and academic conferences. Your career has progressed from enterprise consulting and data science into leading AI transformation within financial services. How did those experiences shape Agentic AI for Engineers, and what recurring gap between AI research and enterprise deployment convinced you that this book needed to be written? I started in 2008 building portfolio accounting and performance measurement systems for banking platforms. One of those projects was a GIPS-compliant engine for calculating time-weighted returns, which financial institutions in more than 80 countries eventually used. That work taught me a lesson that has shaped my whole career. In regulated finance, the most dangerous failure is a wrong number that looks right. A subtly incorrect calculation gets trusted, reported, and acted on for years, because nothing appears broken. I saw the same pattern again later. I found a structural gap in the Markov model of a widely used marketing attribution model. The framework was used by hundreds of thousands of users, and the error had survived for years for one reason: the outputs looked reasonable. When I moved into AI transformation in financial services, I watched agentic systems repeat this pattern with much higher stakes. An agent does not just produce a wrong result. It takes action based on it. The gap that convinced me to write the book is that research and enterprise deployment care about different things. Research measures capability on benchmarks. Enterprises depend on how a system behaves under ambiguity, changing data, and adversarial pressure. Most writing about agents stops at the demo stage. I wrote Agentic AI for Engineers for the engineer who has to put their name on a system that will run with limited supervision inside a regulated institution. The book describes the shift from automation to autonomy as a new engineering mindset. What truly separates an autonomous AI agent from a sophisticated automated workflow, and where are organizations most likely to confuse the two? I give teams a simple test. Can you list every path the system can take before you run it? If yes, you have automation. It may be very sophisticated automation with a language model inside it, but it is still automation. If the system breaks down goals, picks tools, and decides the order of actions at runtime based on context you did not script, you have autonomy. The difference has nothing to do with which model you use. It comes down to where the decisions are made. Organizations confuse the two in both directions, but only one direction is expensive. Calling a scripted LLM workflow agentic is mostly a marketing problem. The costly mistake is the reverse. Teams deploy genuinely autonomous decision-making under governance that was designed for deterministic automation. Their testing assumes repeatability. Their monitoring assumes known failure patterns. Their audit trail assumes there is a traceable rule behind every action. None of those assumptions hold for an agent. That is the mindset shift I argue for in the book. With automation, the main question is whether the system executed correctly. With autonomy, the question becomes whether the system decided correctly. Answering that requires different instrumentation, different evaluation methods, and a different level of caution. Many agentic AI systems perform impressively in demonstrations but struggle when exposed to real users, changing data, and unpredictable tools. What components should be considered mandatory in a production-ready agent architecture? The honest answer is that production needs everything a demo lets you skip. A demonstration works because someone controlled the environment. Production takes that control away. In the book, I describe a seven-layer reference architecture, but these are the components I consider mandatory. Tool contracts with typed inputs and explicit permissions, so the agent’s reach is limited by design rather than by hope. State management that survives interruptions and failures. Structured failure handling with defined escalation paths. An evaluation harness that runs continuously, not once before launch. And an audit trail that records decisions and the reasoning behind them, not just the actions taken. The component teams skip most often is runtime verification. This is a layer that checks every action against the agent’s stated objective and the policies that apply to it. Standard infrastructure tells you whether a call succeeded. Verification asks whether the call should have been made at all. It never proves its value in a demo, because nothing in a demo needs to be caught. In production, it is the first thing you will wish you had. Your book covers safety, alignment, feedback loops, testing, debugging, evaluation, and deployment. How should engineering teams combine these elements into a continuous assurance process rather than treating safety as a final pre-launch review? A final review rests on the assumption that the system you reviewed is the system that will run. For agentic AI, that assumption fails in three ways. The underlying models get updated. The tools and APIs the agent depends on change. And the data and environment the agent operates in keep shifting. A one-time safety review describes a system that no longer exists a few months later. Continuous assurance means closing the loop. Behavioral evaluations run in CI continuous integration the same way unit tests do, and they gate every change to prompts, tools, and models. Runtime monitoring feeds production traces back into the evaluation sets. I describe four monitoring patterns in the book, because no single pattern covers the full failure surface. Every incident produces a new check, the same way every bug should produce a regression test. And adversarial testing runs on a regular schedule instead of once before launch. The organizational side matters as much as the technical side. Safety cannot be a separate team that shows up at the end with a checklist. The engineers who build the agent should own its evaluation suites, its invariants, and its escalation design, because they know better than anyone where the system’s judgment is weakest. You have emphasized semantic monitoring of agent tool calls. What does semantic monitoring reveal that conventional logs and observability tools cannot, and how can it detect when an agent is technically functioning but pursuing the wrong objective? Conventional observability answers one question: did the call succeed? It covers status codes, schemas, latency, and error rates. It cannot answer the question that matters most for agents, which is whether the call should have happened. A tool call can be technically perfect and still be the wrong action. Right format, valid credentials, successful response, wrong thing to do. Semantic monitoring evaluates every action against the agent’s stated objective and the policies that apply to it. In the book, I describe this as defining semantic invariants over agent tool calls. These are properties that must hold no matter what path the agent takes. An agent researching one customer’s case should never access records outside that case. An agent should flag a discrepancy above a certain threshold, never resolve it on its own. When an invariant is violated, you catch the problem at the moment of action instead of in a quarterly audit. This is also how you detect goal drift, which I consider the defining failure of agentic systems. Goal drift looks like an agent that completes every step correctly according to the logs while quietly working toward the wrong objective. It never shows up in a log, because nothing failed. Semantic monitoring treats intent as something you measure directly, and intent is where agents go wrong. When an agent encounters ambiguous instructions, conflicting policies, unavailable tools, or insufficient confidence, what should structured failure handling look like? How can developers ensure the system pauses, escalates, or recovers instead of improvising? The problem to design against is that most agents have only one way to end a task, which is to produce an answer. When instructions are ambiguous or policies conflict, the agent improvises. Not because the model is reckless, but because improvising is the only behavior the architecture allows. Structured failure handling means giving the system better options and making them easier to reach than a made-up answer. In practice, that means refusal and escalation are designed and tested with the same care as success. I recommend defining typed failure states: ambiguous instruction, conflicting policy, unavailable tool, insufficient confidence. Each one maps to a specific behavior. Ask a clarifying question. Hand off to a human with full context attached. Drop to read only operation. Retry within tighter limits. Or stop. Confidence thresholds should match the risk of the specific action. The bar for drafting an internal summary and the bar for touching a customer account should never be the same number. Two practices make this real. First, design the escalation path before the happy path. If a human will receive the handoff, decide what context they get and what authority they have before you write the first prompt. Second, test failure the way you test features. Inject ambiguous instructions. Disable tools in staging. Feed the agent conflicting policies. A system that has never practiced failing will act without guidance the first time it happens in production. Financial institutions must balance experimentation with strict requirements around privacy, auditability, model risk, and regulatory compliance. Where should human approval remain mandatory, and where can agents safely be given greater operational autonomy? My rule is that human approval should stay mandatory for any action that is irreversible, that moves money or affects a patient’s outcome, that involves customer communications carrying regulatory weight, that feeds regulatory reporting, or that changes the agent’s own tools, policies, or permissions. Agents can safely take on more autonomy in read and reason work: research, retrieval, document analysis, triage, drafting, and reconciliations that flag discrepancies for human review instead of resolving them. The common mistake is requiring human approval at every step. That does not make the system safer. It recreates the manual process with extra steps and trains reviewers to rubber stamp. Approvals belong at real decision points. There should be few of them, and each should be staffed by someone with actual authority to say no. The other principle is that autonomy should be earned rather than granted. Start narrow. Expand as the system proves itself under monitoring. Keep the evidence. In model risk terms, your control environment should let you show a regulator not only what the agent did, but why you were justified in giving it that level of independence. That record is the real license to operate. Through your work on artificial intelligence safeguards and standards, you are helping define rules for systems whose capabilities continue to change. Which safeguards can realistically be standardized today, and which areas remain too dependent on context, industry, or use case? The safeguards we can standardize today are structural. They require that certain controls exist, are documented, and can be inspected. Documented capability and permission boundaries for autonomous systems. Defined human oversight and escalation mechanisms. Incident detection and reporting obligations. Evaluation methods and evidence requirements. Clear accountability across the system lifecycle, so that when something goes wrong, the answer to who is responsible is never just the AI. These can be standardized because they concern whether the controls exist and how good they are, not the specific values they take. What we cannot yet standardize are the settings themselves. Specific confidence thresholds, harm taxonomies, and appropriate autonomy levels depend heavily on context. The acceptable failure tolerance for a marketing content agent and for a system that touches clinical or financial decisions are not two points on the same scale. They belong to different regimes, shaped by the domain, the jurisdiction, and who bears the harm when something fails. Financial controls are a useful model here. Audit requirements are standardized globally, but materiality is always judged in context. Standards that respect that split tend to get adopted. Standards that try to dictate context-dependent values tend to get ignored, and a safety standard nobody follows protects no one. Your recent research has explored multicultural and adversarial robustness in AI safety evaluation. What kinds of model failures are likely to be missed by Western-centric or globally averaged benchmarks, and how should enterprises evaluate systems intended for multicultural deployment? Looking only at averaged benchmarks can miss the failures that matter most. A model can post a strong overall safety score while failing badly for a specific language, dialect, or cultural context, because those failures disappear into the average. Western-centric evaluation adds another blind spot. It misses harms that are culturally specific, such as idioms, gestures, and religious or regional contexts where the same output is harmless in one culture and damaging in another. It also under-tests code-switching, transliteration, and non-Western names and entities. There is an adversarial angle as well. Attackers do not target your average performance. They find your weakest slice, and for most models that slice is a lower-resource language or an under-evaluated cultural context. This is what drew me into contributing to multicultural AI safety benchmark research. The core finding is straightforward. Judging safety across cultures requires evaluation data and human judgment drawn from those cultures. You cannot assess harm from outside the context in which it occurs. For enterprises, I suggest three rules. Evaluate every segment you serve, and never accept an average as evidence. Build evaluation sets from your actual customer populations. Run adversarial testing in the languages your customers use. If you serve customers in forty countries and evaluate only in English, you have measured your system for someone else’s deployment. You also hold a granted United States Patent and Trademark Office patent in applied AI. What problem were you attempting to solve, what did the process teach you about turning AI research into practical innovation, and which unresolved agentic AI challenge are you most interested in addressing next? The patent that was recently approved addresses a scale-and-consistency problem in financial services quality review — conventional call review is manual, so human reviewers can only sample a fraction of calls, and their assessments vary from person to person. My approach routes each quality and compliance question to the method best suited to answer it, with every decision logged and traceable for audit. You can see the same themes I have described throughout this interview. Route each task to the least powerful tool that can do it well. Keep humans in the loop where judgment matters. And make every automated decision traceable, because in a regulated institution an answer without evidence is not an answer. What the patent process taught me is that the discipline is in the specifics. You cannot patent a vague idea. You have to show exactly what your method does differently, and exactly where it applies. That forced precision made the underlying work better. The unsolved challenge I care most about now is runtime verification for multi-agent systems. Defining semantic invariants for a single agent is manageable. I know, because we do it in production. When agents delegate work to other agents, behavior becomes emergent, and the failures move into the handoffs. An instruction gets slightly reinterpreted at each step. A policy applies to one agent but not to the agent it recruits. Verifying the interaction between agents, not just the actions of each one, is where I expect the next generation of silent failures to appear. That is the problem I want to work on next. Thank you for the great interview, readers may also want to order her book Agentic AI for Engineers.