How Collective Intelligence Becomes Localized Intelligence in Your Organization

I think about collective intelligence as people combining their knowledge and capabilities with technology, helping them work across the limits of a single person or organization. I think of localized intelligence as what develops when we combine that shared knowledge with our own personal experience and circumstances. An approach that works elsewhere will likely need to be adapted to fit how we work, and as we put it into practice, we learn what applies to our circumstances and what needs to be adjusted.

What interests me is how these two things develop together. As we apply shared AI capabilities across more of society, I continue coming back to who gets to decide what those systems should be working toward. Improving an outcome for one person can mean something significantly different for another, even when they're looking for something similar.

When I then think about applying this across a business, it becomes more complex because we have to account for different priorities and how people’s responsibilities affect one another. People may agree across the board that they want greater efficiency, but a solution that saves one team time could leave another with more work. We have to understand how those responsibilities affect each other before deciding where AI can be most leveraged.

As the business changes, the systems need to be dynamic enough to flex with those changes. That's the value of an implementation partner who takes the time to understand the business's strategic initiatives, priorities, end-to-end operations, and works closely with the experts in each domain to successfully deploy and execute on these AI initiatives. Working through those decisions together helps keep what we're building connected to the goals the business is looking to achieve.

Shared capabilities and different priorities

I think about something like customer service here. A routine question may just need a quick answer. But a customer's first message won't always give the team enough information to understand the problem. Sometimes they need to collect follow-up inputs to define the scope of the request before they can recommend what to do. Understanding the process at this level helps us decide what an AI system can handle directly, when it needs more information and when it should escalate a request to a staff member. For a given system like this, it'll handle ~85% of a business’s requests by answering common questions, significantly reducing the team’s workload while escalating the remaining 15% that actually require a staff member’s attention.

If we measured success only by how quickly an inquiry gets closed, we could end up encouraging the system to finish the conversation before the customer has received useful help. I'd want to know whether it gathered enough information to respond properly, and whether it recognized when someone on the team needed to get involved. That would give us a much more effective evaluation method for the system.

Bringing that understanding into the system is part of how I see collective intelligence developing into localized intelligence.

Latent Knowledge

Something Salim Ismail brought up recently connected here, and this comes from his Organizational Singularity pilot with 10 companies. He described how automating workflows is exposing ambiguity in organizations that people had been handling themselves, forcing the companies to become much more explicit about what those processes or workflows are meant to accomplish.

That adds another dimension to localized intelligence. A workflow might say to assign the next available driver. But the dispatcher knows that a particular customer only accepts deliveries in the morning, so they plan around that without needing to be reminded. That detail may never have made it into the written process because the person doing the work already knows it. When we introduce AI, we need to uncover that latent knowledge so the system can account for it too. Working through those decisions can also reveal where people have been compensating for longstanding processes that haven’t been revisited or adapted in some time.

Ideally, we want a system to bring forward the decisions that need executive judgment, along with the evidence to make them. If AI can help gather the relevant information and make it easier to see where a decision is needed, someone can spend more of their attention applying the experience they bring to that responsibility. Within that, you still need to define which decisions the system can handle and which ones depend on the person.

Why I write about this & Our work at OTZ

Part of why I’m writing these articles is to share how our work with businesses is shaping the way I think about AI. As the landscape continues to develop, I also want to offer helpful information for people, businesses, and organizations navigating this transformative period, along with a clearer view of the implementation work and the value our team brings.

At OTZ, uncovering that latent knowledge is a large focus of ours when scoping out any given project. Our forward deployed engineers (FDEs) work alongside the people who know the business to understand why a process works the way it does, including the decisions that depend on senior experience. Working through those decisions can also reveal different understandings of what the process is supposed to achieve. We need to resolve those differences prior to taking the next step so we're clear on what we're asking AI to take responsibility for and where someone's judgment is still needed.

That understanding continues to develop once a system is in use. A decision that initially needed someone's judgment may become clear enough to automate, while a change in the business may require us to revisit something we'd previously automated. This is part of what interests me about the connection between the two levels of intelligence. The people doing the work continue to contribute to how the technology is applied, and what they learn from using it informs what we build next. Our role is to keep that exchange going and make sure the systems can adapt as the business develops.