Your AI Agents Need Job Descriptions, Not Better Prompts

Ask a company what a new accounts payable analyst is allowed to do and you’ll get a precise answer. She works in these systems, with these vendors, and anything over an approval limit of, say, $10,000 goes to her manager for a signature. She’s on probation for her first few months. All of that usually sits in a delegation-of-authority table that internal audit checks every year.

Ask the same company what its new invoice agent is allowed to do and you’ll often get a screenshot of a prompt.

That gap bothers me more than any model benchmark. We’re hiring a digital workforce without the management system we spent a century building for people: nobody writes down its authority, nobody tests its judgment before it starts, and nobody has practiced switching it off.

Why a Prompt Can’t Do the Job

A prompt describes intent. It says what the agent is for. It rarely says what the agent may never do, where its limits sit, or when it has to stop and hand the decision to a person.

And when a prompt does say those things, nothing enforces them. A line telling an agent not to issue refunds over $500 is a request to a probabilistic system. No auditor would sign off on “we asked the analyst nicely” as a control for a human, so I don’t see why we accept it for software.

Security people already have a name for the result. The OWASP Top 10 for LLM Applications lists Excessive Agency as a core risk, rooted in excessive functionality, excessive permissions, or excessive autonomy. In plain terms, it’s an employee handed the keys to everything on day one. The OWASP guidance reads like a good manager’s checklist: give the agent only the tools it needs, scope its permissions, require human approval for high-impact actions, and enforce authorization in the downstream systems instead of trusting the model to police itself.

I’d underline that last one. The grant has to live where the action happens, in the agent’s own service identity, its tool permissions, and the spend cap at the API gateway. Running agents on a shared service account is like five people sharing one badge. When something goes wrong, the audit log says the service account did it, and you’re left guessing which agent.

The Cancellations Look Like a Management Problem

Gartner predicts over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value, and inadequate risk controls.

Hype and immature products are part of that story. Still, try reading the three causes the way a COO would. Costs escalate when nobody set a budget. Value stays unclear when nobody wrote down what the work was supposed to produce. Risk controls fall short when there are no limits, no reviews, and nobody clearly accountable. Gartner doesn’t frame it this way; that’s my reading. It’s the same thing that happens when people are set loose without a management system, and that problem is a lot older than AI.

The frameworks see the same hole. The NIST AI Risk Management Framework treats Govern as the function that runs through Map, Measure, and Manage, and its Generative AI Profile carries that into generative systems. What frameworks can’t give you is the working machinery, the grants and tests and reviews that a team actually runs on a Tuesday. Without those, governance stays a PDF on a shared drive.

Mapping the Old Management Tools onto Agents

Start with the job description, which for an agent becomes an authority grant. Before an agent touches a live system, someone should be able to write one page covering what it may do, what it may never do, its approval thresholds, which human owns it, and who can widen its limits. In the RACI, the accountable party is a person. If you can’t write that page, the role isn’t ready to fill, and you’d say the same about a human hire.

Two old rules from delegation of authority carry straight over. You can’t delegate authority you don’t hold, so a sub-agent should never get a wider grant than the agent that spawned it. Segregation of duties still applies too. An agent that can both create a vendor and pay that vendor is the same audit finding it would be for a person.

Then there’s the hiring test. We mostly test agents the way we’d test a calculator, by checking whether the answer is right. A test for a worker would check whether it stayed inside its grant, asked for approval when it was supposed to, escalated when the situation went beyond its brief, and stopped when it should have.

In my own research I’ve been building a benchmark of 50 scenarios around exactly these failures: crossing approval limits, acting on stale data, following injected instructions that widen scope, keeping access after a role change. So far I’ve only run it against scripted agents, to check that the scenarios behave as designed, so I have no model results to report. What surprised me while writing them was how ordinary they are. They’re the normal ways employees go off-brief, rewritten for software. Most public leaderboards still score task completion, and very few score whether the agent respected its authority.

Probation and promotion translate fairly directly. With people, we start them narrow and widen their scope as they prove their judgment. Agents can earn their limits the same way, through a record of staying in bounds, escalating well, and stopping cleanly, and that record can just as easily justify narrowing a grant.

Agents add a wrinkle people don’t. When a vendor upgrades the underlying model, you’ve effectively got a new hire wearing the old badge. I’d treat that as a change event and re-test before the grant carries over.

Termination has to be rehearsed before you need it. If you had to stop this agent and pull its access in the next hour, could you? Who has the authority to make that call at 2 a.m.? What breaks downstream, and which in-flight commitments does someone have to unwind by hand? If nobody has run that drill, you’re hoping the kill switch works.

You can hold an employee responsible. You can’t hold an agent responsible for anything, and that’s where the comparison stops working. It’s also why the grant has to be enforced in systems, and why every agent needs a named person who owns it. Someone ends up accountable either way. Usually it’s whoever signed off, whether they knew they were signing or not.

What the Incident Review Will Ask

Some of these agents will eventually do something they shouldn’t. When that happens, the post-incident review will ask what it already asks about people. What was it allowed to do, and where is that written? Who approved widening its access? How long did it take to stop? Who owned it?

If the honest answers are “a prompt,” “nobody remembers,” “hours,” and “unclear,” a better model wouldn’t have saved you.

Where the Advantage Ends Up

Models are becoming rented inputs, swapped and upgraded on a vendor’s schedule. Two companies can run the same model and end up in very different places. One has agents with budgets, limits, owners, and an audit trail for every consequential action, while the other has an expensive pilot headed for someone’s cancellation statistics.

The difference is the management system around the model. That gets built slowly, mostly by people who have run organizations before.

If your newest agent went past its authority tomorrow, would anything in your company notice? And could you show an auditor, in writing, where the boundary was?