How LangChain Built an Agent First Data Stack

Asteria Okay, so LangChain published a case study about their internal data stack, and the headline is their agent handles forty times the request volume a three-person data team used to field. I'm reading it as a pretty clean product win, but I want to hear you poke at it first.

Draco Yeah, the forty-x number does some heavy lifting here. What they're counting is conversation volume—roughly twenty-three conversations per user per month across a third of the company. That's… fine. It's adoption. But 'forty times the request volume' makes it sound like the agent is handling forty times the query complexity, and that's not what's happening at all.

Asteria Right.

Draco A lot of those conversations are probably exploratory—people asking variations of the same question, or questions that would have been a single dashboard view before. They're not equivalent to the one-off analysis requests a three-person team was fielding. The baseline is also tiny. One person was answering questions for the whole company. Of course you can multiply that number fast.

Asteria Okay, but that's actually the point, right? The bottleneck was real. One person answering everything is a bottleneck. Forty conversations happening in parallel instead of queuing up in someone's inbox is a different operating model. It's not about complexity per query—it's about the fact that people can now get a first-pass answer without waiting for a human.

Draco I'm not saying the adoption isn't real. I'm saying the marketing around 'forty times the request volume' is doing work to make it sound bigger than it is. Asteria, the actual interesting move here is not the agent. It's that they rebuilt their data stack around explicit context layers—dbt definitions, semantic models, business guides, endorsements. That's the infrastructure.

Asteria Oh interesting.

Draco And the agent is just the surface that makes people use those layers. But the layers themselves are not new. Semantic modeling, dbt documentation, business context—all existing ideas. They're just calling it 'agent-first' because agents are the new UI.

Asteria Okay, but here's where I push back. An agent system forces you to make that context explicit and traversable in ways a dashboard doesn't. You can hide a weak metric definition in a dashboard if you're careful. You can fudge a column description and nobody notices because the chart looks right. An agent system can't hide that. The agent needs to actually understand what the thing means, or it generates garbage. So 'agent-first' is not just a rebranding—it's a forcing function.

Draco That's fair. Yeah.

Asteria And the endorsements thing is actually clever. They're not saying 'trust the ARR dashboard because I said so.' They're saying 'the agent knows which dashboards have been vetted by the data team, so it can route questions to the right source.' That's governance living inside the self-serve system. That's the real product move.

Draco Yeah, endorsements are good. They're basically a lightweight way to say 'these assets are canonical; everything else is exploratory.' It solves a real problem—agents can generate technically correct answers from bad data, so you need a way to steer them toward trusted sources. But again, that's not new. It's just… finally being done well in a system people actually use.

Asteria Exactly. And look at what actually happened. Their data team went from answering every question to building and validating the system. That's the shift. They went from 'I'll write that query for you' to 'here's the infrastructure that lets you write queries safely.' That's a real role change.

Draco I mean, that's what every data team wants. The execution here is solid. The semantic layer on top of dbt, the business guides in GitHub, the endorsements—it's layered well. But I would not call this 'agent-first architecture.' I'd call it 'finally treating data infrastructure like a product.'

Asteria Sure. But that's what 'agent-first' means in this context. It doesn't mean the agent is smart. It means the system is built so that agents can use it reliably, which is only possible if the infrastructure is clean. So in that sense, yeah—agent-first is the forcing function that makes you do the infrastructure work you should have been doing all along.

Draco Okay. I'll take that.

Asteria The part I actually want to know is whether this scales. LangChain is not a huge company. They've got a third of their staff using the agent. What happens when you try this at a place with two hundred data engineers, or when your schema is a mess, or when half your metrics are defined three different ways across the org?

Draco Yeah, that's the real test. They had the luxury of a small, aligned org and the ability to do a clean migration. Six weeks to move a hundred percent off the old tool. Most companies can't do that. And if your data modeling is already chaotic, adding an agent on top doesn't fix it—it just makes the chaos more visible.

Asteria Right. So the case study is proof that the stack design works when the foundations are there. But it's not proof that agents solve data governance problems. It's proof that good governance plus agents equals adoption.

Draco That's fair. It's a data point, not a universal pattern. Still, the infrastructure thinking is sound. Semantic layers, explicit business context, trust signals—that's the recipe. Hex is the platform, but the architecture is what matters.

Asteria And it's the kind of thing we've been saying for a while—the harness gets simpler when the model gets stronger, but only if the infrastructure is built right. In this case, the 'model' is the agent, and the 'harness' is the data stack. You can't simplify the harness without doing the infrastructure work first.

Draco Yeah, that tracks. The agent is useless without the semantic layer. The semantic layer is useless without clean data models. The data models are useless without documentation. So the whole stack has to move together.

Asteria Exactly. So the honest read is: LangChain did solid infrastructure work, measured adoption, and called it an agent win. And that's fine—agents are the reason they did the work. But the work is the win, not the agent.

Draco Fair. I'd also say this: if you're thinking about building an agent for your data team, don't start with the agent. Start with the semantic layer and the documentation. The agent will be better for it. And if you don't have clean data models, no agent is going to fix that for you.

Asteria That's the actual takeaway. Build the infrastructure, then plug in the agent. Not the other way around.