What Enterprise Teams Should Do Next

Practical Lessons from Ai4 2026

In Part 1 of my Ai4 conference report, I wrote about what became increasingly apparent to me over the course of the conference: AI itself isn’t so much the story anymore. Across sessions on marketing, analytics, enterprise software, healthcare, and agentic systems, the conversation has shifted to everything organizations need to build around AI to make it truly useful.

That was my big-picture takeaway. But buried inside all those sessions was also a surprisingly consistent set of practical recommendations.

Speakers disagreed on many things. They were building different products, solving for different problems, and working in very different industries. Yet when they talked about what organizations should do next, the advice was often the same. The message wasn’t “buy more AI.” It was closer to: “Get your house in order, decide what problems are worth solving, and then give AI enough context, structure, and accountability to solve them.”

This was especially gratifying for me to hear because, at Action, we’ve been preaching all this for a while now, often humorously summarizing it with the phrase “You have to eat your vegetables.”

Here are the practical lessons I brought home from Ai4.

Start With the Problem, Not the Agent

One of the more entertaining metaphors of the conference came from Nemo Dighe of Delaware Life Marketing, who described the current AI market as suffering from “Frozen Yogurt Syndrome.”

Think about walking into a frozen yogurt shop. You start with a perfectly reasonable cup of yogurt. Then you encounter the toppings. Oreos. Gummy bears. Sprinkles. Brownies. Cookie dough. Hot fudge. Suddenly, you’re building a $14 monstrosity because everything looked so good individually.

Enterprise AI is remarkably similar. Models, copilots, agents, retrieval systems, vector databases, MCP servers, knowledge graphs, orchestration platforms, and dozens of other capabilities are all available. Organizations keep adding them without necessarily asking what sequence makes sense or what business problem they’re trying to solve.

Dighe’s recommendation was to reverse the process. Start with pain-point literacy: understand the problem deeply enough to describe it in business terms. Then determine which technology is appropriate. Only after that should organizations build the operating foundation required to support it. Her mantra was simple:

Sequence first, then scale.

That philosophy surfaced elsewhere, too. During a panel on AI-driven data storytelling and decision-making, speakers repeatedly emphasized working backward from clearly defined business goals. Don’t boil the ocean. Build something, use it, learn from it, maintain it, and expand only when the value justifies doing so. One panelist put an especially useful constraint on the process: ask about ROI before building the agent.

It’s tempting to start with the technology because that’s the exciting part. Ai4 offered plenty of reminders that the less exciting work usually determines whether the exciting technology succeeds (that’s the “eat your vegetables” stuff).

Fix the Knowledge Before Blaming the AI

If I had to pick one practical recommendation that surfaced most frequently across the conference, it would probably be this: Fix your information.

AI has a remarkable ability to expose organizational mess. If two departments use different definitions for the same metric, AI will find both. If a policy document expired three years ago but still lives in SharePoint, AI may retrieve it. If important business logic exists only in the head of an analyst who’s been with the company for 12 years, the model doesn’t know it. If five websites describe the same product differently, the system has to decide which version represents reality.

One marketing panel offered a particularly vivid example. Onney Crawly of Goodwill International told us that the company operates across roughly 150 organizations, with a sprawling collection of websites containing information that wasn’t always consistent. As AI-driven search became more important, that fragmentation stopped being merely a web governance problem. It became a discoverability and trust problem. The response involved crawling the sites, examining schema and backlinks, and working toward greater consistency across the organization’s public information.

Peter Sloterdyk of Gist approached the same issue from the public web. His advice to brands was to identify the queries they wanted to appear for, then inspect the documents AI systems were likely to retrieve. Was the right information available? Was it accurate? Did the company’s website, Reddit discussions, and other sources tell roughly the same story?

Inside the enterprise, the principle is the same. Before asking how to make the model smarter, ask what you’re giving it to be smart about.

Build the Company Brain

“Company brain” came up more than once at Ai4, and while the phrase risks becoming another AI buzzword, the underlying idea is important. Organizations contain enormous amounts of knowledge that don’t live in databases. They live in conversations, decisions, Slack threads, customer calls, analyst notebooks, sales experience, business definitions, and the heads of employees who have learned how things actually work.

AI creates an opportunity to make more of that knowledge reusable.

In one marketing session, Kathleen Booth of sequel.io described building an internal system called Cerebro. The team began by cataloging its sources of organizational knowledge: CRM data, product usage, customer support, sales conversations, customer success information, internal HR documents, and more. Employees could then query that combined knowledge through a Slack interface. The system could answer questions about how customers described products, competitive positioning, and other topics that previously required people to hunt across multiple systems.

Suku Krishnaraj Chettiar from PromptQL pushed the concept even further. Their argument was that AI initiatives repeatedly start from zero because organizations fail to capture the shared context their teams already possess. If an analyst teaches an AI system an important business definition or rule, why should the next analyst have to teach it again? Their model treats organizational knowledge as something that can be taught once and reused broadly, while continuing to record changes in definitions, goals, and decisions over time.

The technology behind these systems will change. The principle probably won’t. Institutional knowledge has always been valuable. AI simply makes the cost of failing to capture it much more visible.

