Not a goal, not a department, one task. Agents fail on vague briefs far more often than they fail on hard problems, and a brief is only as good as the process behind it.
Pick a task that already has a written process
If a person cannot describe the steps to you, an agent cannot follow them either. That is not a limitation of the technology, it is the same reason a new hire struggles.
Write the steps down first. Half the time this alone shows you the process is broken, and you fix that instead. That is a win, not a detour.
Write the brief like a job description, not a command
The briefs that fail describe activity. The briefs that work describe the outcome, what good looks like, what to do when something is unclear, and when to stop and ask a person.
If your brief does not say what to do when the input is weird, the agent will guess. It will guess confidently.
Build it where you can see the steps
I build these in n8n. The reason is not that it is the most powerful option, it is that every step is visible on a canvas, so when something goes wrong you can see which step went wrong.
Anything that hides its own steps will cost you the time it saved the first time it breaks.
Keep a human approving the output at first
For the first few weeks, the agent proposes and a person approves. This is not timidity. It is how you find the failure modes that no amount of planning would have surfaced.
When approvals stop changing anything, that is your signal to let it run.
Do not start with the customer facing one
Start somewhere a mistake is cheap and invisible. Internal, boring, repetitive. Get one working end to end, learn what actually breaks, then move outward.
The first one is not really about the task. It is about finding out how your business behaves when a piece of work moves out of a person's hands.