Most construction teams don’t really have a data problem, at least not in the way we usually think about it. They already have dashboards everywhere. Finance has reports, project managers have schedule views, field teams have inspection logs. Everyone can see what’s going on. But the moment something looks off, that’s where things slow down. A project starts going over budget and suddenly the question is not what happened, but why. And that answer almost never sits in one place. You check finance data, then schedules, then maybe dig into inspection reports, and then you end up asking someone on site. It’s not broken, it just takes time, and it depends a lot on who is asking the question.
That was the gap I wanted to explore in this demo. Not another dashboard, not another chatbot, but something that could actually follow the trail. I picked construction because it makes this problem very obvious. You’ve got ERP data like cost and invoices, you’ve got change orders and schedules, and then you’ve got field level signals like inspection reports and site notes. Each one tells part of the story, but none of them are enough on their own. When you put them together, that’s when things start to make sense.
Instead of building one large agent, I split the system into smaller pieces. A finance agent that understands budgets, WIP, AP and AR. A project controls agent that looks at schedules and delays. A field operations agent that reads inspection reports and site issues. Then a couple of knowledge assistants to handle document heavy context. And on top of all of that, a supervisor agent that decides how to combine everything. That last piece ended up being the most important, because real questions are never clean. Nobody actually asks for a metric. They ask why something is going wrong.
One example from the demo stood out to me. A project had rising costs. The finance agent picked that up quickly. But on its own, that doesn’t help much. When the supervisor pulled in the other agents, things started to connect. Project controls showed recent delays. Field operations showed repeated inspection defects. The documents added a bit more context. The answer shifted from “costs are high” to something much more useful, which is that rework tied to quality issues was likely driving both cost and schedule impact. That’s the difference. Reporting tells you what happened. This starts to explain it.
What I liked about working with #Agent Bricks is that it doesn’t stop at building the agent. It gives you a way to improve it. You can generate evaluation datasets, score responses, and refine behavior over time. Everything still sits on governed lakehouse data, so you’re not losing control of definitions or access. That part matters more than it sounds, especially in finance heavy environments where consistency is non negotiable
The piece that I think people underestimate is feedback. The system only gets better when someone actually reacts to its answers. With #ALHF, you’re essentially letting the system learn from how real users respond. Someone reads an answer and says this is right, or this missed something, or this focused on the wrong signal. Over time, those small corrections start shaping how the system behaves. In construction, that’s important because different roles care about different things. Finance looks at cost drivers, project controls focuses on milestones, and field teams care about what’s actually happening on site. The system becomes more useful when it starts to reflect those priorities
If I’m being honest, the hardest part wasn’t the agents at all. It was getting the data to line up properly. Making sure finance, project, and field data actually connect in a meaningful way takes more effort than expected. If that layer is weak, everything feels off. If it’s solid, the rest comes together much more easily.
I don’t think dashboards are going anywhere. They still have a place. But they’re starting to feel like just one layer in a bigger system. The shift that stood out to me is pretty simple. We’re moving from asking what happened to asking what is happening and what should we do next. That’s where this kind of setup starts to help. Not by replacing people, but by taking on the part that slows everyone down, which is connecting the dots. If I had to start over, I wouldn’t begin with the model or the tools. I’d start with one simple question: what investigation do people keep repeating every week. That’s where something like this actually becomes useful.
#Agentbricks #SupervisorAgent #DatabricksDataIntelligencePlatform