Give Agents Owners, Budgets and Boundaries

One of the more provocative ideas came from Dataiku’s keynote: stop thinking about agents as software and start thinking about them more like labor. If an organization deploys an AI agent, somebody should own it. The agent should have a defined purpose. Its costs should be visible. Its performance should be measurable. And someone should be accountable for what it does.

Dataiku reduced that concept to four elements:

Agent | Owner | Cost | Target

Their argument was that this is essentially the bargain organizations have always made with labor. People don’t simply appear inside companies and start doing things. They have responsibilities, managers, budgets, expectations, and accountability. Agents need analogous structures.

This becomes particularly important as experimentation spreads. One CTO reportedly believed his organization had around 40 agents operating internally. When they actually investigated, they discovered more than 400. That’s a governance problem, but it’s also an observability problem. You can’t manage what you don’t know exists.

This was one of several moments at the conference where the emerging role of IT started to look different. In an agentic organization, IT may become less of a gatekeeper handing out permission slips and more of a platform provider establishing visibility, standards, security, and governance. The people closest to the work can build and use AI, but they do so inside an environment where ownership and accountability remain clear.

Build a Better Chassis

If Part 1 had one recurring technical theme, it was that enterprise AI isn’t primarily a model problem. It’s an architecture problem. Vivek Vaidya of Kana did a presentation on agentic marketing offered a useful framework for thinking about that architecture. He described five elements surrounding the model: context, tools, memory, policy, and proof. Together, these form the “chassis” of an enterprise agent.

The metaphor works because the model is increasingly becoming something like the engine. Engines matter, but putting a bigger engine into a badly designed car doesn’t produce a better vehicle. The surrounding system determines whether the power can actually be used. Context determines what the agent knows about the task. Tools determine what it can do. Memory determines what it retains. Policy determines what it’s allowed to do. Proof determines whether humans can understand and trust the result.

Each layer introduces its own failure modes, which means “enterprise grade” can’t simply mean choosing the most capable model available. As Vivek put it, enterprise-grade AI isn’t a bigger model. It’s a better chassis.

That also explains why so many seemingly unrelated topics kept surfacing at Ai4: semantic layers, retrieval systems, knowledge graphs, metadata, access controls, observability, governance, citations, and agent orchestration. They aren’t peripheral concerns anymore. They’re becoming the infrastructure that determines whether AI works reliably inside an organization.

Know What Your AI Knows

Trust was another recurring concern, but the discussion was refreshingly specific. Speakers weren’t simply asking whether people “trust AI,” they were asking what makes an answer trustworthy in the first place.

Sue Weng-Cross of Wiley presented a useful model in which knowledge sits beneath the model and deployment layers. Their argument was that errors introduced during retrieval are difficult to correct downstream. As AI systems become agentic, the problem becomes more serious because an error at one step can become an input to the next.

Their definition of knowledge quality included breadth and depth, but also trust signals such as citations, attribution, retractions, peer-review status, versioning, and corrections. In other words, knowing where an answer came from becomes part of knowing whether to trust it.

That same principle surfaced during the data storytelling panel. In industries such as insurance, users may be querying policy documents hundreds of pages long, some of which can expire or change. An AI system shouldn’t simply provide an answer. Users need lineage: which repository, which document, which page, which version?

This is a particularly important distinction as companies race toward agentic systems. A chatbot that produces a questionable answer is annoying. An agent that acts on a questionable answer can create an entirely different class of problem.

Sequence First, Then Scale

Looking back over my notes from the conference, what’s striking is how conventional some of this advice sounds. Understand the problem before choosing the solution. Get your information organized. Establish ownership. Build reliable infrastructure. Preserve institutional knowledge. Measure business outcomes. Put judgment where judgment matters. None of these principles began with AI. But, what AI has done is raise the stakes.

A messy definition in a dashboard creates a bad metric. Give that same definition to an autonomous system and it can become a bad decision repeated at machine speed. Undocumented institutional knowledge used to make organizations inefficient. Now it can determine whether an agent understands the business at all. Weak governance once created software sprawl. Agentic AI can turn it into hundreds of autonomous systems nobody realized were operating.

Maybe that’s why “sequence first, then scale” feels like such an appropriate summary of what I took away from Ai4. The organizations making real progress aren’t necessarily the ones deploying AI everywhere fastest. They’re the ones becoming more deliberate about what they’re building underneath it.

Part 1 ended with the observation that AI isn’t replacing the fundamentals of good organizations. It’s making those fundamentals impossible to ignore. I’d add one thing to that:

Get the fundamentals right, and AI accelerates what works. Get them wrong, and it accelerates what doesn’t.

Coming Next

We’ve looked at the big ideas emerging from Ai4 and the foundations organizations need to put them into practice. In Part 3, we’ll get closer to the technology itself. We’ll look at some of the most interesting AI systems demonstrated at the conference, from Pfizer’s knowledge-graph-powered CoCo and Google’s experiments with generative interfaces to enterprise agents that can retrieve data, reason across it, recommend next steps and take action.

Taken together, these examples offer an early glimpse at what happens when AI moves beyond answering questions and becomes an active participant in how organizations work.