An AI Agent Needs a Job Description
We do not need to invent a new language of management for AI agents. We need to make the organisation we already have clear enough for both people and machines.
Imagine hiring a person on a Monday morning.
You show her to a desk, give her access to the company’s systems, and send one long message on Slack.
The message contains her title, her responsibilities, the company’s values, the rules for customer data, the procedure for complaints, the tone to use in emails, who she reports to, when she may make a decision on her own, and what she is to do on her first day.
On Tuesday, you send a new message. It is worded slightly differently. By Wednesday, you have forgotten half the rules, but still expect her to follow them. On Friday, you are frustrated that she did not understand the company culture.
No one would call that management.
Yet that is how many companies try to manage AI.
They take everything we have learned over more than a hundred years about organising human work, compress it into a system prompt, and hope the model can work out the rest. When it does not work, they write a longer prompt.
I think we have made the problem harder than it is.
An AI agent does not need a new philosophy of organisation. It needs a job description.
We have already invented the system
When a person joins an organisation, they do not encounter one giant instruction. They encounter several distinct layers, each with its own purpose.
The job description tells them what role they have. What they are responsible for. Which decisions they may make. Whom they work with, and whom they escalate to.
The staff policy sets out the shared rules and values that apply across roles. How we handle confidential information. What we do about conflicts of interest. Which conduct the organisation accepts, and which it does not.
A standard operating procedure — an SOP — explains how a specific piece of work is to be carried out. How an invoice is approved. How a complaint is handled. How a customer account is created. Which checks must be completed, and when a person must be brought into the process.
And then there is the specific task: Can you prepare the analysis for Thursday’s meeting?
The last of these is the prompt.
The prompt is not the job description. It is not the staff policy. It is not the SOP. It is simply the work that needs to be done now.
We do not give the agent a place in the organisation. We give it a block of text.
From chat window to employee
This was not a major problem when AI was primarily a chat window.
You asked a question. The model answered. The conversation ended. If the answer was wrong, you read through it and tried again. The AI had no enduring role, no rhythm of work of its own, and rarely access to anything beyond the text you entered yourself.
But that model is disappearing.
As I wrote in From Tool to Being, the decisive shift is not whether AI is conscious. It is whether it takes initiative. Agents keep running when we close the window. They remember. They monitor. They use tools. They discover tasks and act on them before a person has formulated a new prompt.
At that point, the role matters more than the message.
I have an agent of my own named Freja. If she were only a chat window, I could get by with explaining every task as it arose. But she works across projects, information, and time. So she needs to know what kinds of decisions she owns, what she may change, and what she must never do on my behalf.
She may organise, investigate, troubleshoot, and prepare. She may not send an external email, make an agreement, or promise anything on my behalf without an explicit yes.
That is not a prompt. It is a job description with a mandate.
The work on this text is itself an example. Freja was allowed to build an internal newsroom, create a branch, and make local commits. At the same time, she was expressly forbidden from pushing, publishing, deploying, or changing a schedule. The task was large and open-ended, but the boundary of her mandate was simple: she could create something I could consider. She could not make the decision public on my behalf.
That boundary mattered more than any instruction to “be careful”. It made the distinction between editorial work and publication part of the job.
And when she is to carry out a particular task — process an inbox, prepare a meeting, or investigate a content opportunity — she follows a procedure for precisely that work.
The interesting thing is that none of this requires a new vocabulary. We already know the words: role, responsibility, mandate, policy, procedure, escalation.
The gigantic system prompt
Even so, I see the system prompt being used as a kind of organisational junk drawer.
This is where we put the personality. This is where we put the safety rules. This is where we put the workflow. This is where we put the formatting requirements, the company history, the tone of voice, the exceptions, the previous mistakes, and a brief admonition never to hallucinate.
When the agent does something wrong, we add another section.
It resembles companies where every problem is solved with a new line in the employee handbook. Eventually the rule exists somewhere, but no one can see which rule applies to whom, or why it was introduced.
The problem is not the length. It is that different kinds of governance are mixed together.
A job description changes when the role changes. An SOP changes when the workflow improves. A shared policy changes when the organisation’s rules change. Today’s task changes all the time.
If everything lives in the same prompt, every change becomes risky. A small adjustment to the tone of an email can inadvertently change the agent’s understanding of its mandate. A new procedure can contradict an old rule 8,000 words further up. And when something goes wrong, it is difficult to determine whether the error lay in the role, the policy, the procedure, or the task.
Imagine a customer-service agent given the task: Close the complaint as quickly as possible. The job description says it must protect the customer relationship. The staff policy says vulnerable customers must be referred to a person. The procedure says amounts under 500 kroner may be refunded automatically. The customer demands 450 kroner back, but also writes that the bill means she cannot buy her medication.
Which text should prevail?
The policy should prevail. It has higher authority than the procedure, and today’s task has the lowest authority. The agent should refund the 450 kroner, stop the automatic processing, and pass the case to the person who owns the exception.
That requires more than four texts in a folder. Each layer needs an owner, a date, and a place in the hierarchy. The policy owns the shared boundaries. The job description owns the role and mandate. The SOP owns the repeatable workflow. The prompt owns only the current task. When two layers collide, the agent should not choose the best-worded sentence. It should follow the highest authority and make the conflict visible.
And some of this must be enforced outside language. If the agent may refund no more than 500 kroner, the system’s access control should block 501. If an external message requires approval, the send button must be technically locked — not merely surrounded by a kindly worded paragraph about caution. Logs must show which rule and which version underpinned the decision.
Text can describe the mandate. The system must enforce it.
AI as the organisation’s mirror
This is where it becomes interesting. And a little uncomfortable.
Many companies cannot give an agent a precise job description or a usable SOP. Not because the technology is new, but because the work has never been properly described.
The process lives with the employee everyone calls, but whom no one has made the official owner.
The mandate depends on who is asking.
The exceptions are passed on verbally and disappear when the wrong person is on holiday.
The staff policy says one thing, the actual culture does another, and the new employee learns the difference by making mistakes.
People are remarkably good at surviving organisations like that. We read faces. We hear hesitation in a colleague’s voice. We notice that a rule does not really apply to the CEO’s biggest customer. We piece together the real workplace through a thousand small social signals.
An agent cannot simply do the same. It operates according to the organisation we can make visible to it.
That is why the agent becomes a stress test of the company. Not only of its data and technology, but of its ability to explain itself.
If the company cannot describe who may make a decision, the problem is not primarily that the AI lacks context. The problem is that the mandate is unclear.
If no one can write down the procedure for a complaint case, the problem is not that the model lacks training. The problem is that the process is not shared knowledge.
If the values in the policy do not resemble the decisions leaders actually make, the problem is not alignment. The problem is the organisation’s own inconsistency.
AI does not necessarily create the mess. It makes it harder to hide.
That may be the most important difference between a person and an agent.
People quietly compensate for poor organisation. They ask a colleague, ignore the outdated procedure, and learn which rules apply only on paper. That ability keeps work moving, but it also conceals the cost of the ambiguity. Management sees the outcome, not the hundred small repairs employees make along the way.
The agent pulls the rug away. It follows the wrong rule consistently. It escalates too much or too little. It does exactly what it was told, and thereby reveals that the instruction was never enough.
It looks like a technical error. Sometimes it is an X-ray of the company.
The same company, different boundaries
The obvious response is to build a special layer for agents. An agent portal. A new taxonomy with new words for roles, rules, and workflows. I think that is the wrong direction.
If people and digital employees are to work in the same organisation, they should, wherever possible, use the same organisational infrastructure.
The same definition of customer service’s purpose.
The same rule for handling personal data.
The same procedure for a complaint.
The same definition of when a case must be escalated.
The difference lies in their mandate and capabilities. A person may be allowed to assess an exception where the agent must stop. The agent may review 10,000 documents in a night, while the person can understand the political consequences of what it finds. They need not have the same powers to work in the same company.
But the analogy has a limit. An agent can be copied in an instant. Its underlying model can be replaced overnight. Its memory is not experience in the human sense, but data with a particular authority and lifespan. It does not sense that the mood in a meeting has changed unless someone has made that signal legible. And whereas a person can be held morally and legally accountable, the agent’s responsibility is still borrowed from the people who gave it its mandate.
A job description does not make it human. It makes visible which person still owns the consequence.
The aim, then, is not to make people machine-readable or reduce all work to procedures. Nor is it to pretend that an agent is a person with a pension plan and feelings.
The aim is to avoid two parallel companies: one that people think they work in, and another that exists only in the agents’ prompts.
The objection: People are not procedures
There is a reasonable objection to this whole idea.
Human work functions precisely because it cannot be described completely. We use judgement. We improvise. We take considerations into account that no SOP could foresee. If we make the organisation machine-readable, do we not also risk making it mechanical?
Yes. If the ambition is to describe everything.
A good job description is not a complete simulation of a person. It says what responsibility the person has without specifying every single movement. A good procedure describes the repeatable work and the critical checks, but it also says when the procedure is not enough.
The latter is crucial.
A mature organisation is not one that has a rule for every situation. It is one that knows where the rules end, and who must then use their judgement.
For an agent, that means escalation is not a failure state. It is part of the job.
The agent should not imitate human judgement in secret. It should be able to say: This is where my mandate ends. Here is the evidence. Here is the conflict. Now a person must decide.
That does not make the organisation less human. It places human responsibility where it truly belongs.
Documentation is not an AI project
I can already hear the practical objection from the other side of the meeting table: Do we now have to document the whole company before we can use an agent?
No.
But you must describe the work you intend to delegate.
And that work should not be done only for AI’s sake.
A precise job description also helps the next human employee. An up-to-date SOP makes the company less dependent on Birgit’s memory. A clear escalation path reduces errors, whether the first assessment is made by a person or a model.
That may be the biggest overlooked benefit of putting agents to work: the technology forces the organisation to make its knowledge usable.
Not as a hundred PowerPoint slides about values. Not as an intranet no one has opened since 2019. But as living descriptions of roles, rules, and work that actually correspond to what people do.
If the documentation can only be understood by the agent, we have failed. If it can only be understood by the three people who already know the process, we have also failed.
It must be shared infrastructure.
We do not need a new language of management
The AI industry loves new terms. Copilots. Orchestrators. Multi-agent systems. Agentic workflows. Every new technical possibility arrives with its own language and its own sense that everything old is now irrelevant.
But companies do not primarily need more words. They need to connect this new capability to the organisation they already run.
An agent must know its job, the shared rules, and the procedure for the work it performs. It must know when today’s task falls outside its mandate. And it must have a person to turn to when reality does not fit the documentation.
That is not a revolutionary management model. It is simply sound, ordinary management.
Perhaps that is exactly the point.
We do not need to build a parallel bureaucracy for the machines. We need to make the organisation we already have clear enough that both people and digital employees can find their place in it.
What is new is not that we must learn a foreign language to manage machines.
What is new is that machines reveal how much human work has so far functioned because people have silently compensated for unclear management.
The agent is not hard to manage because it is mysterious. It is hard to manage because it takes our organisation more literally than we do.