AI Summit 2026 Recap: What Worked, What Didn't in Enterprise AI

On September 22, 2026, TorontoAI's biggest night of the year took over OneEleven on Front Street. With 650+ registrations across Luma and Meetup, AI engineers, data leaders, and CTOs came for one thing: honest answers about what actually happens when AI leaves the demo and hits a real enterprise.

Mohit Rajhans (ThinkStart), TorontoAI community ambassador, opened the stage and served as MC for the night.

The centrepiece was a 45-minute panel, "What Worked, What Didn't: Leaders Compare Notes on Real Enterprise AI Rollouts," moderated by TorontoAI organizer Chandan Kumar, with:

• Rina Taddei, Director of Global Sales Corporate Optimization, Air Canada
• Vincent Fortier, Manager, Field Engineering, Databricks
• Shobhit Khandelwal, Founder & CEO, ShyftLabs

It was paired with a live demo from Ezequiel (Eze) Lanza, Sr. Developer Advocate at Intel, on the infrastructure it takes to run AI agents in production (covered below).

The ground rule for panelists was simple: concrete stories with real numbers and real mistakes, no "future of AI" generalities, and disagreement encouraged. They delivered. Below are the key takeaways, in the panelists' own words.

Cold open: "What's one enterprise AI promise that turned out to be a lie?"

Before introductions, each panelist had to answer in one sentence.

"Once the model is smart enough, the rest is just integration." Shobhit Khandelwal, ShyftLabs

"Your data's ready, just point Clippy, err, Copilot at it." Vincent Fortier, Databricks

"The biggest lie was that AI adoption is primarily a technology problem. In my experience, it's been a trust and change-management problem." Rina Taddei, Air Canada

Three different answers, one shared theme that ran through the rest of the night: the model is rarely the thing that breaks.

What worked

Air Canada: from reporting to reasoning

Rina described the shift that changed how Air Canada's corporate sales leaders make decisions. Sales there sits at the intersection of network planning, revenue management, distribution, and customer behaviour, so there is no shortage of data. The problem was that data alone doesn't create decisions.

"Power BI tells us what happened, whereas an AI reasoning layer can help us think before we walk into the room."

Working with Snowflake Cortex and agent-based approaches, the goal was to help leaders ask a better second question: why did something happen, and where should we intervene? The lesson, in her words, "wasn't that AI replaces judgment." AI reduced the effort of synthesizing information across sources, so leaders spent more time discussing actions and less time assembling context. It changed the questions being asked, toward "why, and what do we do about it."

Databricks: three early signals that a rollout will ship

Vincent works where AI strategy decks become production systems, inside some of the most high-accountability environments in Canada. His answer to "what's the earliest signal a rollout ships versus stalls" came as three patterns:

1. A named person whose number moves if it works. Rollouts ship when the owner is measured on the outcome (case-processing time, response SLA, cost per transaction), not when an innovation team has a budget and no operational mandate. His test: in the first meeting, can they name the metric they're accountable for? He contrasted a program director who tied an assistant rollout to a service-delivery metric they personally reported on (shipped in a quarter) with an "AI lab" that produced six proofs of concept in a year and shipped zero.
2. Security and procurement in the room on the first call, not the last. Counterintuitively, the rollouts that ship in high-accountability organizations engage the CISO's delegate and procurement from day one. The stall pattern is a beautiful POC that walks into a nine-month security review it never budgeted for, and dies. Early governance friction is the signal it's real.
3. Real data in the first working session. If the team can reach its own governed data in week one, the project moves. If every data pull is a ticket to another department, it "dies of thirst before the model matters."

What didn't: "The technology worked. The project still failed. What killed it?"

This was the core of the panel, and every answer pointed somewhere other than the model.

The $150,000 weekend (Vincent Fortier)

An enterprise customer used an LLM to validate physical addresses. Tested on 10,000 addresses, it worked great. Then they scaled it to 4 million addresses with no cost controls, no budget guardrail, and no batching strategy. It ran over a weekend and racked up a bill of roughly $150,000.

The technology worked perfectly. There was simply no governance, so the money was spent before anyone was watching. Vincent's lesson: cost is a governance surface too. A working model with no spend guardrail is a loaded gun.

His second story was quieter but just as common: a POC funded from an innovation budget, with a working model and nobody to take it to production and no funding vehicle for run cost. It died at the handoff. In large public-sector organizations, build money and run money come from different places, and if that isn't lined up on day one, "the best demo of the year still dies."

The pricing platform that worked online (Shobhit Khandelwal)

Shobhit's team deployed a pricing platform for a large retailer. It worked well online, then failed when it expanded beyond the pilot stores.

"The technology worked, but we hadn't accounted for the labor and operational constraints of changing prices across physical locations. We had optimized the pricing decision without accounting for the execution effort."

Technical success is not adoption (Rina Taddei)

Rina described the same gap from inside the business. Early on, teams evaluated copilots, agents, prompts, platforms, and POCs, and the technology was often impressive. But people needed to understand how AI fit into their work before they trusted it: where the data came from, whether outputs could be trusted, and how much validation was required.

"The project wasn't successful when the model worked. The project became successful about a year later, when people started to change their behaviour and actually started making decisions differently because they trusted the output."

On where trust actually comes from:

"I don't think trust comes from telling people AI is accurate. Trust comes from transparency."

The governance debate

This is where the panel had its sharpest exchange. Is governance the blocker, or the thing that makes speed possible? Rina's position:

"Governance isn't the enemy of AI. Unclear governance is. If people know the rules, know the approved data sources, and know how to manage risk, they can move surprisingly fast."

