Work

There was no data warehouse. Operational and historical data lived in siloed systems, and as it aged out of each system’s retention period it was gone for good. Management metrics and long-term analysis were out of reach.

The harder problem was that the sources never held still. Input locations, processes, and table shapes changed constantly, and the definition of something as basic as when a warranty starts could shift from the install date to the ship date. A warehouse that captured data permanently but couldn’t bend with that churn would have been abandoned within months.

I built the first warehouse, solo, using Claude Code as a throughput multiplier. Every operational source was consolidated into a single source of truth, stored as parquet, queryable with SQL through AWS Athena, and visualized in Grafana.

Around it I put a working discipline of cleaning, verifying, monitoring, and maintaining: stakeholder interviews to confirm the right data came from the right source, nightly jobs that flag missing data and decide whether to filter, interpolate, or investigate it, and schema-drift detection that raises an alert whenever a column is added, removed, renamed, or retyped.

Then I closed the loop. Each morning an AI agent analyzes the detected table changes and opens a pull request containing the needed migrations, the Terraform updates, and a written rationale. I review it and deploy. I chose to keep a person in that last step on purpose, because an agent can’t know that a table called Locations actually holds customer names. That judgment is the part a human has to keep.

History stopped disappearing, and long-term questions became answerable. The warehouse keeps up with constant schema churn on a short daily review from one person, which is what makes it sustainable for a small team. The pull-request loop also leaves a documented trail of every change and why it was made.

Anyone who needed something from the data had to ask one of a few SQL-capable teammates. Requests took days, were often deprioritized, and were sometimes never answered. The people asking worked in operations, customer experience, and management, and their questions were reasonable. The bottleneck was the translation step.

An internal MCP data-access server over the warehouse, so staff could ask questions in plain English through an AI assistant. It translates the question into SQL, corrects its own errors, shows where the answer came from, and, for questions that aren’t about data, answers from internal documentation instead.

The piece that made it trustworthy was a concept dictionary: the business’s nouns, their definitions, and which tables they map to. Before it existed, the system would confuse a plant’s seed date with its germination date and confidently answer the wrong question when someone asked what a customer had planted recently. After it, the definitions lived in one place and the answers held up.

The server logs every question, and a periodic analysis looks for concepts to add or refine and opens pull requests against both the server and the warehouse. Those pull requests have been reviewed and merged into production.

Non-technical staff answer their own questions, and the analyst queue is gone. The concept dictionary became the shared vocabulary for what the data actually means, which turned out to matter as much as the query engine.

Sustainability reports for customers were put together manually, pulling from several tools and assembling the graphics each time. It was specialist work, and it consumed the specialist’s time.

An end-to-end pipeline. An AI assistant calls the MCP server, which queries the warehouse through Athena, hands the result to an image generator, and publishes the finished graphics to a download server. Reports take a defined set of parameters and ranges, so the same pipeline produces a scheduled report or a custom one.

Scheduled reports run fully automated across the customer base. Custom reports are self-serve for the customer experience team, from a single place, with no engineer involved.

A task only one person could do became something the customer-facing team owns. Reports go out on schedule without anyone remembering to make them, and custom requests get answered by the people who actually talk to the customer.