IA agentique en entreprise – Partie 2 : Conseils par persona

This is Part II of a two-part series from the AWS Generative AI Innovation Center. If you missed Part I, refer to Operationalizing Agentic AI Part 1: A Stakeholder’s Guide . The biggest barrier to agentic AI isn’t the technology—it’s the operating model. In Part I , we established that organizations generating real value from agents share three traits: they define work in precise detail, they bound autonomy deliberately, and they treat improvement as a continuous habit rather than a one-time project. We also introduced the four ingredients of work that is truly “agent-shaped”: a clear start and end, judgment across tools, observable and measurable success, and a safe failure mode. Without these foundations, even the most sophisticated agent will stall in the lab. Now comes the harder question: who makes it work, and how ? In Part II, we speak directly to the leaders who must turn that shared foundation into action. Each role carries a distinct set of responsibilities, risks, and leverage points. Whether you own a P&L, run enterprise architecture, lead security, govern data, or manage compliance, this section is written in the language of your job—because that’s where agentic AI either succeeds or quietly dies. Part II – Guidance by persona For the line-of-business owner: put the agent on the hook for your KPIs. If you own a P&L, you don’t need another technology toy. You need fewer open tickets, fewer days in your cash conversion cycle, fewer abandoned carts, fewer compliance exceptions. An agent is useful only if it can be tied directly to those numbers. The first step is to write a job description for the agent the same way you would for a new hire. “This agent takes inbound X, checks Y, does Z, and hands off to this team when it’s done.” Include what done means in your operational terms: time to respond, quality threshold, escalation triggers, and customer-facing commitments. The second step is to anchor the business case in numbers your own team already tracks. How many units per week pass through this workflow? What does each unit cost in labor, rework, and write-offs? How long does it spend waiting in queues? How often does it bounce back because something was missing or wrong? If you can’t answer these questions today, your first project isn’t an agent—it’s instrumenting the workflow. The third step is sequencing. Early in the journey, the most useful agent is often the one that collapses handoffs: it reads the inbound request, gathers context from multiple systems, proposes a plan, and drops that plan into your team’s lap with everything pre-staged. It may not close the loop by itself, but it can remove hours or days of back-and-forth. Cost-saving wins like this help build credibility with the CFO and give you political capital to pursue more ambitious, revenue-focused use cases later. The line-of-business owner doesn’t need to understand models or prompts. They need to own a small portfolio of agent jobs tied directly to their metrics, and they need to insist that every initiative starts with a written job contract, not a slide with a label. For the CTO or chief architect: Decide whether you want ten agents or one hundred If you’re the CTO, one of your biggest risks is success. Once the first agent lands well, other teams will want one. If each team builds its own stack—own framework, own connectors, own access model—you’ll end up with a zoo of agents that look different, are tested differently, and are impossible to monitor as a whole. The architecture question is simple to state and hard to execute: do you want ten impressive one-off agents, or do you want a system that can support one hundred agents safely? The system path asks you to do some hard work early. It means standardizing how tools are exposed so that every agent calls the same integration when it needs to read customer data, update a ticket, or book a payment. It means separating thinking from doing in your design: one component plans, another calls tools, another checks compliance, another explains decisions back to users. It means capturing decision traces in a consistent format so observability and debugging work across use cases. It also asks you to think about agents as long-lived services, not short-lived scripts. They need identities, permissions, rotation, lifecycle management, and a way to be upgraded without breaking their consumers. That’s more work on day one, but it’s what allows you to say “Yes” to the tenth team that wants an agent without starting from scratch. The CTO’s job isn’t to pick the best agent framework in a vacuum. It’s to build a sturdy floor—identity, policy enforcement, logging, connectors, and evaluation hooks—that allows many teams to ship agents safely, quickly, and consistently. For the CISO: Treat agents like colleagues, not code If you’re responsible for security, you’re used to thinking in assets: systems, data stores, credentials. Agents add something new to your threat model: authorized entities