What Uber’s Slackbot Taught Me About Building Smart AI Assistants

Forget dashboards. The fastest path to insight is an agent that speaks your data’s language.

Most finance teams don’t lack data.

They lack fast, trusted access to the right data.

And no, BI dashboards aren’t the fix.
They still rely on manual digging, tool switching, or someone from data engineering.

Uber’s answer?
They built an AI agent that speaks the finance team’s language, literally.

---

As developers increasingly turn to CLI coding agents like Claude Code for rapid development, a critical gap emerges: who reviews the AI-generated code?

CodeRabbit CLI fills this void by delivering senior-level code reviews directly in your terminal, creating a seamless workflow where code generation flows directly into automated validation. Review uncommitted changes, catch AI hallucinations, and get one-click fixes - all without leaving your command line.

It's the quality gate that makes autonomous coding truly possible, ensuring every line of AI-generated code meets production standards before it ships.

---

Here’s the typical flow inside a medium/large company:

• Data lives in multiple sources (Presto, Oracle EPM, Excel, Google Sheets…)

• Naming conventions vary wildly (e.g. “US&C”, “GB”, “Q4 FY23”)

• The Analysts either:

  • Know SQL (and spend their time writing/debugging queries)

  • Or submit requests to data teams and wait 3 days (if you are lucky)

It’s slow, frustrating, and error-prone.

And when data access becomes the bottleneck, everything downstream suffers.

• Decisions are delayed.

• Errors creep in from manual lookups.

• Analysts burn time fetching numbers instead of interpreting them.

• BI tools become static graveyards.

This is not just inefficiency; it’s an opportunity lost. And Uber knew it couldn’t afford that.

Uber’s Answer: Finch

Instead of adding more dashboards, Uber built Finch, an AI agent inside Slack.

You ask in plain English:
“What was GB value in US&C in Q4 2024?”

Finch understands finance lingo (“GB” = Gross Bookings, “US&C” = region). It identifies the right data source, generates SQL, runs it, and returns the result in Slack. Large datasets export directly to Sheets.

No dashboards. No context switching. No waiting in line.

General Architecture

Finch isn’t a chatbot with shortcuts. It’s a system of specialized agents, data layers, and safeguards.

• A semantic layer maps user-friendly terms to schema fields.

• Curated marts provide optimized, reliable datasets.

• RBAC checks enforce strict access control.

• A multi-agent system separates intent detection, SQL generation, and validation.

• Results appear where users already work: Slack or Sheets.

How the Finch Data Agent Flow Works

It’s one thing to say “an AI agent runs queries for you.”
It’s another to see how the moving parts actually work together.

Finch isn’t a black box; it’s a coordinated system of agents, metadata lookups, and real-time feedback.

Every query travels through a well-defined pipeline: from Slack input → to intent detection → to SQL generation → to validated results delivered back to the analyst.

Understanding Finch’s power is easier when you see the flow.

1. User query input
   A finance analyst asks a question in Slack, e.g.
   “What was GBs in US&C last quarter?”

2. Agent orchestration
   The Supervisor Agent receives the query and decides which specialized sub-agent should handle it (e.g., SQL Writer Agent).

3. Metadata retrieval
   The sub-agent queries an OpenSearch index to fetch relevant metadata:

   • Synonyms and aliases for table/column names

   • Valid values for filters (e.g. “US&C” → region_name)

   This mapping step is critical: it lets Finch bridge messy human shorthand with rigid schemas.

4. SQL query construction and execution
   The SQL Writer Agent uses the retrieved metadata to dynamically build a precise SQL query and execute it against the right data mart.

5. Guardrails
   Validates security permissions before executing the query.

6. Result delivery
   The final result is returned directly in Slack, complete with:

   • Natural language explanation of the SQL mapping

   • Generated SQL (with comments)

   • A Google Sheets link with full results

The Trade-Offs

Of course, an AI agent isn’t magic. Uber had to navigate real risks:

• Schema drift: keeping metadata aligned as tables change.

• Trust: analysts wanting to see how answers were computed.

• Backend load: too many heavy queries hammering systems.

• Hallucinations: models inventing columns that don’t exist.

The mitigations included caching common queries, regression testing generated SQL, exporting large results outside Slack, and adding human oversight for executive-level data.

The design isn’t just about speed. It’s about trust, security, and usability.

Takeaways: How to Build Your Own Finch

If you want to build something like this for your org:

• Start with one team and a few high-leverage metrics (finance is a great use case)

• Build a semantic metadata layer (OpenSearch, Postgres, whatever) to store aliases

• Use curated marts to simplify routing and avoid complex joins

• Separate responsibilities across multiple agents (intent → SQL → validation)

• Focus on observability: log every query, allow feedback, measure success

• Don’t ship without RBAC and audit logging; data privacy is non-negotiable

Final Thought

Most dashboards are slow, static snapshots.
They were built for looking, not doing.

Finch points to the better path:

Ask the question.
Get the truth.
Make the move.

If analysts are still stuck writing SQL or digging through dashboards, it’s wasted potential. I think dashboards had their moment, but they’ve become a bottleneck.

The future isn’t more dashboards. It’s agents that deliver answers when you need them.

“Dashboards show you data. Agents move you forward.”

Until next time,
— Raul

---

Reference

https://www.uber.com/blog/unlocking-financial-insights-with-finch/

---

System Design Classroom is a reader-supported publication. To receive new posts and support my work, consider becoming a paid subscriber.