How to write a goal an AI agent can actually execute

"Get more customers" is not a goal — it's a mood. An agent team reading it cannot tell when it's done, who it should be looking for, where to look, or what it must never do. That's not a limitation of AI; a human freelancer handed the same sentence would be just as stuck. Goals are specifications, and vague specifications produce vague work regardless of who does the working. The fix isn't writing more words. It's writing four specific things.

Every goal that agents can execute answers four questions, usually in a single sentence:

Each part maps directly to how the work gets set up. On Brohns, the outcome tells Bro — the assistant that assembles your agent team — what "done" means and how fast the team needs to move. The audience and region tell a sourcing agent like Finder exactly which businesses or people to surface. And the constraints don't just steer the drafts: several of them become settings the platform holds the agents to, which we'll get to below. You write all of this in plain language; nobody is asking you to fill in a config file.

Here are eight goals the way people actually say them, rewritten the way an agent team can actually run them. Each rewrite took under a minute of extra thought — the pattern is always the same four parts.

Notice what every rewrite added: a number, a place, and a fence. Notice what none of them added: process. Not one says which data source to use, how many agents to spin up, or what order the steps should run in. That part isn't your job, and holding onto it actually makes the result worse — more on that in the last section.

When you hand Bro a goal, it doesn't start working immediately. It asks one to three short questions first — typically about audience, region, channels, tone, or what success looks like to you. If you've read this far, you'll recognize that list: it's the anatomy from section one. The interview exists to fill in whichever of the four parts your goal left out, before a single agent does a single unit of work.

This is worth defending, because it feels slower than a tool that just starts. A system that never asks is not smarter — it's guessing, and guesses compound. Skip the region question on "more clients for my design studio" and a sourcing agent can spend its effort surfacing businesses three time zones away. Skip the tone question and you'll be rewriting every draft by hand. One clarifying question up front replaces twenty corrections later, and corrections are where delegated work quietly stops saving you anything.

Answer the questions the way you'd answer a sharp contractor: short and decisive. "Amsterdam and Haarlem." "Email only." "Direct, no exclamation marks." And "I'm not sure" is a legitimate answer — just follow it with what you'd accept, like "I don't have a target number; a steady five qualified conversations a week would be a win." That's still a spec. It's just a spec with honest error bars.

In most tools, a constraint is a polite request buried in a prompt — the software has no mechanism to honor it. On Brohns, the fences you write into a goal map to guardrails the server actually holds agents to: a daily send limit, a send window so nothing goes out at 2 a.m., a do-not-contact list for clients and names that are off-limits. "Max 10 emails a day, business hours only" isn't flavor text. It becomes configuration.

And there's a floor beneath even the best-written goal: writing one never hands over the keys. Everything outward-facing — every email, reply, post, and payment reminder — lands in your Approvals queue as a draft, where you approve it, edit it first, or dismiss it. So a sharp goal doesn't buy the agents independence; it buys you a queue full of drafts that are actually worth approving. Later, once the drafts have earned it, you can grant routine autonomy step by step per team — and step back down whenever you want. The goal sets the direction; the trust gets built afterward, in the open.

The opposite failure is just as common as vagueness: over-specifying the method. "Pull businesses from this directory, then send a five-step sequence, then follow up on day three..." — write that, and you haven't briefed an agent team, you've written a script with extra steps. You've also thrown away the one thing an orchestrator is for. Given your goal, Bro proposes the team it actually needs — usually two to seven agents, each with one sharp responsibility, like a Finder feeding a Qualifier feeding an Outreacher — and shows you the design for approval before anything runs. If the proposed route looks wrong, that's the moment to say so, with full context in front of you.

The line to hold is boundaries versus method. Channels you refuse, tone, budget, deadlines, names never to contact — those are boundaries. They're yours, and they belong in the goal. Which data source to use, how many agents to run, what order the steps go in — that's method, and it belongs to the team you're briefing. A quick test before you submit: could a capable stranger read your goal and know what done looks like, who it's for, where, and what they must never do — without knowing anything about how you'd do it yourself? If yes, send it, answer the two questions that come back, and let the team show you its plan.