May 15, 2026 · 5 min read
AI agents need job design more than bigger models
Enterprise AI agents need clear roles, permissions, approvals, handoffs, observability, and ownership before they can responsibly take action in real workflows.
A lot of the conversation around AI agents still starts with the model.
Which model is smarter? Which benchmark improved? Which tool can reason longer, code faster, or use more context?
Those things matter.
But in enterprise work, I think a different question is becoming more important:
What is the agent’s job?
Not its prompt. Not its demo. Not its theoretical capability. Its actual job.
What work is it responsible for? What inputs does it receive? What systems can it touch? What decisions can it make? What actions require approval? What happens when it is uncertain? Who reviews its output? Who owns the result? How do we know if it made the workflow better?
That is job design.
And most AI agent projects do not spend enough time there.
The model is not the role
A more capable model can make an agent more useful.
But capability does not automatically create accountability.
If a human joins a company, we do not say, “This person is intelligent, so let’s give them access to everything and see what happens.”
We define a role. We decide what they own. We define permissions. We explain what good work looks like. We set escalation paths. We decide what requires review. We measure whether the role is helping the business.
AI agents need the same kind of thinking.
The fact that an agent can summarize, search, draft, classify, call tools, update systems, or trigger workflows does not mean it should do all of those things without boundaries.
The useful question is not only: “Can the agent do this?”
It is: “Should this agent be allowed to do this, in this workflow, under these conditions, with this level of oversight?”
The missing middle: ownership, permissions, and handoffs
Many agent demos look impressive because they skip the messy middle of real work.
A demo usually shows the happy path: the input is clean, the goal is clear, the tool calls work, the output looks reasonable, and no one asks who is accountable if something goes wrong.
Production work is different.
The hard questions show up quickly:
- Who owns the agent after launch?
- What data is it allowed to use?
- What tools can it call?
- What action is it allowed to take on its own?
- Where does human approval belong?
- How are exceptions handled?
- What logs are reviewed?
- When should the agent stop instead of continuing?
- What metric proves the workflow improved?
Without those answers, the organization does not really have an agent.
It has an experiment with credentials.
That may be fine in a sandbox.
It is risky in a business process.
Agents should have job descriptions
One practical exercise I like is writing a job description for the agent before building it.
For example:
Agent role: Intake assistant for support tickets
Primary responsibility: Read new tickets, classify intent, gather missing context, suggest routing, and draft first-response options.
Allowed actions:
- read incoming ticket text
- search approved knowledge sources
- classify urgency and category
- suggest routing
- draft a response for human review
Not allowed:
- close tickets automatically
- promise refunds or credits
- change customer account settings
- message customers without approval
- use unapproved knowledge sources
Escalation rules:
- send billing issues to a human
- flag legal/compliance language
- stop if confidence is low
- escalate if customer sentiment is severe
Success measures:
- faster triage time
- fewer misrouted tickets
- better first-response quality
- lower support backlog
- no increase in compliance exceptions
That kind of clarity changes the build.
It changes the prompt. It changes the tools. It changes the permissions. It changes the approval flow. It changes the evaluation.
Most importantly, it changes the conversation from “look what the model can do” to “here is the work this agent is responsible for, and here is how we know it is doing that work safely.”
Bigger models will not fix unclear work
If the workflow is badly defined, a better model may only make the confusion faster.
It may generate more polished outputs for a process nobody owns. It may automate steps that should have been redesigned first. It may create the appearance of progress while adding hidden review work downstream. It may expand risk because the agent has access without accountability.
This is why I think agent design needs to borrow more from operating model design, org design, and process engineering.
The model is part of the system.
But the system also includes workflow ownership, permissions, approval gates, exception paths, observability, evaluation, lifecycle management, and human accountability.
That is where trust gets built.
The practical shift
The next phase of enterprise AI will not be won by companies that simply deploy the most agents.
It will be won by companies that know what their agents are for.
Agents with clear jobs. Agents with bounded authority. Agents with measurable outcomes. Agents with escalation paths. Agents with owners. Agents that make a workflow better instead of just making a demo look smarter.
The model still matters.
But the job design may matter more.
Because once an AI agent can take action inside a real workflow, the question is no longer just intelligence.
It is responsibility.
Need this in your workflow?