Back to Home
Enterprise AIJan 19, 20262:00 PM EST

Architecting the Agentic Enterprise

Dippu Singh walks through the architectural decisions enterprises face when moving from AI assistants to AI agents — covering orchestration layers, trust boundaries, data governance, and why most enterprise AI projects stall at the pilot stage.

D
Dippu SinghData & AI Leader, Fujitsu North America

What This Session Is About

The shift from AI assistants to AI agents changes everything about enterprise architecture. Assistants respond to prompts. Agents take actions — they write to databases, send emails, trigger workflows, and spin up other agents. That capability gap requires a completely different approach to security, governance, and organizational design.

Dippu drew on his experience leading data initiatives at Fujitsu North America to map out what enterprise-grade agentic infrastructure actually looks like — and why most organizations underestimate the non-technical work required to make it real.

The Four Pillars of Agentic Architecture

Orchestration layer

A central orchestrator coordinates multiple specialized agents, routes tasks, manages context, and handles failures. Without this, each AI initiative becomes a silo. The orchestrator is where enterprise value compounds — it can sequence agents that would otherwise operate independently.

Trust & permission model

Agents that can take actions need explicit permission boundaries. Dippu emphasized scoped credentials, action allowlists, and audit trails as non-negotiable. The question isn't just "can the agent do this?" — it's "should it, and how do we know when it does?"

Governed data access

Agents need to read and sometimes write enterprise data. That requires integrating with existing identity providers, row-level security policies, and data contracts. An agent that can query customer records is a potential compliance incident if not governed correctly from the start.

Human-in-the-loop by design

Not every action should be fully automated. Dippu's framework distinguishes between low-stakes actions (auto-approve), medium-stakes (notify and allow override), and high-stakes (require human approval). The thresholds should be defined by business teams, not engineers.

Key Insights

  • 01
    Most enterprise AI projects stall at the pilot because the data layer isn't ready. Agents need clean, accessible, well-documented data. Enterprises that invested in data mesh and catalog initiatives before the AI wave are moving significantly faster than those that didn't.
  • 02
    The orchestration layer is the moat. Individual agent capabilities commoditize quickly. The durable competitive advantage is how well your orchestration layer integrates agents with enterprise context — your customers, your workflows, your history.
  • 03
    Security for agentic systems is not an add-on. Prompt injection, credential sprawl, and unauthorized data exfiltration are not hypothetical — they've already occurred in early enterprise deployments. Dippu argued that security architecture must be designed before the first agent goes to production.
  • 04
    Change management is the longest critical path. The technology is often ready before the organization is. Employees need to understand what the agents do, what they don't do, and how to escalate when something goes wrong. Building that muscle takes longer than building the agents.
  • 05
    Start narrow, instrument everything, expand deliberately. The enterprises making the most progress in 2026 are the ones that picked one high-value, bounded workflow, deployed a production agent, measured rigorously, and used that proof point to earn budget and trust for the next one.
  • 06
    Model selection matters less than context quality. Dippu's observation: the difference between a mediocre and excellent enterprise agent is rarely the underlying model. It's the quality of the context — retrieved data, system instructions, memory — that determines output quality in production.
"

The enterprises winning at AI agents are not the ones with the best models. They're the ones with the best data, the best governance, and the organizational patience to deploy iteratively.

— Dippu Singh

From the Q&A

How do you decide which workflows to agentify first?

Three filters: high frequency (run many times per week), high cost of human time, and bounded scope (can be evaluated with clear success criteria). Workflows that meet all three criteria make the best initial candidates. Avoid starting with anything that requires nuanced judgment or has ambiguous success criteria.

How do you handle agents that make mistakes?

Design for reversibility. For every action an agent can take, define the rollback. If the agent sends an email, you can't unsend it — so email sending should start as a draft-and-review flow, not fully autonomous. Escalate the autonomy level incrementally as the error rate proves acceptable.

What's your take on build vs. buy for the orchestration layer?

At Fujitsu NA, they evaluated building on LangGraph, AutoGen, and several commercial orchestration platforms. For most enterprises in 2026, commercial orchestration platforms have caught up with custom builds — and the maintenance burden of a custom orchestrator is usually underestimated. The exception is when you have very specific compliance requirements that commercial platforms don't yet support.

What skills gaps are you seeing in enterprise data teams?

Two underestimated gaps: prompt engineering at production quality (not the chatbot level, but the system-prompt-for-enterprise-agent level), and evaluation design. Teams know how to ship features. Knowing how to measure whether an AI agent is actually performing well in production is a different and rare skill.