Using LLMs for Small Team Data Analysis

💬 What happens when you connect a small LLM to an Iceberg catalog full of river flood data? You actually get solid spatial reasoning, expressed in SQL, all built in 130 lines of Python. I recently built a simple chat interface that connects to an Iceberg catalog holding current and historic river gauge data. It’s powered by two lightweight agents: One to explore spatial trends and another to dive deeper and follow up with detailed spatial queries. Instead of a single, overloaded prompt, this multi-agent setup splits the cognitive load: 🧠 One model thinks broadly, scanning for spatial patterns using ST_Intersects, ST_Distance, and temporal changes. 🔎 The other interprets those patterns and generates SQL to pull meaningful insights, even from complex geographies. Why does this matter? Spatial data is hard. Most models struggle to reason across both structure (SQL schemas) and space (geometry) in a single prompt. But if you break the problem into roles, it becomes tractable, even with smaller LLMs (in this case gpt-4.1-mini). Now with this set up: ✅ You can ask, “Where are rivers currently above flood stage?” ✅ The model writes valid spatial SQL using geospatial joins ✅ The model iterates for you, modeling the same way we think about spatial questions. With solid data (in this case a pipeline in Apache Airflow with a runner in Wherobots and Apache Sedona) which outputs into Apache Iceberg you can bring this to any SQL query engine and in turn any LLM via LangChain. This changes who gets to explore spatial data and ask spatial questions. 👉 If you want to try this kind of reasoning with your data! 🌎 I'm Matt and I talk about modern GIS, geospatial data engineering, and how spatial thinking is changing. 📬 Want more like this? Join 5k+ others learning from my newsletter → forrest.nyc

What if you didn’t have to write SQL to get insights from your data? Imagine being able to _ask_ your database questions in plain language—no technical barriers, no SQL skills needed. With Large Language Models (LLMs) and Retrieval-Augmented Generation (RAG), we're making that possible. Here’s a peek into how it works: ➤ Schema Understanding: We extract and cache the database structure, giving the model the “map” it needs to understand your data. ➤ Enhanced Questions: Your natural language questions are enriched with this schema, so the model knows exactly what you’re asking. ➤ Relevant Results: A ranking model picks the most relevant tables, ensuring the model focuses on the correct data. ➤ SQL-Free Answers: The LLM generates SQL in the background, so you get accurate results without touching a single line of code. This isn’t just about tech—it’s about empowering everyone to explore data freely, making insights accessible and driving smarter decisions across teams. Could conversational AI make data analysis more effortless for you and your team? Cheers! Deepak Bhardwaj

How to Build an AI Agent for Data Analysis: A Blueprint An "agent" is more than just a chatbot. It’s a system designed to understand a goal, create a plan, and use tools to actively accomplish that goal. You can build your own powerful agent for data analysis, transforming how users interact with their data. This blueprint outlines the core components required to turn simple questions into actionable insights. An agentic system is built on three foundational concepts: an LLM for reasoning, a set of tools for taking action, and a sophisticated memory for learning and context. 1. The LLM: Your Agent's Reasoning Core At the heart of any data analysis agent is its reasoning core: a Large Language Model (LLM) like OpenAI's GPT or Google's Gemini. To build this, create a central orchestrator service (e.g., a Chat Service). This service shouldn't just pass the user's question to the LLM. Instead, it should enrich the prompt with context from the agent's memory. The LLM's role is not merely to respond, but to create a step-by-step plan and generate the precise Python code needed to perform the analysis. 2. Tools: Give Your Agent Hands-on Capabilities An agent is only as good as the tools it can use. For a data analysis agent, the primary tool is the ability to execute code. After the LLM generates an analysis script, your orchestrator service must run it against the relevant dataset. This is the most critical agentic step: it moves the system from simply planning to actively doing. You can equip your agent with other tools, such as services for data loading, chart generation, or even calling external APIs, allowing it to handle a wide variety of analytical tasks. 3. Memory: Enable Context and Learning To elevate your agent from a one-shot tool to an intelligent partner, you need to implement memory. A robust approach is to use a graph database like Neo4j to manage two distinct types: ➜ Short-Term Memory: Implement a mechanism to track the current conversation history for each user session. This allows your agent to understand follow-up questions ("now show me that by region") and maintain context, just like a human analyst would. ➜ Long-Term Memory: This is where your agent can learn. Every time it successfully executes an analysis, store the user's query and the generated code as a "solution." By creating a vector embedding of the query, you can enable semantic search. When a new question comes in, the agent can first search its long-term memory for a similar problem it has already solved, allowing it to deliver accurate results faster and more efficiently over time. By integrating these three components, your application will function as a true AI agent. Your central orchestrator service will drive the powerful loop of Memory -> Reasoning -> Action, creating a system that doesn't just answer questions, but actively solves them.

Dropped into a new team. No docs. Critical database. And no one knew how it worked. As a fractional VP of Engineering, I inherited a massive legacy Postgres DB that was central to the business — but totally undocumented. The original devs? Gone. The schema? A tangled mess. The team? Asking urgent questions like: ➡️ Where’s customer data stored? ➡️ How does order tracking work? Here’s how I used an LLM to turn chaos into clarity — in just a few hours: 1️⃣ Dumped the schema Used pg_dump --schema-only to extract the structure. 2️⃣ Condensed it with ChatGPT Prompted it to create a lean, token-efficient version that still captured table names, key fields, and relationships. 3️⃣ Turned ChatGPT into a schema assistant Loaded the summary into a ChatGPT project so anyone could ask real questions and get helpful SQL (and answers) fast. ✅ No new tools ✅ No digging through code ✅ No waiting on docs that didn’t exist You can dig deeper into how I did it - including the prompts in the linked blog post (first comment) #llm #database #chatgpt