Message in a bottle

Most businesses that struggle with AI agents aren’t hitting a technology limitation. They’re hitting a briefing limitation.

The pattern tends to look the same. Someone gives an AI agent a loose, conversational instruction. The kind of thing you’d say to a colleague over coffee. The agent runs with it and produces something that’s technically functional but misses the point. The conclusion: AI isn’t ready yet, or it doesn’t work for our use case.

But often the problem isn’t the system. It’s the message.

The species simulator story

Anthropic’s Jack Clark told a story recently that captures this well. He wanted to build a species simulation — predators, prey, roads, a kind of 2D strategy game. He fired up Claude Code and described what he wanted in a paragraph of loose language.

The result was, in his words, horribly buggy and only kind of worked.

So he tried something different. He asked Claude to interview him about the project. What are the rules? How should the species interact? What does the visualisation need to look like? The system asked probing questions, and the output was a detailed specification document.

He gave that spec back to Claude Code. Ten minutes later, he had a working simulation that would have taken a skilled developer hours or days. Not because the AI got smarter between attempts. Because the brief got better.

Clark called it a “message in a bottle” problem. When you hand a task to an AI agent, you’re not having a conversation. You’re writing a set of instructions that will be carried out without you in the room. That message needs to be specific, structured, and detailed enough that the system can execute without guessing.

Why loose briefs fail with agents

We’re used to working with people who fill in the gaps. When you brief a colleague, they bring context. They know the company, the client, the last three projects. They’ll ask clarifying questions. They’ll make reasonable assumptions based on shared experience.

AI agents don’t do that. They’ll work with whatever you give them, and if the brief is vague, the output will be technically functional but off target. Not because the system lacks capability, but because it took your instructions literally and had nothing else to go on.

Clark put it well: the mistake is thinking of an AI agent as a knowledgeable colleague, when it’s actually an extremely literal one that you can only communicate with through text.

This is a common pattern we see when AI adoption stalls at the workflow level. The technology works. The integration into how people actually brief and manage work hasn’t caught up.

Let the system help you write the brief

What’s interesting about Clark’s approach is that the AI wrote the spec too. He didn’t draft a requirements document from scratch. He asked the system to interview him, draw out the details, and structure them properly.

That’s a workflow pattern worth adopting more broadly. If your team isn’t sure how to brief an agent, start by asking the agent to help define the brief. Let it ask questions. Let it probe for the details that would normally stay implicit. Then hand that structured output back as the instruction set.

The quality of what comes back tends to be noticeably better. Not because you’ve unlocked a hidden capability, but because you’ve given the system what it actually needs to work with.

This applies well beyond code

The same principle holds for content briefs, research tasks, data analysis, strategy documents. Any time you’re asking an AI system to go away and produce something on your behalf, the quality of the input shapes the quality of the output.

A vague instruction like “write a report on our market position” will get you something generic. A structured brief that includes the audience, the angle, the key data sources, the tone, and what a useful output looks like will get you something your team can actually act on.

This isn’t a new idea. Anyone who’s managed freelancers or agencies knows that a bad brief produces bad work. The difference is that AI agents won’t push back on a bad brief. They’ll run with it and deliver something that technically matches what you asked for.

The bottleneck isn’t prompting. It’s thinking.

The conversation around AI often drifts toward prompt engineering, as if there’s a precise phrasing that unlocks better results. But Clark’s story suggests something simpler. The bottleneck isn’t the prompt. It’s the thinking behind it.

Do you actually know what you want? Have you thought through the constraints? Can you articulate what good looks like before you see it?

If the answer is yes, the AI will likely deliver. If the answer is “roughly, we’ll know it when we see it,” you’re going to burn through iterations and end up questioning the tool rather than the process.

This connects to a broader point about what an AI system actually looks like in practice. It’s not just the technology. It’s the structure around it — the briefs, the workflows, the feedback loops that make the technology consistently useful rather than occasionally impressive.

The message in a bottle only works if you write a good message. And writing a good message means doing the thinking first.