Most conversations about AI agents start in the wrong place.
They start with the model.
Which model is smartest? Which one is fastest? Which one can reason longer, write better, browse the web, use tools, or remember more context?
Those questions matter, but they are not the whole design problem.
In real work, the more useful question is not:
What can this AI do?
It is:
What job does this AI have?
That sounds like a small shift. It is not.
When people say an AI "has a job," they often mean it can complete tasks: gather research, triage messages, inspect code, write drafts, summarize meetings, or monitor a queue.
But a job is more than a task.
A real job has boundaries, inputs, tools, authority, expectations, escalation paths, and things the person should not do even if they technically could.
The same is true for useful AI systems.
The unit that matters is not an abstract helper floating around with general capability. The useful unit is a role.
The Role Creates the Boundary
The first thing a defined role gives an AI system is a boundary.
Without a boundary, the system has to infer too much. It has to guess what matters, what it is allowed to touch, what quality bar applies, and when to stop.
That is why broad prompts like "be helpful" are not enough for serious work.
"Be helpful" might be fine for conversation. It is weak for operations.
A research role has different limits from inbox triage. Code review differs from direct coding. Documentation differs from customer support.
They may use the same underlying model, but they should not behave the same way.
One role might compare sources and produce a cited brief. Another might label messages, draft replies, and flag anything sensitive for a person. A third might inspect a pull request and recommend changes without touching the merge button. A fourth might turn tickets and commits into a draft guide that still needs approval before publishing.
The role tells the system what kind of work it is doing.
It also tells the system what kind of work it is not doing.
That second part matters more than people think.
Inputs Decide What the Job Can See
Every job starts with inputs.
For a human, the input might be a ticket queue, a codebase, an inbox, a spreadsheet, a meeting transcript, a support case, or a project brief.
For an AI system, the input is just as important.
If the system is reviewing code, it needs the actual diff and enough repository context to judge it. If it is triaging messages, it needs the sender, prior context, and maybe calendar or customer data. If it is writing release notes, it needs the source material it should trust.
The job cannot be better than the information it is allowed to inspect.
This is one reason agent demos can be misleading. A demo often gives the AI a clean prompt, a narrow task, and an obvious success condition.
Real work is messier.
The source might be stale. The ticket might be vague. The docs might conflict. The spreadsheet might have hidden assumptions. The user may have asked for an outcome but skipped the constraint that actually matters.
A well-designed role needs rules for input quality:
- What sources should it use?
- Which sources are authoritative?
- How fresh do they need to be?
- What should it do when sources conflict?
- What missing information should cause it to ask a question?
Without those rules, the system will often do what language models are good at: produce the most plausible continuation.
That may look like work.
It may not be the work that was actually assigned.
Tools Define Reach
Inputs define what the system can see.
Tools define what it can do.
This is where the word "agent" becomes practical. It is not just a chatbot with a more ambitious prompt. It is software that can use tools: search, files, calendars, databases, code execution, issue trackers, email, documents, deployment systems, or internal APIs.
Tools are what turn language into action.
They also create risk.
An AI that can summarize an inbox is useful. An AI that can send email is more powerful. An AI that can delete email, change billing data, grant access, deploy code, or message customers is in a different category.
The job should decide which tools are available and under what conditions.
For example, a code-review role can have read access to the repository, test output, pull request metadata, and issue history. It can leave review comments. It should not merge by default.
An inbox triage role can label messages and draft replies. It needs approval before sending. It should never send messages involving legal, financial, medical, or sensitive personal information.
A research role can browse the web and save notes. It should cite sources and distinguish between what it found, what it inferred, and what remains uncertain.
The tool list is not a technical afterthought.
It is part of the job description.
Authority Is Different From Ability
One of the most important distinctions in AI design is the difference between what a system can do and what it is authorized to do.
A model may be capable of drafting a customer response.
That does not mean it should send it.
A coding assistant may be capable of modifying code.
That does not mean it should commit directly to the main branch.
A system may be capable of reading a folder full of documents.
That does not mean every document in the folder should be treated as relevant, current, or safe to follow.
Authority is the permission layer around capability.
In human organizations, this is normal. A junior employee may be able to write a refund email, but not approve a large refund. An engineer may be able to edit production code, but the process may require review, tests, and deployment gates. A support rep may have access to customer records, but still needs policy boundaries.
AI systems need the same separation.
Authority should be explicit:
- Can the system only recommend?
- Can it draft?
- Can it edit?
- Can it take action after approval?
- Can it take low-risk actions automatically?
- Which actions are never allowed?
This is where many autonomy claims get too vague.
Autonomy is not a single switch.
It is a set of permissions attached to a specific responsibility.
Review Points Make the Job Trustworthy
If an AI role has tools and authority, it also needs review points.
Human approval is not a sign that the system is weak. It is how the system becomes usable in higher-stakes work.
The key is to put approval at the right moments.
Approving every tiny step makes the workflow exhausting. Approving nothing makes it unsafe.
Good gate design depends on the work.
For research, the gate might be the final brief. The user wants to inspect the sources, the summary, and the uncertainty.
For code review, the gate might be pull request comments. The system can surface risks, but a human decides what matters before merge.
For inbox triage, approval might be required before sending a reply, but not before applying a low-risk label.
For documentation, approval might be required before publishing externally, but not before saving a draft.
The pattern is simple:
Low-risk, reversible steps can often be automatic.
High-impact, irreversible, public, financial, private, or production-facing steps should require a gate.
The system should make those gates visible instead of hiding them behind confidence.
Failure Behavior Is Part of the Role
A role description is incomplete if it only defines success.
It also needs to define failure behavior.
What should the system do when it cannot find the source? What if the inputs conflict? What if the requested action is outside its authority? What if a tool fails? What if the task is taking too long? What if the user asks for something risky?
These are not edge cases.
They are daily reality for useful systems.
A weak system improvises. It keeps trying, guesses, loops, or gives a polished answer that hides the missing piece.
A stronger one has a known failure mode.
It can say:
- I do not have the source needed to answer this.
- These two documents conflict.
- I can draft this, but I cannot send it without approval.
- The tool failed, so I stopped instead of pretending the action completed.
- This request is outside my role.
- I found a likely answer, but the evidence is not strong enough for the decision you are asking for.
That kind of failure behavior may sound less impressive than a fully autonomous demo.
In practice, it is much more useful.
Systems earn trust when their failure is legible.
The Job Should Have a Stop Condition
Another underrated part of a defined role is knowing when it is done.
Many agent failures are not dramatic. They are just vague.
The system keeps researching because it does not know what "enough" means. It keeps editing because there is no quality bar. It keeps trying tools because a task failed and no stop rule exists. It produces a long answer because it was never told what output would be useful.
A real job needs a stop condition.
For research, the stop condition might be a short brief with cited sources, open questions, and a recommendation.
For code review, it might be a prioritized list of findings with file references and test gaps.
For inbox triage, it might be a set of labels, draft replies, and escalations.
For documentation, it might be a draft page that matches a template and identifies anything that still needs human confirmation.
The stop condition keeps activity from being mistaken for completion.
It also makes evaluation possible.
You cannot evaluate the work clearly if you have not defined what good completion looks like.
The Practical Template
If you want to make an AI system useful, describe the role before arguing about the model.
A practical definition looks like this:
Role: What work is this system responsible for?
Inputs: What information should it inspect?
Sources of truth: Which sources govern the answer when context conflicts?
Tools: What systems can it use?
Authority: What can it recommend, draft, edit, or execute?
Review points: Which steps need human approval?
Failure behavior: What should it do when context, tools, or permission are missing?
Stop condition: What output means the job is complete?
That template is not glamorous, but it is the difference between a toy demo and an operational system.
The model still matters. Better models can handle more ambiguity, follow instructions more reliably, use tools more effectively, and explain uncertainty more clearly.
But a better model inside a vague role is still a vague system.
The future of AI work will not be one general assistant doing everything with unlimited authority.
It will be many bounded systems with specific responsibilities: investigate this claim, inspect that pull request, triage these messages, monitor this queue, prepare this decision, draft this update.
The value will come from giving each system the right context, the right tools, the right authority, and the right limits.
That is what it means for AI to have a job.
Not that it can do anything.
That it knows what work it owns, what it can touch, when it should ask, when it should stop, and what a good handoff looks like.
