Building got cheap. The thinking that made building worth it didn’t get less important. One of the tools that forced that thinking is sitting on a shelf, and now is exactly the wrong time to leave it there.
You can stand up an agent in an afternoon now. Wire a model to a few tools, give it a prompt, point it at a problem, and watch it do something that looks like work. A prototype that would have been a quarter of engineering effort three years ago is a weekend. The barrier to building has dropped further and faster than almost anyone predicted.
And in the rush through that open door, I keep watching teams leave something behind. Not the code. The conversations that used to happen before the code. The practices that decided whether the thing was worth building in the first place have quietly stopped happening, because building is now so cheap that skipping straight to it feels like speed instead of recklessness.
Product management is full of these practices, and a lot of them haven’t had much airtime in the last few years. The canvas is one of them. I want to make the case for pulling it back off the shelf, because the moment that makes it look optional is the same moment that makes it matter most.
What the canvas was actually for
I’ve spent more than twenty years running product, engineering, and security teams, and advising the people who run them. Somewhere in there I became a believer in the canvas, in its various flavors, and I should be precise about what I came to believe in.
It was never the boxes. A canvas is a single page with blocks on it: who the customer is, what problem you’re solving, how value gets created, what it costs, how you’ll know it worked. The lineage is worth knowing. Alexander Osterwalder’s Business Model Canvas formalized the idea in 2010, taking a sprawling, multi-stakeholder thing and putting it on one page so people could see it together. Ash Maurya narrowed it into the Lean Canvas for startups. Louis Dorard adapted the format for machine learning in 2015, and his framing has stuck with me: he argued that ML failure is usually a design and alignment problem, not a modeling one. The model wasn’t where projects died. The shared understanding was.
That’s the part that earned my trust. The value was never the artifact you ended up with. It was what happened in the room while you filled it in. A product person, an engineer, a domain expert, and someone who owned the risk would sit down to complete a board that any one of them thought was obvious, and within twenty minutes they’d discover they had been describing four different products. The canvas surfaced the disagreement early, on a whiteboard, before it surfaced late, in production. The what, the why, the who, the when, the how. Cheap to argue about on paper. Expensive to discover after you’ve built the wrong thing.
The board was just the thing that forced the conversation. You could throw the board away afterward and keep most of the value, because the value was the alignment, not the document.
Agents make the conversation matter more, not less
Here’s the trap in the current moment. The easier building gets, the less necessary the upfront thinking feels, and the more it actually matters.
Traditional software does what you program it to do. When it fails, it fails in ways you can usually trace and contain. An agent is different in kind. It receives a goal, decides how to pursue it, calls tools, takes actions, and adapts when something doesn’t go as planned. That autonomy is the whole point, and it’s also the reason the failure modes are sharper and the blast radius is bigger. A traditional bug processes a record wrong. An agent with the wrong boundaries books the wrong thing, emails the wrong person, or spends real money before anyone notices.
So the questions a canvas forces are not the same questions you asked about a feature, and they’re harder. How much should this thing decide on its own, and where does a human stay in the loop? What tools can it touch, and what happens when one of them fails? When does it escalate instead of pressing ahead? What does it refuse to do regardless of what it’s asked? What context is it working from, and what is it not allowed to see? None of these answer themselves, and none of them are visible in a demo. The demo shows you the agent working. It doesn’t show you the agent deciding, at 2 a.m., on a case nobody anticipated.
This is exactly the kind of complex, cross-functional, high-uncertainty system the canvas was built to think through before building. The format barely needs to change. The conversation it forces is more valuable now than it has ever been, because the cost of getting it wrong went up at the same time the cost of building went down.
The same discipline, inside or out
One objection I hear is that this is a product practice, and a lot of agentic work isn’t a product. It’s an internal automation, a workflow, something the team builds for itself. The discipline transfers anyway, and I’d argue it transfers cleanly.
When you’re building an external AI product, the canvas conversation leans harder on the things customers feel: trust, transparency, how someone recovers when the agent gets it wrong, what the experience is when it hands off to a human. When you’re building an internal agent, the same conversation leans harder on governance, on cost per outcome, on which systems it’s allowed to act in and who’s accountable when it does. The emphasis shifts. The board doesn’t. You’re still sitting down with the people who hold different pieces of the truth and forcing the what, why, when, and how into the open before you commit.
I’ve watched internal projects fail for the identical reason external products fail. Nobody disagreed in the room because nobody had the room. The work felt too small or too obvious to warrant the conversation, so the conversation didn’t happen, and the disagreement showed up later wearing the costume of a technical problem.
Six things the conversation has to nail
If you do run the canvas conversation for an agentic project, internal or external, these are the places I’ve seen it earn its keep. They are less about filling boxes and more about what the discussion has to actually settle.
Start with the problem, not the technology. The discipline the canvas enforces is refusing to talk about the agent until you can say plainly who is served and why they’d prefer this to what they do today. If you can’t, you don’t have a problem worth automating. You have a tool looking for a use.
Be deliberate about autonomy. Decide explicitly how much the agent does on its own versus what a human approves, and start lower than feels necessary. Raising autonomy once you’ve earned trust is easy. Rebuilding trust after an agent did something irreversible without asking is not.
Name the boundaries and the failure path. What the agent won’t do, when it escalates, and how you recover when it gets something wrong. Vagueness here is where agents do real damage. “Use good judgment” is not a boundary.
Ground it in real context. An agent is only as good as the data and knowledge it can reach. Be specific about the sources it draws on, how fresh they need to be, and just as important, what it is not allowed to touch.
Build safety and governance in from the start. This is the one teams most want to defer, and the one you cannot bolt on later. Validation, approval checkpoints for high-stakes actions, an audit trail, and the compliance constraints that actually apply to your domain. Decided early or decided badly.
Plan to learn. Agents drift as models change and the world moves. Decide up front how you’ll know whether it’s working, how corrections flow back into better behavior, and what you’re watching so slow degradation doesn’t hide until users start complaining.
Pull it off the shelf
The tools got easy. That’s real, and it’s good. But easy to build was never the same as worth building, and the gap between those two is exactly the space the canvas was made to work in. The discipline didn’t stop being valuable because the barrier to entry fell. If anything, the falling barrier is what makes the discipline scarce, and scarce is usually where the edge is.
The conversation costs an afternoon. Building the wrong agent costs a great deal more than it used to be able to, because this kind of software acts on its own. Spend the afternoon.