Sponsored by
The Modern Leader has a new home for premium membership. Check it out here. You’ll get full archive access, Leadership Hotline answers, templates and tools, plus courses and direct access to me at the higher tiers. Pick the level that fits.
Last week's post ended with an idea I didn't chase all the way down. I called it spelunking: an agent poking around a small ticket, proposing something, mostly unsupervised until review. I framed that as a way to clear out work that used to be too annoying to justify touching. That undersells what's actually useful about it.
The same behavior, done on purpose instead of by accident, might be the quickest way to find the real plan for something nobody's scoped yet.
I ran into a related argument this week in Mia Kiraki's newsletter, Robots Ate My Homework. Her case: stop treating different AI model outputs as competitors for "best," and start reading the differences between them as diagnostic. If one model assumes you're writing for experts and another for beginners, that's not noise to filter out, it's a sign you never actually decided who the audience was. The gap between two outputs is doing the same job a good clarifying question would do.
That's the same move I'm describing, just one level down. A single agent, given room to try two or three approaches instead of one tightly-specified one, hands you that same kind of gap to read. Not "which attempt got closest to correct," but "what does the spread of attempts tell me about what I haven't decided yet."
A thank you from this week’s sponsor:
The best voice models, now across all channels
Most CX platforms do not own the voice. They orchestrate a workflow, then call a third party for speech and transcription. Every hop adds latency, cost, and another vendor to manage.
ElevenAgents is the opposite. They make the voice models the market builds on, and ElevenAgents puts full orchestration on top. Voice, transcription, text-based chat, and reasoning run in one vertically integrated pipeline, so responses come back in <400 milliseconds and sound human, not synthetic.
Plus, you keep full control. Plug in any LLM, integrate tools, webhooks, and MCP servers, and ground responses in your knowledge base. Get an agent live in minutes, then A/B test with Experiments, enforce Guardrails, and version every change.
The payoff: more human conversations, lower latency, and far less time stitching infrastructure together. You build on the models you already trust. Pricing is transparent and flat at $0.08 per minute.
The default instinct works against this: write the tight spec, hand the agent a narrow lane, expect something close to production-ready on the first pass. It feels like discipline. But it front-loads a decision nobody's ready to make yet, what the solution should even look like, before anything has shown you the shape of the problem.
The alternative is to let the exploration be bad on purpose. Turn an agent loose on two or three directions with almost no constraints, and don't read what comes back like a reviewer. Read it like you'd read those diverging model outputs. Where did the attempts disagree? What did one assume about scope, or ownership, or performance, that the others didn't touch at all? Those disagreements usually point straight at the question you hadn't answered yet.
Then you delete the code and keep what it taught you.
Watching two hours go into something you're about to throw away doesn't look like progress. But you didn't spend those two hours writing code. You spent them finding out, cheaply, what you hadn't decided yet about your own plan. The plan you build after that is better because the unresolved question already surfaced, on purpose, before anything shipped.
I'm not recommending you tell your teams to use this approach for every ticket that comes through. Sometimes bugs are really that simple. But when you're dealing with a vague problem, this is an excellent approach to getting to a more thoughtful solution instead of settling on the first pass.
I don't have a clean rule for how long to let this run. Cut it off too early because the mess makes people nervous, and you build the wrong thing carefully. Let it run too long chasing a direction that was obviously dead an hour in, and you've just burned a day.
A few things make it easier to get right: nothing from an exploratory run gets merged, no matter how close it looks to working. There's a time limit on it going in. And the debrief starts with what the attempts disagreed about, not what got built. Asking the second question first tends to mean the first one never really gets answered.
Deadline pressure will always tempt a team to ship the ugly first draft. The discipline is making sure a bad attempt gets to teach something before that happens.