Building Enterprise AI Agents: Frontline Lessons with TrueFoundry

by
0 comments
Building Enterprise AI Agents: Frontline Lessons with TrueFoundry

Panel discussions about AI used to be mostly theoretical. A recent panel hosted by TrueFoundry was different: it brought together leaders who are actually building agentic AI systems at enterprise scale — Kishore Aradhya, head of data engineering and architecture at Frontdoor; Eli Tsinovoy, head of AI at UKG; Shafiq “SQ” Quorashi, senior Android/ML engineer at The New York Times; and Manish Nigam, senior director of AI at Ameriprise Financial. The lessons they shared are frontline observations from teams moving AI out of demos and into governed production systems.

Start small — deliberately

Every panelist emphasized starting small, not from lack of ambition but from experience. Aradhya argued that rushing into elaborate agentic frameworks is a recipe for failure; his team at Frontdoor targets known problems with measurable results — such as automating insurance-claim review — before attempting anything more complex. The pattern echoes what platform teams see repeatedly: real barriers around governance, access, and infrastructure only surface once models leave the demo stage.

The model-access maze

Model access, surprisingly, remains unstandardized. Each company approaches it differently, for defensible reasons. UKG routes everything through Google Cloud’s Vertex AI, gaining model-garden features and token-usage controls without building anything — and is already moving toward LLM proxies for smarter routing and fallbacks. Frontdoor, a decades-old insurance business, runs access through Snowflake because that is where its data governance already lives. Nigam of Ameriprise stressed that in financial services safety is paramount — but that does not mean standing still.

AI gateways: the new battleground

A genuine debate emerged over whether enterprises need specialized AI gateways or whether traditional API gateways can evolve to handle AI traffic. Tsinovoy took the evolutionary view: the network infrastructure is largely the same, and adding semantic measures such as time-to-first-token beats adopting sprawling do-everything platforms. Nigam countered that while tokens, latency, and cost suffice for basic chatbots, agentic systems are a different animal: an agent may choose tools, call multiple APIs in sequence, access a file system, loop repeatedly, and coordinate with other agents. Conventional observability answers what happened; agentic systems must also show why — the logic and the decision path. For insurance claims or financial recommendations, that explanation is owed to users, auditors, regulators, and the teams improving the system.

Tracing is unsolved — everywhere

Strikingly, none of the companies represented has solved enterprise-wide tracing. Quorashi was frank: different teams at The New York Times implement observability differently because their needs differ — a mobile app producing user-facing content needs different tracing than a centralized system feeding many endpoints. His teams are even exploring AI to help monitor AI. The tooling landscape compounds the problem: most observability platforms serve one audience well — engineers want traces, data scientists want evaluation metrics, product managers want user behaviour — and no platform yet serves all three. Tsinovoy evaluated several prominent platforms, including Arize and LangSmith, and came away unsatisfied; demos impressed, but attention to unglamorous requirements like regulatory compliance and on-premises support (often several versions behind cloud offerings) did not.

What “agent” actually means

Definitions of “agent” vary wildly. Nigam offered the cleanest one: an agent is a model plus tools plus memory — all three, or it is something else. The New York Times’ code-analysis work illustrates it: a model that understands code patterns, tools that access the repository, and memory that tracks what has been analyzed, used to find places where design systems are not fully implemented across the codebase.

The under-discussed catch is that non-determinism stacks. LLM output varies; add tool calling and it varies more; coordinate multiple agents and the variance compounds. This is why Aradhya insists on starting with problems humans already solve — a human baseline provides a measurable reference and an understood decision process. Pointing agents at problems nobody understands invites trouble.

The MCP shift

The Model Context Protocol (MCP) drew cautious enthusiasm. Nigam values the standardization: before MCP, every integration with external systems was custom-built, whereas a common framework for file access, tool calls, and API interaction also makes observability more tractable. Tsinovoy is most interested in MCP-enabled memory beyond basic session state — while warning that vendors will soon all claim “memory,” and buyers should ask what kind. He also acknowledged having spent significant effort building capabilities MCP now provides out of the box. Aradhya added perspective: MCP is plumbing, like TCP/IP; the durable value sits in the semantic layer above it — context engineering and knowledge graphs. He cited Andrej Karpathy’s line that context engineering beats prompt engineering.

The two real barriers

Asked about the biggest obstacles to agent adoption, the panel did not name technology. The first is human alignment: stakeholders must be brought along early, or expensive proofs of concept never get implemented — especially for agentic systems that change workflows for people, such as customer-service representatives, who were never trained for AI assistance. Change management at enterprise scale is brutal. The second is starting with solutions instead of problems. Tsinovoy shared a cautionary tale of executive pressure to “do as much AI as possible”: much was built, and most will never create value, because it was technology in search of a problem. The remedy: define what AI does well in the industry — automating repetitive tasks, surfacing insights, decision support, scenario simulation — then map those capabilities to real business problems and chain small wins into larger systems.

Takeaways, limitations, and what to watch

Three conclusions stood out. The companies succeeding with AI agents are not those with the biggest budgets but those that start small, measure obsessively, and build on proven foundations. Infrastructure matters more than models — the panel spent far more time on gateways, observability, and protocols than on LLMs. And the field remains early: when experienced enterprise teams admit they are still figuring it out, that is honesty, not weakness.

Readers should note that these are practitioner opinions from a vendor-hosted panel — TrueFoundry sells AI-infrastructure tooling, so its framing naturally emphasizes gateways and governance — and single-company anecdotes may not generalize. Useful signals to watch include convergence (or not) of AI observability standards, MCP’s maturation as covered in the protocol’s documentation, and whether enterprises publish measurable outcomes from agentic deployments rather than pilots. Related reading on this site: real-time agent interactions on Bedrock AgentCore and x402 and autonomous agent payments.

Related Articles