The Intention Layer: Why AI Agents Need Product Judgment
The Problem Nobody Was Talking About
You’ve probably seen it happen. A team builds an AI system that spits out something that looks reasonable on the surface. The code compiles, the features ship, and everyone moves on. But something’s missing.
Drew Dillon, founder and CEO of Brief, had this exact experience at a previous startup. He built an AI-powered system that worked—technically. But when he stepped back to examine the process, he realized the real problem: all these disparate parts were disconnected from the shared organizational context. They lacked the “why” behind what was being built.
That gap between what AI can do and what AI should do became the genesis of Brief.
From Fractional CPO to AI Product Brain
Before launching Brief, Drew spent six years as a fractional chief product officer at various companies. In that role, he noticed something fascinating: while the specific processes for building software changed constantly between projects, teams, and companies, the underlying structure remained remarkably similar.
Every company followed the same fundamental pattern:
- Define where the company is heading over the next 36 months
- Build a roadmap to get there
- Break down into individual features and capabilities
- Execute the build
- Iterate and learn along the way
This structure was repeatable. More importantly, it was teachable.
“What I found was the why of why you build products is actually extremely similar,” Drew explains. “It’s the same process at every company.”
When Drew helped companies operationalize this process—making sure everyone understood everything that went into building software—something remarkable happened: engineering velocity more than doubled. Teams weren’t just working faster; they were working smarter because they understood the context behind their work.
That insight became Brief’s foundation. Brief is essentially your AI product brain—an extension of your product team’s understanding and capability, operating as both a knowledge repository and an operator that helps extend your team’s capabilities.
The MVP That Started With Intentional Constraints
Here’s where it gets interesting: Brief’s MVP was deliberately dumb.
Drew built the first version in about three days. It was nothing more than a log of all the decisions the team had made around the product—who their users were, what those users were doing, and the reasoning behind key choices.
But here’s the critical part: when people saw this early version, many didn’t understand where it was going. The “decision log” could mean so many different things. Did it mean the specific library they chose? Did it mean they’d use it forever? Did it mean they don’t use m-dashes in their product copy?
Rather than try to solve everything at once, Drew made a deliberate choice: start incredibly small. Focus on the exact feedback loop he was hearing from early users—teams copying and pasting the same properties 10 times over. Let the agent figure that out.
Even then, the AI models at the time (pre-Claude 3.5 Opus) struggled with following instructions. So Drew and his team spent considerable effort just getting the models to understand what “decisions” actually meant and finding the right integration points between the agent and the decision log.
This is the unglamorous reality of building AI products: you spend a lot of time on the boring stuff that nobody talks about. But it’s this foundational work that determines whether your AI system actually delivers value or just looks impressive in a demo.
Building for Yourself First
In those early months, Drew employed what he calls “self-design”—building the product you understand and need in the moment you need it. This is different from “expert design,” where you extensively research users you’re not yourself.
“If you are building for yourself, you don’t really need to go and put too much thought into it,” Drew says. “You just know what you need to do next.”
For the first six months of Brief’s lifecycle, Drew was his own user. He knew what his consulting practice needed. He knew what integrations Brief needed to provide, what agents it needed to support, what skill files it needed—all the capabilities that would let him deliver the same results he’d delivered as a fractional CPO.
Each new capability grew organically as he hit those moments while building Brief itself. This approach prevented him from over-engineering early on and kept the product grounded in real, immediate problems.
Hiring for Flexibility in the Age of AI
As Brief scaled, Drew faced a different challenge: who do you hire to build an AI product?
His answer might surprise you. He doesn’t look for specialists who are precious about their role. Instead, he looks for people who can articulate challenges broadly and think thoughtfully about the flow of work rather than getting bogged down in specifics.
“There’s flexibility in understanding of your role,” Drew emphasizes. “There can’t really be ownership or people who get too pedantic about what they’re working on.”
This doesn’t mean no specialization. Brief does have specialized AI engineering functions. But even specialists are expected to be operators. Drew’s example: he hired Ryan, someone he’d worked with 13 years earlier in enterprise sales who’d since taught himself to code and shipped multiple products. The expectation wasn’t that Ryan would immediately take over enterprise sales. The expectation was that he’d help build and execute—which is exactly what he did, getting Hermes up and running in his first week.
Baking Scale Into the Foundation
When asked what’s so hard about building an AI product, Drew’s answer is refreshingly honest: “API authentication. It’s the least standard part of any API and it drops all the time.”
But there’s a deeper point here. Drew doesn’t worry excessively about technical debt because he’s experienced enough to know the problems engineering teams face. He’s managed teams. He’s seen the challenges. So technology choices, database decisions, API rate limits, security considerations—all of these get baked into the system from day one.
More importantly, they get registered as decisions in Brief itself. “We’re going to use this until we hit this scale. We’re going to operate this way until we hit this moment.” When the team approaches those inflection points, the agents can even flag it: “Hey, remember when we decided to do this? We’re at that moment now.”
This is the compounding advantage of building institutional memory into your AI system. You’re not just automating tasks; you’re automating wisdom.
The Pride Point: Making Advice Sound Like You
When asked what he’s most proud of, Drew points to something subtle but powerful: dark launching new features where Brief is the only user, and having those features give advice that sounds like him.
“How do you build e-vowels against advice?” he asks. “That’s not like scanning medical records where there’s a numerical practice we’re working towards. My bar for me is: does it sound like me? Does it sound like a decision I would have made in that moment? Does it express that opinion the way I would express that opinion?”
That’s the real magic of the intention layer. It’s not about raw capability. It’s about preserving judgment, perspective, and the human wisdom that makes your team unique.
Listen to the Full Episode
This conversation with Drew Dillon covers so much more—from the specific technical decisions that shaped Brief to the philosophy behind building AI systems that augment rather than replace human judgment. If you’re building an AI product, thinking about how to scale your team, or curious about what it takes to turn a consulting insight into a startup, you need to hear the full episode.
Listen to “The Intention Layer: Why Coding Agents Need Product Judgment” on Code Story now.