AMII Upper Bound AI Conference 2026
Upper Bound is easily one of the larger conferences I’ve attended. It lists 8,000 attendees and 250 speakers, encompassing several key sectors: education, health care, science, culture, policy and engineering, across the axes of academia, government, and industry. The potential for cross-pollination is high.
On the logistical side, it’s a well-run conference, given its size: things move along pretty quickly, including the initial registration, considering the number of attendees. How to get around is clear and the scheduling app is on par with other conference apps I’ve used. An interesting aspect of the conference is that while there are several separate rooms for smaller audiences, the main ballroom holds seven talks simultaneously, without there being an unpenetrable cacophony, through the use of headphones: you get a pair of headphones when you walk in, click a selector until the glowing panels on either headphone match the colour of the stage you’re paying attention to, and you’re ready to go. While there is sometimes a little confusion about whether it’s the green banner background or the yellow stage number that indicate the channel you need, or you can’t quite tell whether you should be using pink or purple, but all in all it works well.
As for the content: alongside BCNet Connect, I found the content in Upper Bound 2026 to be far less 🤩 and much more 🤔 than last year: there seemed to me to be less unbridled enthusiasm and more cautious pragmatism, which I appreciate. Issues of environmental impact–including a talk on building data centres with community buy-in (a rare vendor presentation in that I was interested and engaged)–along with cognitive offloading, online safety, and other potential downsides–were represented. My biases will be evident in the selections I made.
One other thing on the content and logistics: I found that generally throughout the four days of the conference there was always a session I was interested in attending, and only had a couple of slots where I had to choose between two topics of interest to me. That’s always lucky!
In the following sections I’ll briefly describe some of the sessions I attended and why they were interesting to me.
Do not quote anything here: these are from my hastily scribbled notes and some photographed slides, and I have a terrible memory. That is why I have provided whatever links I can. Regardless, these describe only what I took away from the talks and may not represent the content fully or accurately.
Interaction & Cognition in AI-Assisted Programming
- Speaker
- Majeed Kazemitabaar
- Synopsis
- https://www.upperbound.ai/schedule?date=2026-05-19&showSession=773093
This session kicked the conference off right for me because it discusses one of my major concerns about AI and the most immediately practical use case: the risks of off-loading your thinking to AI with particular respect to programming. I have had direct experience with developers relying too heavily on AI in their work, which can lead to poor outcomes and a heavier load on the rest of the team, whether that’s for more laborious reviews, fixing and refactoring sub-par work, or taking on more tasks. My general directive to my team is: use AI to help find an answer, but don’t rely on it to provide a solution.
I am not alone in my concerns about AI assistance in this type of work. The speaker’s PhD thesis was “Balancing Productivity and Cognitive Engagement in AI-Assisted Programming”, and the talk described a study that attempted to quantify the impact.
Three groups of first-year computer science students were given a number of coding tasks. One group was permitted to use AI, another was permitted to use web searches only, and the third group was permitted no external tools at all. The three groups were rated on success and time to completion, and the results were as you might expect: the AI group was faster than the search group which was faster than the no-tools group. All were successful. No real surprises there.
In a followup a week later, the three groups were again given a number of coding tasks, but none of the groups were permitted tools. Here is where the results are interesting: the AI group was succesful in solving the tasks without assistance, as were the search and control groups, and if I recall correctly retained some of their productivity advantage. So this was surprising.
In a followup analysis, the AI group’s results were examined and a large variance was found in both how members of the group used AI and how they fared in the followup. Here is where things start to make sense.
Consider an example problem (from a different talk, to be honest): determine whether a string is a palindrome.
Some users asked the AI, “Write me a program that determines whether a string is a palindrome.” They were broadly less successful in the followup tasks. Others, meanwhile, solved the general problem themselves, but requested assistance in syntax or specific subtasks: “How do I convert a string to a list?”, for example. The latter group did very well.
The difference in the two subgroups is, in my view, one of engagement. In the former group, there is very low engagement. The coder is barely there at all. The latter group, the coder is using AI but is actively engaged in solving the problem. In the former group, the coder asks the AI to solve the problem for them. In the latter, the coder works through the problem and asks the AI specific questions to help them solve it.
This matches my own experience going back to late elementary school: I noticed at some point at age 10 or 12 or so that where I sometimes had trouble recalling something that was taught in class, I would never forget the answer to a question I asked. The reason for that is engagement: my brain had no problem retaining that knowledge because it bridged connections already formed. In passive learning, the brain has to make what connections it can and sometimes the links are weak or few. And when people just copy and paste an answer from an AI bot into a solutions form, there is little or no engagement.
From LLMs to AI Agents: From Words to Action
This talk was about specializing LLMs for different tasks, with an overview of refining through supervised fine-tuning (SFT) and reinforcement learning (RL), followed by post-training and distillation into smaller yet effective purpose-built models.
My main takeaways from this session were that synthetic data can actually be a strength in training LLMs if the quality is there, and the concept of model merging. And a reference to this paper.
Practical Approaches to Building Responsible AI in Startups
- Speaker
- Andrea Yzeiri
- Synopsis
- https://www.upperbound.ai/schedule?date=2026-05-20&showSession=771056
I was interested in this talk as an overview of implementing AI tooling in a safe and responsible way for a small team. This was more about building models in a socially responsible way. It went over some of the issues I’ve read about in the past with AI vs. societal reality but also discussed some ways to avoid these issues as your team goes through building up a model.
- Build a use case: prediction policing in Baltimore.
- Plan of action: Use datasets from 911 calls, starting 70 years ago
- But wait: This immediately introduces bias because this data is already skewed
- So: Use data auditing, cleaning, validation and augmentation
- Feature engineering: Choose variables corresponding to any use case:
urgency, zip code, time record, proximity to risk areas
- But wait: Now we have feature bias
- So: Exclude sensitive features
- Model: Choose Bayesian network
- But wait: Model is overly reliant on patterns, amplifies
- So: Try different models–what’s used in the industry?
- Build & test model: Fine-tune aspects of the algorithms for the model.
- But wait: algorithm bias
- So: ensure the algorithm provides transparency and accountability.
- Deployment
- But wait: Operational bias–how the tool is used, when it’s applied, how the data and analysis provided are interpreted
- So: Monitor and evaluate.
The value to me here is, apart from my interest in societal issues around technology, awareness of these biases at the various stages of model development.
Protecting Canada’s Information Ecosystem: AI, Influence Operations, and Democratic Resilience
- Speakers
- Brian McQuinn, James Benoit, Matt Taylor
- Synopsis
- https://www.upperbound.ai/schedule?date=2026-05-20&showSession=770973
A fascinating talk on threats Canadian society faces through technological vectors and a decision-making system designed to find and track these threats. Threats include both covert (think Russian disinformation campaigns) and overt (think the Trump regime’s talk of the 51st state and support of Alberta separatism), as well as economic opportunists who have no skin in the game but create AI slop stoking division and outrage on YouTube for nothing other than clicks and lucre. These threaten social cohesion, trust in our institutions and democracy, stability, investor confidence, and (scariest yet) cognitive sovereignty–freedom in making decisions.
The CIPHER system was built from fundamental research at the Centre for Artificial Intelligence, Data and Conflict and uses AI to sift through social media and online communities for various patterns or artifacts, such as increasing viral far-right content or pictures of weapons and weapon systems which may be shared by militant groups or other potential adversaries. The talk dscussed how the system identifies and classifies potential threats: for example, a racist jackass spouting off some conspiracy theory to 10 followers is not a big deal, but if one of those picks up the idea and carries it to 100,000 followers, that’s a problem. Or if the niche idea starts showing up in YouTube videos–that’s a problem. Other variables include velocity and source credibility.
We didn’t get a demo or screenshots but the system identifies potentials through traffic light classifiers: red for rapid spread, coordinated threats from known adversaries; yellow for emerging narratives with some amplification where the adversary might be on a watchlist; green for normal discourse or barely potential threats with low coordination, low amplification, and/or low operational relevance. Thresholds for these classifiers can be configured for where the activity is detected, what platforms are affected, who is involved, and so on.
It is important to note that this system retains expert analysts and the output of the system is geared to support their judgements. The whole system is built off research, and I didn’t catch or ask how the system is refined, but it analyzes from multiple expert perspectives and presumably an analyst has some path to identify a false red.
When asked how, once a threat is identified, how they make sure the necessary people listen, they left us with this thought: Try to be the first voice in the room, not necessarily the loudest voice. This gives you the opportunity to get a few points in.
Vibe-Ops: The Missing Half of Software DevOps in the Age of AI
- Speakers
- Johnny Chen, Tony Tam, HAZL Cloud
- Synopsis
- https://www.upperbound.ai/schedule?date=2026-05-20&showSession=771073
The basic idea: You can accelerate the development part of DevOps with AI–vibe coding–but the operations and maintenance is still a manual slog, even with IaC such as Terraform. According to the speakers, development is “driven by CoPilots, code-generation, and rapid AI assistance” while operations is “highly manual, complex, and lagging in workflow revolution”. DevOps is more accessible to people who can do the dev part through vibe coding and other AI assistance, but they can’t manage the Ops part. (I would argue that if you can’t do the operations part, you shouldn’t do the operations part.)
One of the challenges is that there is too much tooling: containers, registries, k8s, configs, networking, monitoring. It’s a lot to handle if your cel goes off at 3 a.m. and there’s an issue.
Their product uses Generative AI to understand what you want and then from a model trained on specs, best practices, and so on, determine deployments and, when necessary, remediation, for you. Instead of expressing syntax and commands, you only need to express your intent: “Deploy the app and scale to handle 50,000 requests per second”, for example. Their examples show managing deployments through messaging on your phone.
They made valid points and it’s definitely an interesting idea. I’m not sure what it would take for me to trust such a mechanism with production services, but having it develop and execute a plan for development or test systems would be reasonable, and I could then reuse that plan for production after inspection, testing–whatever vetting would make me comfortable.
Why Agile Intelligence is the Future of AI in the Workforce
The talk featured a brief survey where the audience reported on their use of AI. Within a few hours a report arrived in our inboxes summarizing the results, which confirmed the talk’s message: people need to be able to do real work, not to keep hearing about strategic ambitions. The report itself was an artifact of this direction: the terms “AI-assisted analysis” and “Automated insight report” appear at the bottom of every page, and it appears representative of the audience’s experiences, so far as I can tell–I have absolutely no way of knowing if it’s accurate, but the sentiment it professes to capture align with the interests of the audience that would choose this particular talk, I would think.
In essence, my main takeaway from this talk was mindfulness. Don’t expect effective AI to be easy, and off-the-shelf models are neat but limited; to really succeed you’ll need to incorporate your knowledge base and operational contexts.
From Chaos to Clarity: The Adoption Framework for AI-Ready Teams
This talk’s foundational theme was “forget the hype, here’s how AI can actually be useful”. It’s been hard to miss all the stories of CEOs telling anybody who’d listen that they fire anyone who isn’t using AI or that AI has increased productivity. Meanwhile, stories are surfacing of those in the trenches trying to figure out how. In one report, 81% of respondents reported using AI, and 78% reported seeing no benefit.
So in their journey, they spent some time being curious, playing and experimenting, from the bottom up. Workers had the freedom to try things out and share, with some guardrails like software oversight and safety training. This helped remove the fear and anxiety and build familiarity. On the down side, they spent a long time being aimless and there was little quantifiable benefit. But the culture won: they learned to make it easy to learn and easy to share what they’d learned. They confirmed that beginning from the ground up rather than a top-down approach was key, but also to build a plan quickly, and that some of this is really hard. But some of it is also really easy, so focus on the quick wins.
This talk laid out a pretty clear road map for adoption (this is pretty much transcribed from the slides I photographed):
- Set the stage: create a culture of experimentation. This means permission.
- Define the box: create an ethical framework, governance and IT boundaries
- Set the vision: where will AI take the organisation, specifically?
- Build the plan to take you from where you are to where you want to go.
There was also a slide with this important message: The goal isn’t to replace the work you love, it’s to stop spending time on the work that gets in the way. That’s a comforting message. Let’s hope leaders hear it.
Data Centres and the Communities Around Them
I no longer work in a data centre but I’m still infrastructure-adjacent, and I’m interested in some of the technical aspects and, increasingly, in the social and environmental responsibility aspects of these hyper-wired warehouses.
There has been a lot of pushback in communities in the US against data centres for being built next to less affluent residential areas, creating a lot of constant noise, consuming and polluting water resources, and disrupting the electricity grid, to little benefit of those communities. This talk was about how to not do that, by a company that doesn’t seem to need to.
This could have been a sales pitch, but it didn’t feel like it: although the speaker talked about how their company went about planning data centres, it was about the approach, as if she was teaching a seminar on how to build a data centre responsibly.
Key points:
- Engage with the community and utilities early, before breaking ground. The community is a partner to engage, not an obstacle to overcome.
- Exceed municipal noise requirements. Go above and beyond with sound baffling.
- Prioritize industrial zones to preserve farm land (it was a given these things aren’t being built in residential areas)
- Use closed-loop systems: your data centre shouldn’t drink all the water, and it shouldn’t pee in it, either.
- Use free cooling. This is Canada, after all, and our climate is an advantage here.
Canadian data centres also promote employment. Apart from the direct employment in planning, construction, and operations, the data centres are value multipliers by virtue of all the work that’s done with them.
Overall impressions
As mentioned previously, this year’s conference was way more aligned with where I am and where I see myself going with AI. Last year was lots of early adopters at every level with all the excitement whether they were computer scientists talking about advancements in reinforcement learning or data scientists talking about building specialist LLMs or startups talking about the amazing things they were going to unlock with AI. Among the most accessible talks for me was industrial engineers talking about how AI was used in monitoring and operation of a municipal water purification plant. I’m not dismissing any of these talks or topics but I often left talks feeling way behind or very skeptical.
This year more of the talks met me where I am, and it’s nice to know I’m not alone in trying to figure out how I can actually benefit my team and organization with AI, without further offloading our intellectual property to massive corporate entities in other countries. And along with that acknowledgement and validation there was some good information on how to get there.
Don’t get me wrong, last year was a fun ride–but this year was more of a journey.
(Yeah, yeah, that was a bit much.)