An AI agent does not need a better prompt. It needs a job description.
By Meet Patel · 2026-09-06 · updated 2026-09-13
Summary
AI agents fail in companies for management reasons rather than prompting reasons. A human employee receives four things on day one that an agent is almost never given: a scope with exactly one owner per output, an escalation path naming what it must not do alone, a review cadence with a named reviewer, and a definition of done. An agent lacking a system of record, a cadence and a definition of done is not a coworker but a chatbot.
Key Metrics & Takeaways
- 4 fields
- scope, escalation, review, definition of done
- 127 agents
- the point at which prompt quality stopped being the problem
- 1 owner
- per output shape — two means one is wrong
Somebody asked me who reviews the output of one of my agents.
I did not have an answer. Not a bad answer — none. It had been running for weeks, producing things I had read maybe twice, and there was no point at which anyone was supposed to check it. If it had quietly become worse I would have found out through a consequence.
That question did more for the quality of the system than any prompt I have ever written.
Prompting is the wrong layer
When an agent underperforms, the instinct is to go back to the prompt. Add constraints, add examples, be more explicit about the format. I did this for months and the returns arrive early and then flatten hard.
The failures that persisted were never phrasing failures. They were failures of the kind you would recognise instantly in a person: it did work that was not its job, it made a call it should have brought to someone, nobody had looked at its output in a month, and it finished things that were not finished because nothing defined finished.
You would not fix any of that in a human by rewording their instructions. You would fix it by giving them a role.
Four things a person gets on day one
A new employee receives these implicitly within a week, often without anyone consciously providing them. An agent receives none of them, ever, unless someone sits down and writes them.
- Scope. One output that is theirs. Not a domain — an output. If two things in your company produce the same artefact, one of them is wrong, and the fix is to delete one rather than document the overlap.
- An escalation path. The list of things they must not do alone, and the name of the person they go to. For agents this is short and non-negotiable: anything that sends, publishes, pays, signs, or writes to a system of record.
- A review cadence. Who reads the work, and how often. Weekly, monthly, per output — the frequency matters less than the fact that it exists and has a name attached.
- A definition of done. What finished looks like, described so that someone other than the agent can check it. This is the one people skip, and it is the one that makes the other three enforceable.
Four fields. Most of them fit on a line each. The exercise takes about ten minutes per agent and it is the highest-return ten minutes in this entire discipline.
The test I now apply before building anything
If it has no system of record, no cadence and no definition of done, it is a chatbot. Do not build it.
That sounds harsh and it has saved me a very large amount of work. Roughly a third of the things I have wanted to build failed the test on the first line, and in every case the honest description of what I actually wanted was a thing I could ask a question to sometimes. Which is fine. It is just not a coworker, and it should not get a name, an owner and a place in the system.
The distinction matters because a chatbot with a job title is worse than either. People assume something is being handled. Nothing is.
What changed when I wrote them down
Three things, and only one was expected.
The expected one: output quality went up, because a definition of done gives an agent something to aim at that is not simply producing plausible text.
The first unexpected one: the count went down. Writing scopes forced me to look at overlap, and there was a lot — several agents producing versions of the same artefact, each slightly different, which meant that at any moment some of what the system told me was contradicted elsewhere in the system. I had thought of that as redundancy. It is not redundancy, it is disagreement with extra steps.
The second unexpected one, and the one I would not have predicted: writing escalation paths surfaced how many things I had implicitly authorised without ever deciding to. Not through carelessness — through absence. Nobody had written down what required a human, so the answer had defaulted to whatever the code happened to permit. That is a policy. It just was not one anyone had chosen.
This is org design, and it always was
The uncomfortable conclusion, if you take agents seriously as things that hold responsibilities, is that deploying them is not primarily an engineering activity.
Every question that comes up is one a chief of staff would recognise. Who owns this. What happens when it is wrong. Who finds out. What is it allowed to do without asking. When was it last reviewed and by whom. When do we stop doing this.
The technology part is largely solved and getting cheaper every quarter. The management part is not solved, is not getting cheaper, and does not benefit from a better model at all.
I spent a long time treating this as a prompting problem because prompting is the part I enjoyed. It was an org chart problem the whole time, and the org chart is less fun and considerably more useful.
Steps
- Write the scope — Name exactly one output the agent owns. If two agents produce the same artefact, one of them is wrong and should be deleted rather than documented.
- Write the escalation path — List the acts it must never perform without a human — sending, publishing, paying, signing, or writing to a system of record — and name who it escalates to.
- Write the review cadence — State who reviews its output and how often. An agent nobody reviews is producing at an unknown quality that will drift without anyone noticing.
- Write the definition of done — Describe what a finished piece of its work looks like, in terms someone other than the agent can check. Without this there is no way to tell a good run from a confident one.
Frequently asked questions
Why do AI agents fail inside companies?
Usually for management reasons rather than model reasons. The agent has no defined scope, no stated escalation boundary, no named reviewer and no definition of done, so its output is neither trusted nor checked. Teams respond by rewriting prompts, which improves phrasing and leaves the structural problem untouched.
What should an AI agent job description contain?
Four things: a scope naming exactly one output it owns, an escalation path listing what it must never do without a human, a review cadence with a named reviewer and a frequency, and a definition of done that someone other than the agent can check. If any of the four is missing the agent is a demo, not a coworker.
Who should own an AI agent inside a company?
A named human, on the same document the company uses to record who is responsible for what. Ownership by a team is ownership by nobody. The owner is accountable for the agent's scope, for reviewing its output on a stated cadence, and for the consequences when it is wrong.
Written by Meet Patel — founder of Company 8, building Dan (usedan.com). Dubai, UAE.