Birdy AI — a conversational operating system before LLMs

Business intelligence wasn't difficult because the data didn't exist. It was difficult because the information lived everywhere.

Employees constantly jumped between BI dashboards, SQL queries, maps, fleet management systems, operations consoles, support tools, internal APIs, and cloud services. Finding an answer often required knowing which system contained the information, who had access, how to query it, and how to interpret the results.

Our goal wasn't simply to build another dashboard. It was to democratize access to information by allowing anyone to ask questions in natural language and receive immediate answers.

As Birdy evolved during the hackathon, we realized we weren't building a BI assistant. We were building a conversational operating system for Bird.

Different users needed different capabilities. Executives wanted global business metrics. Fleet Managers wanted fleet health and revenue. Operations teams needed vehicle information. Support teams wanted customer context. Repair technicians needed maintenance history. Supply Chain wanted inventory information.

Rather than building separate interfaces for each department, Birdy unified everything behind a single conversational experience.

Looking back today, Birdy's architecture feels surprisingly modern. If I rebuilt it today, I would likely replace Wit.ai with GPT-5 and use MCP for tool integration. Almost everything else would remain remarkably similar.

The architecture separated language understanding from business execution. Birdy wasn't responsible for answering questions itself. It was responsible for understanding what the user wanted and routing the request to the appropriate system.

One of the most important design decisions was building Birdy around Skills rather than hardcoded commands.

Each capability was represented as a reusable skill describing intent, parameters, entities, permissions, and execution logic.

Today we'd probably call these tools, functions, or MCP servers. Back then we simply called them Skills.

Perhaps my favorite part of the project was that Birdy could continuously evolve without requiring engineering work.

When users asked questions that Birdy couldn't answer, those requests were collected for training. An administrator could then create a new intent, define parameters, add training utterances, associate the intent with a business query, and publish the new skill.

No application deployment. No code changes. No engineering release. A completely new capability could become available within minutes. The platform became smarter simply by observing what employees were asking.

Birdy integrated with Metabase to execute parameterized business intelligence queries. Rather than embedding SQL inside the application, each business question was mapped to a configurable query.

Questions like "How many scooters were deployed today?", "Which habitats have the most configurations?", or "Show me the top markets this week" could all be configured without modifying application code.

Administrators simply associated conversational intents with Metabase questions and parameter mappings.

Birdy wasn't limited to plain text. Responses could include formatted tables, summary statistics, charts, generated maps, operational details, images, and Slack Block Kit layouts.

If a question involved geography, Birdy automatically generated static maps with markers using Mapbox.

The goal wasn't simply to answer questions. It was to present information in the most useful form for the user.

Although Slack was the primary interface for the hackathon, Birdy was intentionally designed as a platform rather than a Slack bot.

Our architecture already anticipated additional interfaces including Terminal, Mobile Applications, SMS, Alexa, Google Assistant, and Siri.

All of those channels communicated with the same orchestration layer and reused the same skills and integrations.

Watching our original hackathon presentation today is surreal. We built Birdy remotely during COVID in just three days.

At the time, we described it as an Artificial Intelligence assistant powered by Natural Language Processing. Today, looking through the lens of modern AI, it's remarkable how many concepts already existed: conversational interfaces, skills, intent routing, tool orchestration, business intelligence integration, operational actions, permission-aware execution, configurable workflows, and continuous learning.

The language model was the only missing piece. Everything else already looked remarkably similar to the AI agent architectures that have become mainstream several years later.