Tony Santiago
AI & Cloud Engineering Leader
Miami, Florida, United States
Actions
Tony Santiago leads CapNexus Applied Intelligence, the AI and AWS practice at a mid-tier technology consultancy, and is the creator of the AI Capability Flywheel. He spent six years at AWS where he co-authored the Cloud Adoption Framework Platform Perspective and the CAF for AI with its maturity assessment, helped Global Systems Integrators and Fortune 500 organizations stand up AI and agentic practices, and enabled more than 30,000 developers. He has published AWS blog posts and code samples across platform engineering, AI, and agentic systems.
Area of Expertise
Topics
Beyond Vibe Coding: Agentic Engineering at Delivery Scale
Vibe coding does not produce velocity. Agentic engineering does. If your AI coding rollout this year did not move your team's numbers, you are part of the paradox METR measured in 2025 (19% slower with 20% perceived speedup) and DORA validated at scale. AI is an amplifier of the engineering system it lands in. The tools work. Most rollouts fail. But what if the constraint is not the tools you bought, but the system you didn't build?
In this talk you'll see how a 70-engineer delivery org rebuilt itself in five months around eight operating directives and an agentic layer that builds the system that builds the system. You will leave with the rebuilt org diagram, the AI Development Lifecycle (AIDLC), one AI Engineering Workflow walked end to end, the measured gains we got past baseline, and the one metric that got worse.
Frameworks and Flywheels: Uncovering the Constraint Holding You Back
Capabilities compound. Projects don't. Most organizations are still managing AI as projects, which is why one in three initiatives are abandoned before production at $4.2M each and why the ones that ship deliver a median ROI of negative 72%. Production at scale doesn't come from better tools. It comes from a capability that compounds across waves of technology, where each rotation of investment makes the next rotation faster.
Six years at AWS working with global systems integrators while co-authoring the Cloud Adoption Framework for AI. I kept seeing the same repeating pattern across hundreds of engagements. The bottleneck was almost never where the organization thought it was. That observation became the AI Capability Flywheel. Four stages (Govern, Structure, Build, Enforce) around a center that changes with each wave of technology, with maturity assessed per stage and the constraint identified as the lowest stage. In this talk you'll see how to run the diagnostic, where the next dollar of AI investment should go, and one engagement where uncovering the constraint changed the entire production curve.
A Portfolio Operating Model for Enterprise AI
AI runtime is not a vendor decision. It is a portfolio decision. Most enterprises pick one substrate and try to force every kind of AI work onto it, then wonder why their data scientists are angry, their auditors are nervous, and their cloud bill grew faster than their adoption curve. The category error is treating runtime as something you procure rather than something you portfolio.
The three-runtime operating model treats enterprise AI as three concurrent tiers, each with different physics. The Practice Runtime where practitioners do daily AI-augmented work. The Headless Runtime where hardened workflows run cost-efficiently at scale. The Orchestrated Runtime where multi-step audit-critical work earns its governance. Tiered by operational substrate, not capability or autonomy. In this talk you'll see why three is the right number, the contract-based promotion gates between tiers, the seven named anti-patterns, and how to build the operating model that surrounds whichever models you pick. Models are commodities on a one-to-two-year clock. Runtime is durable.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top