That lines up closely with Vincent's point that security and procurement friction on day one is a sign a project is real, not a sign it's doomed.

The cost of overpromising autonomy (Shobhit Khandelwal)

Shobhit took on the most hyped word in enterprise AI right now, "autonomous":

"You end up moving work rather than removing it. Reading an invoice, recommending approval and releasing payment are three different responsibilities. Calling all three 'an autonomous finance agent' hides the important details."

Who has authority? What needs approval? What happens if a payment request times out and nobody knows whether it went through? "You can't solve that by telling the model to be more careful." His prescription: start with a bounded task, measure the outcome, and expand authority only when the controls support it.

"Autonomy should be earned one action at a time, not promised for an entire job."

Rapid fire

From Shobhit Khandelwal:

• Buy or build? "Buy the common infrastructure. Build the workflows and business logic that differentiate you."
• Most overrated AI trend? "Using five agents to do what one straightforward workflow could handle."
• Advice to yourself a year ago? "Spend less time perfecting the demo and more time testing what happens when things go wrong."

Closing question: "What's the first thing you'd check before greenlighting an AI project in 2026?"

"What business outcome are we changing, who owns it, and do we need AI to achieve it?" Shobhit Khandelwal

"Whether we're solving a decision problem or just introducing new technology. If I can't clearly explain which decision improves and who benefits, and the ROI, I probably don't have a business case yet." Rina Taddei

Rina added that every AI conversation eventually comes back to data quality and trust, so she also wants confidence the underlying data is trusted and governed.

Demo: The Enterprise Agent Stack, Open, Governed, and Production Ready (Eze Lanza, Intel)

Eze's session picked up exactly where the panel left off: if the model isn't the hard part, what is? His answer was the infrastructure around the agent loop.

A prompt became a loop. Agentic AI turns a single prompt-and-response into a multi-step loop of planning, orchestrating, acting, and evaluating. That shift explodes token usage (Eze's slide put agentic workloads at roughly 1,000x the tokens of an initial chat interaction, versus about 10x for reasoning models) and changes what the infrastructure has to do.

Your framework gives you the agent. It does not give you production. LangGraph, CrewAI, and Flowise give you the loop, control flow, prompts, tools, and business logic. Production also demands an API gateway with auth and rate limits, inference routing across models, memory and state, tool and MCP registration, sandboxed code execution, observability on every step, and deployment and scaling. As his slide put it: "a dozen infrastructure problems, solved at once or not at all."

Agents spend most of their time on the CPU. Eze cited research co-authored by Georgia Tech and Intel, Towards Understanding, Analyzing, and Optimizing Agentic AI Execution: A CPU-Centric Perspective, which measured where agentic workloads actually spend their time. Average share of execution time on CPU, per the benchmarks on his slide:

• Web-based QA (LangChain web-augmented agent): 86% CPU, 14% GPU
• Augmented QA (Haystack RAG): 84% CPU, 16% GPU
• Chemistry research (ChemCrow): 79% CPU, 21% GPU
• Software engineering (SWE-Agent): 40% CPU, 61% GPU
• Math augmentation (Toolformer): 17% CPU, 84% GPU

The implication: tool calls, orchestration, and retrieval dominate many agent workloads, so the right CPU/GPU ratio depends on the workload, not on a default of "put it all on the biggest GPU."

Routing is the gateway to agentic AI. The live demo showed one agent backed by four models. The same request hit the gateway with no client or SDK change; a router classified intent and picked a target (local CPU, local GPU, cloud, or frontier model); simple steps stayed local on Xeon and only complex reasoning left the building; and every hop showed up in the trace with its own latency and token count. "Watch the routing decision, not the answer. The answer is never the interesting part."

He laid out a maturity path for model-aware routing: rule-based complexity routing to start, semantic (embedding-based) routing when prompt complexity stops predicting the right model, an adaptive self-tuning router, and finally agentic speculative routing, where a local model attempts each task first and the cloud steps in only if it stalls.

Build one this week. The stack Eze demoed is the open-source Intel Enterprise Agent Toolkit: Apache 2.0, seven pluggable provider blocks (gateway, routing, tools/MCP, sandboxed execution, memory, observability, deployment), runs on a single machine with Docker Compose, works with any OpenAI-compatible model, and lets you put LangGraph, CrewAI, or Flowise on top. Docs, blueprints, and samples are at swcatalog.intel.com. His closing ask to the room: "Open an issue and tell me what broke. I read them."

The common thread

Across an airline, a public-sector field engineering team, an AI platform startup, and a chip company, the night kept landing on the same conclusion: the model is rarely what fails. Projects die on ownership, cost guardrails, governance that shows up too late, workflows nobody redesigned, trust that was never earned, and infrastructure that was never built for a loop instead of a prompt. The teams that ship treat all of that as part of the design from day one.

Photos

Thank you

Thank you to our Silver Sponsors, ShyftLabs and Databricks, to OneEleven for hosting, to our panelists for bringing real stories instead of slide decks, and to everyone who showed up.

What's next

Monthly Social, October 2026 Our monthly community gathering, open to everyone building with AI in Toronto. When: 5:30 PM, October 8, 2026 → Register on Luma

Hands-on workshops Step-by-step tutorials for data engineering, cloud, and AI teams. → becloudready.com/workshops

Looking for your next role in data or AI? Join the TorontoAI Talent Exchange. Hiring? Partner with us.

---

TorontoAI runs monthly socials, panels, and demo nights across Toronto. See all events or join the community.