Most of the disappointing results we see from a bot trace back to the first message. It said what the person wanted. It said nothing about what finished looks like or what the bot must leave alone, and it didn't ask to see who was going to do the work before anyone started.
Sean Donahoe, our founder, said this back in May: "Most people say 'I want X' but there's no detail in that, there's no context in that. A good agentic system needs clarification." Murage asks when it isn't sure. But every question it has to ask is a round trip you could have skipped, and some things it won't know to ask about.
Three lines fix most of it. They're short enough to type on a phone.
What done looks like
One page, a list, a draft, a decision. Say which. "Research the dental market" can come back as a 40-page report or as a paragraph, and both are correct answers to the question as asked. "One page with sources" is a brief. So is "a table of the nine competitors with what each charges", or "a yes or a no, with the two reasons".
Add a length when length matters, as a number. Under 300 words. Under 120 words per card. Fifteen hooks. Bots take numbers literally, which is what you want from them.
What it must not do
Send nothing. Post nothing. Change nothing in the CRM. Contact nobody.
This is the line people leave out because they assume it, and the honest answer is that Murage mostly assumes it too: new bots start on Ask, and sending to someone new or posting publicly stops at the stop line whatever the level. We'd still write it. A bot with "send nothing" in its brief plans the job differently from one that thinks sending might be the last step, and if the brief turns into a routine, those words run every week without you.
The other must-not is scope. "Only the open deals." "Only October." "Leave the internal meetings alone." Each one is a thing the bot would otherwise have to guess, and the guess is usually bigger than you wanted.
Whether you want the plan first
For anything that will take more than a few minutes, add "show me who you'd put on it before anyone starts". Your Chief of Staff proposes the team, Research and an Analyst and Copy, say, and you see the shape of the job before a token is spent on it. Half the time you'll look at the proposal and realize the brief was wrong, which is a cheap moment to find that out.
Sean's own habit here is the one we'd copy: "I put out what I expect, but I give it the opportunity to come up with something better." Write the brief you think is right, then ask whether there's a better way to do it. Sometimes there is.
Put it in the project, then correct it
A brief typed into a chat is read for that job. Put the same words in a project's goal, up to 2,000 characters, and every bot in the project follows them on every turn. For a routine, the instructions can run to 100,000 characters, which nobody needs, but it means the brief for a weekly job can carry the format, the exceptions and the one client who gets handled differently.
Then correct. When a draft comes back wrong, say what's wrong in words that can be reused: "Keep client emails under five lines" teaches more than "shorter". The bot keeps that as a lesson, you can read every lesson it has kept in its memory, and you can edit or undo any of them. The guide on how bots learn from your corrections covers it.
A brief with those three lines in it is still a brief. You don't need a persona or a page of rules on top of it. The team is better at the how than you are at describing it. What it can't know is what you'll be happy with, so that's the part you write.
Download Murage, open a chat with your Chief of Staff, and give it one job today with the three lines in it. Pick something you'd have done yourself this afternoon, so you'll know whether the result is right.