Kraken: Building an AI Platform Before AI Was Cool

I built an AI system in 2019. Nobody called it AI back then. We called them "bots." The technology was different, the terminology was different, but the core idea was the same: give a machine the ability to reason, act, and learn from its environment.

The system was called Kraken. It was an Intelligent Communication and Operations Platform built for network engineers at one of the largest telecom groups in the Middle East. And it taught me more about architecture, AI, Cloud - specifically Azure, and organizational impact than anything I've done since.

The problem we were solving

Network operations teams were drowning in repetitive work. Every device issue, every configuration change, every status report followed the same pattern: check the system, cross-reference with documentation, make a decision, take action, report back. The individual tasks weren't hard. The volume was. The operations center ran 24/7. Engineers spent most of their time on tasks that followed predictable patterns but required judgment at each step. A device goes offline: check the logs, verify the last configuration, determine if it's a hardware failure or a software issue, escalate or resolve. Repeat, hundreds of times a day. The existing tools were dashboards and ticketing systems. They showed you what was happening but didn't help you figure out why or what to do about it. Engineers were the glue holding everything together, and they were burning out.

What Kraken actually was

Kraken was a system of intelligent agents, what we'd now call AI agents, designed to work alongside the operations team. Each agent handled a specific domain: device monitoring, configuration management, incident response, reporting. But the real innovation was how they worked together. The platform was a clustered solution hosted on Azure, built with Docker and Docker Swarm (now-deprecated) for orchestration. We used cloud-native components throughout: Azure Web Apps for the frontend, Function Apps for serverless processing, and a range of other Azure services for storage, messaging, and monitoring. It was one of my first deep dives into cloud-native architecture, and it shaped how I think about distributed systems. The platform had four communication modes:

• Human-to-human: Engineers could chat with each other through Kraken, sharing context about ongoing issues without switching between tools.
• Human-to-machine: Engineers could query the system using natural language. Instead of writing complex commands or navigating dashboards, they'd ask a question and get an answer.
• Machine-to-human: Kraken proactively sent alerts, reports, and recommendations to the right people at the right time. Not just "something is wrong," but "something is wrong because of this, and here's what we should do about it."
• Machine-to-machine: The agents talked to each other. When one agent detected an issue, it could automatically trigger another agent to investigate related systems, cross-reference data, and compile a comprehensive analysis. Under the hood, the NLP layer ran on LUIS, Azure's legacy Cognitive Service for language understanding. It was one of the few options available at the time for building conversational AI, and it gave Kraken the ability to understand natural language queries from engineers. The chat interface felt a lot like what ChatGPT would later popularize, but built specifically for network engineers with domain-specific knowledge and actions.

The thirty-second moment

I remember one afternoon, watching a network engineer use Kraken to diagnose a device issue. The engineer typed a question about a specific device. Kraken queried the monitoring system, checked the device's last configuration, reviewed recent changes, and provided a diagnosis with a recommended fix. The engineer confirmed the fix, Kraken executed it, and the device was back online. Less than a minute. A task that would have normally taken a twenty-minute call to the support engineer, plus time waiting for a response, plus time for the engineer to manually investigate. That moment stuck with me. Not because the technology was impressive, though it was for its time. It stuck with me because I saw the gap between building something that works and building something that genuinely changes how an organization operates. The engineers didn't just use Kraken. They relied on it. It changed their daily workflow from reactive firefighting to proactive management.

What it taught me about architecture

Building Kraken taught me several things that still shape how I think about systems:

• Agents need context, not just commands. The power of Kraken wasn't in executing individual actions. It was in understanding the context of a situation and choosing the right combination of actions. That's the difference between automation and intelligence.
• Communication patterns matter. The four communication modes weren't a feature list. They were an architectural decision. Each mode served a different use case, and the system needed to support all of them seamlessly.
• Organizational adoption is the hardest part. The technology was the easy part. Getting engineers to trust a system that made decisions on their behalf? That took time, transparency, and a lot of demonstration of value. We had to prove that Kraken's recommendations were reliable before people would act on them without double-checking.
• Integration beats isolation. Kraken worked because it connected to the systems engineers already used. It didn't replace their tools. It enhanced them. That's a lesson I carry into every architecture decision: meet people where they are.

The legacy

Kraken was built years before "AI agent" became a buzzword. The technology has evolved dramatically since then, but the principles remain the same. Give machines the ability to reason about context, act on that reasoning, and communicate their findings in ways humans can understand and trust. Building Kraken on Azure gave me a deep foundation in cloud-native architecture that I've carried throughout my career. It's one of the reasons I've continued to specialize in Azure, earning 8 certifications along the way. The platform taught me that cloud architecture isn't just about services and scalability. It's about choosing the right tools for the problem and integrating them into something that genuinely serves the people who use it. I'm proud of what we built. Not because it was revolutionary for its time, but because it genuinely helped people do their jobs better. That's what technology should do. If you're building AI systems today, whether they're agents, copilots, or something else entirely, the lesson from Kraken is simple: focus on the problem, not the technology. The technology is a means. The problem is the end.

If you're building AI systems and want to think through the architecture, governance, or implementation strategy, I'd love to connect. Reach out at zulmehdi.com or find me on LinkedIn.