I recently attended the Chief AI Officer Summit at the Westin Boston Seaport, hosted by the AI Accelerator Institute.
The room was full of AI leaders from banking, insurance, pharmaceuticals, healthcare, and technology companies. I wanted to hear how organizations at that scale are putting AI into production, what they’re building, and what problems they’re running into.
There was a good mix of technical architecture, governance, organizational strategy, and vendor presentations. Some talks were more useful than others.
Here’s what I found interesting.
Microsoft’s approach to agent governance
Sarah Bird, Chief Product Officer for Responsible AI at Microsoft, opened the day with my favorite talk.
Her main point was that you can’t rely on an AI model to govern itself. She shared research from Microsoft showing that models can find ways to cheat and even reason about how to hide that behavior. If you want reliable governance, the controls need to exist outside the model.
She introduced two open source specifications from Microsoft:
- Agent Hooks provides a standard way to connect governance detectors to different agent runtimes.
- Agent Control Specification defines how the agent runtime communicates with a policy engine, allowing checks at each stage: user input, model calls, tool calls, tool results, and final output.
The demo used a banking chatbot. A deterministic rule automatically waived late fees under $35 before a tool call was executed. A separate LLM-based financial hardship detector watched for signs that a customer needed help and escalated those conversations to a person.
I liked the separation of responsibilities. Use rules for things you can define precisely, models for situations that require interpretation, and people for decisions that need human judgment.
I was also glad to see Microsoft publishing these as open specifications rather than keeping the approach inside one of its products.
Microsoft has also published run-assert-eval, which brings risk discovery, evaluation, policy enforcement, and retesting into a single workflow. I’m interested in exploring how these tools could fit into the governance and review processes we’re building at Kanopi.
Red Hat’s model routing architecture
Christopher Nuland, Chief AI Architect at Red Hat, delivered the most technical talk of the day, which I thoroughly enjoyed.
When people discuss model routing, they usually focus on cost. Send simple requests to a smaller, cheaper model and reserve the expensive frontier models for harder problems.
Christopher’s reference architecture adds another consideration: how sensitive is the information?
Every request is classified across two dimensions: four levels of complexity and five levels of sensitivity. A small classifier called llm-d-sc runs on a CPU and makes that determination in milliseconds.
The gateway then decides where the request should go.
Regulated data stays inside the organization’s infrastructure and goes to a locally hosted model. Requests that can use external SaaS models first pass through redaction, replacing names, keys, and other sensitive values with placeholders. Those values are restored when the response comes back.
NeMo Guardrails provides another layer of checks, and outbound network traffic is blocked by default except for approved destinations.
What interested me was how the pieces fit together. The classifier doesn’t make the final security decision. It provides information to a gateway that enforces the organization’s policies.
For organizations working with sensitive client data, this approach could make it possible to use a mix of local and hosted models without treating every request the same way.
The llm-d-sc repository is still pre-1.0, and its documentation distinguishes the currently implemented classifiers from the broader architecture. Christopher’s reference architecture shows how the pieces could fit together; it doesn’t mean every component is production-ready today.
I’m planning to spend more time looking at Red Hat’s routing stack.
Blitzy and the problem with legacy code
Ben Bergerson and Brendan Schoch from Blitzy gave two talks about AI working with large codebases and legacy modernization.
Ben described a problem that anyone working on a large application will recognize. A developer might be able to keep a few thousand lines of code in their head. A coding agent might effectively work with twenty thousand. But an enterprise application can contain twenty million lines or more.
You can’t understand a system that size by feeding an agent one file at a time and hoping it figures everything out.
Blitzy’s approach is to map the system into a knowledge graph before agents start making changes. The graph captures relationships and dependencies across the codebase so agents have a better understanding of what they’re working on.
Brendan made a related point about modernization: the hardest part usually isn’t converting one programming language to another. It’s figuring out what the existing system actually does.
He offered three takeaways:
- AI modernization is largely a problem of defining and coordinating the work for agents. Generating code is the easy part.
- Validation determines whether the modernization succeeds. The new system needs to produce the same results as the old one.
- AI handles the volume. People make the decisions.
That last point resonated with me. I’ve worked on enough platform migrations to know that writing the new code is only part of the job. Understanding the existing behavior, deciding what should change, and proving that nothing important broke are where much of the real work happens.
PromptQL’s multiplayer AI
Tanmai Gopal, co-founder and CEO of PromptQL, gave an energetic talk about what makes an organization’s AI valuable when everyone has access to the same models.
One of his slides made the argument that AI intelligence is becoming a commodity purchased by the token. Your competitors can buy access to the same models you use. What they can’t easily buy is the accumulated knowledge of how your organization operates.
He described an approach called multiplayer AI, where multiple people collaborate with the same agent rather than each person working in an isolated conversation.
His example went something like this:
A person asks an agent to complete a task, but the agent gets something wrong or lacks the necessary context. Another person joins the conversation, supplies the missing knowledge, and helps complete the work.
The agent then proposes an update to its shared context, with a reference to the work and the person who provided the correction.
Over time, that shared knowledge improves the agent’s ability to handle similar tasks. He calls this the context flywheel.
A few of his principles stood out:
- Share the agent or prompt, not just the output.
- Shared knowledge should have a human source and owner, rather than relying on AI-generated content alone.
- People increasingly become responsible for teaching, guiding, and improving the AI systems doing the work.
I found this particularly interesting because so much of the conversation about AI adoption focuses on individual productivity. This approach treats AI as something teams improve together.
It also raises some interesting questions about documentation, ownership, and how organizations preserve knowledge when people change roles or leave.
A few other talks worth mentioning
Several other sessions offered useful perspectives.
Shani Fargun of StackAI and Dave Rossi of Cause + Effect Strategy presented findings from a review of 631 AI use cases across 13 industries.
The strongest results came from text-based work such as classification, extraction, and drafting.
Their common failure patterns were familiar: projects without success metrics, choosing the wrong tools, generating summaries nobody acts on, assuming the underlying data is clean, rebuilding capabilities that already exist, and allowing the scope to grow beyond the original problem.
The successful patterns were more practical. Extract information and have people review exceptions. Reconcile data across sources. Route work to specialized agents. Draft using trusted knowledge. Check compliance against defined criteria. Write results back to the systems where people already work.
None of that is especially glamorous, but it’s the kind of work that produces something useful.
Christie Mealo of Medical Knowledge Group discussed the difference between strategy and operational effectiveness. AI can make everyone more productive, but if every organization adopts the same tools and gets the same improvements, that doesn’t create much of a competitive advantage.
She identified five areas where organizations can differentiate themselves: data, distribution, integration, experience, and brand.
Shensi Ding of Merge offered one of my favorite observations of the day: shadow AI is user research.
When employees work around approved tools to use AI, they’re showing you where their existing workflows aren’t meeting their needs. That doesn’t mean you should ignore the risks, but it does mean you should pay attention to what people are trying to accomplish.
And during the Salesforce panel, Derya Isler made a point that came up throughout the conference: data is the moat, not the model.
If your organization’s data is a mess, adding AI doesn’t fix the underlying problem. It just gives you new ways to use that messy data.
After the summit
I went to Boston hoping to hear how other engineering and AI leaders are handling the same questions I’ve been working through: how to govern agents, how to protect client data, how to make AI useful across a team, and how to know whether the work is actually correct.
I came away with a few approaches I want to investigate further.
Microsoft’s Agent Hooks and Agent Control Specification are particularly interesting as we continue building governance and review into our own AI development workflows. Red Hat’s routing architecture also has me thinking about how we could use different models depending on the work and the sensitivity of the data involved.
I also appreciated hearing from people working on these problems at a much larger scale. The technical details vary, but many of the questions are the same ones we’re asking at Kanopi.
I’ve got some reading and experimenting to do.