翻訳待ち：Building Production Agentic AI at IBM: Architecture, Decisions, and Lessons

AI サービスが一時的に利用できないため、復旧後に翻訳を補完します。

Building Production Agentic AI at IBM: Architecture, Decisions, and What We Learned TL;DR — IBM’s Technology Lifecycle Services built a multi-agent system from scratch — the agents themselves in Python with LangGraph. In production since fall 2025, it gives every TLS role one place to ask questions that used to span a dozen systems. What I’d tell someone starting the same project: Use A2A for every agent boundary, MCP for every tool boundary. That uniformity is what let five of our six specialist agents be built by separate teams, one in an entirely separate environment. Carry the user’s identity through every hop — propagate or exchange, never substitute a service account. The moment one delegation drops the caller’s identity, authorization quietly leaves the enterprise’s model for yours. Easy to get wrong, brutal to retrofit. Instrument before you build — evals, traces, business metrics — with tools that exist today. We flew blind too long: tracing stalled on shifting internal roadmaps, evals arrived after the changes they should have guarded, and a business baseline never arrived at all. Sooner would have mattered more than any architectural decision. The real constraint was never agent code — it was data access. Everyone wants an agent factory, a team stamping out new agents; we needed a data factory — finding the systems of record, negotiating access, building the tool layer. Independent teams are easy to add and hard to align. The same boundaries that let them plug in let each prioritize its own backlog. We shipped a better reasoning pattern everyone agreed made sense; most of our agents still don’t use it. Introduction As I described in my previous post on building trustworthy AI, I’m a senior architect in the IBM Infrastructure AI Center of Excellence (AI CoE), a group focused on accelerating responsible AI adoption across the IBM Infrastructure business unit — putting AI to work for IBM’s own employees, not just its clients. For the past couple of years I’ve been something of a double agent: officially part of the AI CoE, but embedded full-time in IBM’s Technology Lifecycle Services (TLS) organization, where I’ve been serving as Chief Architect for the TLS Agentic Platform. TLS is a large organization with thousands of employees within IBM Infrastructure that provides hardware and software support, maintenance, and lifecycle management worldwide. The TLS Agentic Platform is the full system: a multi-agent AI system, the Model Context Protocol (MCP) tool servers and APIs that connect it to enterprise data, and the cloud environment everything runs on. Its front end is the TLS Concierge — a single AI experience built to give every TLS employee one place to go. One interface, one conversation, whether the question is about a support case, a hardware asset, a contract, or a client’s history. The goal is to eliminate the context-switching across a dozen different systems that currently consumes so much of a TLS professional’s day. We built it from the ground up and had real users in production within months of starting — and have been evolving it ever since. If you read my earlier post on the IBM Cloud console’s evolution from monolith to microservices, this post is the next chapter of that same story. The architectural philosophy is the same: decompose complexity into independently deployable units, build shared infrastructure that scales, be honest about what went wrong. But the technology has shifted in ways nobody in the industry fully anticipated — that post predates the ChatGPT moment by over a year. The services are still independently deployed, the patterns are still familiar — but when a service’s core logic is an LLM reasoning over tools rather than deterministic code executing a defined path, the differences matter in ways that aren’t obvious until you’re operating one in production. That context matters for everything that follows. Every architectural decision I’ll describe was made inside a real service organization at real scale, where an agent giving bad information to an IBM employee can have real consequences for an actual client. Enterprise AI constraints — compliance, audit trails, long-running operations — were not academic concerns here. They were the requirements that shaped the architecture from day one. TLS and Its AI Strategy TLS has been on a deliberate AI journey for several years. IBM Fellows Bala Rajaraman and Kyle Brown wrote about the vision behind TLS’s AI investment: using AI to move TLS from a reactive support model to a proactive, insight-driven one, measuring success not just by ticket resolution metrics but by the client outcomes those metrics are supposed to represent. IBM VP Dylan Boday frames the operational case: integrated data center support reduces downtime and total cost of ownership when the people and tools providing that support have the right information at the right moment. IBM VP Bina Hallman describes the practical shape of that investment: watsonx-powered Agent Assist surfacing relevant knowledge during case work, AI-generated case summaries reducing the effort of managing complex multi-week engagements, and automated Call Home processing that handles 91% of hardware error notifications end-to-end without client intervention. Agents in the agentic sense — autonomous systems reasoning over tools and acting on their own — appear nowhere in those posts. For the first few years, TLS’s AI work was focused on AI-infused features and assistive tooling: surface the relevant data, reduce manual lookup, give support engineers better information faster. That work established some early data pipelines and integrations, but TLS didn’t yet have a coherent AI platform to build on. A significant part of my first year embedded in TLS was helping design and build that foundation: a secure cloud environment for running AI workloads, integrations to the systems of record, a model deployment and governance framework drawing on the AI CoE work I described in my trustworthy AI post. When agentic AI moved from research curiosity to production reality, that platform is what made it possible to go from a workshop in May 2025 to real users in production by fall, with the platform continuing to grow from there. That’s what this post is about: what building that agentic layer actually looked like, on top of an existing AI foundation, inside a large service organization with real production requirements. Personas and Use Cases Understanding who your users are and what they’re trying to accomplish is old advice. It binds harder on an agentic system: you aren’t designing screens for tasks you’ve already scoped, you’re building something that has to handle whatever a user thinks to ask. The initial use case centered on the Technical Escalation Manager (TEM), a role that can spend hours of manual effort getting up to speed on a new escalation before reaching out to a client: reading through long case histories, cross-referencing asset data, finding relevant technical documentation. That’s a real operational pain point in a large service organization, not a demo use case invented for a conference talk, and it was the seed the rest of the platform grew from. From that starting point the platform expanded to cover a broader set of TLS roles. Below is a sampling of key personas and the kinds of scenarios the platform supports for each. RoleDescriptionRepresentative scenarios Technical Escalation ManagerManages critical escalations and coordinates technical resourcesRapidly get up to speed on a new escalation — case history, asset details, business impact — so the first client conversation is informed and productive; draft status updates grounded in the actual case data Client Manager / Client Success ManagerOwns overall client relationship and successInteractively explore a client’s support history; generate tailored insights and PowerPoint content for a client review High Availability Center of Competence (HACoC) SpecialistCross-platform high-availability architecture and consultingAnalyze a client’s infrastructure environment ahead of a workshop; generate a findings and recommendations report post-session Sales / Global Contract OfficeDrives revenue; manages contract portfolioAsk natural-language questions about contract terms and obligations; identify revenue opportunities embedded in existing agreements Technical Account Manager / Client Availability LeaderProactive technical guidance and availability managementSurface asset visibility gaps and proactive risk indicators across a client’s installed base Remote Technical SupportFront-line technical support engineers resolving client issuesPull relevant technical documentation and case history for an active support issue TLS Concierge The TLS Concierge is the front end of the platform, built on IBM’s Carbon for AI design system to give every TLS role a single place to work. Its centerpiece is AskTLS, an open-ended chat for any persona: type a question, and the platform figures out which agents and data sources are needed to answer it. Alongside it sit workflows tailored to specific personas — experiences that feature the same conversational core but structure it around a particular role’s tasks rather than leaving everything to open-ended chat. The screenshot below shows AskTLS handling the kind of question a Technical Escalation Manager might ask when first picking up a new escalation: a natural-language query about the major events in a case, answered with a synthesized, structured timeline pulled from the case system. Ready to read in seconds rather than assembled manually over the course of hours. The TLS Concierge with AskTLS open — one front end giving every TLS role access to the full agentic platform. Full System Architecture The TLS Agentic Platform spans the full stack: from the Concierge front end through the multi-agent system to the cloud infrastructure described below. It began with the TEM use case; the architecture that emerged from that initial work is what’s in production today. The TLS Agentic Platform in production. A representative slice — the Supervisor routes to more specialist agents than are shown individually. The diagram reads top to bottom, from the user interface down through the agents to the systems of record. The legend tells the visual story: the dark blue Supervisor sits at the top of the agent hierarchy; lighter blue boxes are the specialist agents; grey filled boxes are MCP tool servers; plain white boxes are APIs, services, and data stores; and dashed boxes are external systems the platform doesn’t own. The line colors carry the protocols — blue for A2A between agents, slate for MCP from an agent to a tool server, grey for ordinary service and data calls. Here’s what each layer does. Frontend. The Concierge UI never speaks directly to agents. It routes through a Next.js Backend for Frontend (BFF) layer that handles authentication, session management, rate limiting, and the SSE streaming connection to the browser. The BFF talks to the Supervisor Agent using Agent2Agent (A2A), the same protocol the agents use among themselves. A separate external-facing Support Insights UI, owned by the IBM Support Insights team, surfaces analytics and reporting over its own data. Agents. Behind the BFF sits the Supervisor Agent, the system’s routing intelligence. All agents are built in Python using LangGraph; most began on a standard ReAct loop, and the platform is now moving toward the skills-based deep agent pattern described later. The Supervisor receives every user request, determines intent, and delegates to the appropriate specialist agent via A2A rather than an in-process call — a choice I’ll come back to below. Each specialist is an independently deployed service responsible for a distinct domain: AgentDomain Case AgentCase summaries, timelines, and similar-case retrieval Asset AgentHardware inventory and [truncated for AI cost control]