Every AI agent needs a job description
Before an AI agent touches real work, define its owner, outcomes, authority, access, evaluation, and offboarding plan.
“We are starting to use AI agents across the company. What should we put in place before they touch real work?”
The short answer
Give every agent a job description.
Define the result it owns, the person accountable for it, the systems it can access, the actions it can take, and the conditions under which it must stop and ask for help. If those answers are unclear, the agent is not ready for production.
This is not about pretending software is an employee. It is a useful operating model. Companies already know how to define responsibilities, grant access, review performance, and remove access when a person changes roles. AI agents need the same clarity, expressed through architecture, policy, and automation.
The need is becoming urgent. Microsoft reported 15× year-over-year growth in active agents in its Microsoft 365 ecosystem. Its guidance to IT leaders is direct: treat agents as managed entities with identities, permissions, policy enforcement, and lifecycle management.
The prototype usually skips the management layer
Most agent pilots begin with a reasonable goal: reduce support backlog, research prospects, reconcile invoices, review code, or assemble a weekly report. The first demo works, so the team connects another data source and gives it another tool.
Before long, nobody can answer basic operating questions:
- Who is accountable when the agent makes the wrong decision?
- Which customer records, repositories, or cloud resources can it access?
- Can it only recommend an action, or can it execute one?
- What quality threshold must it meet, and how is that measured?
- How do we disable it, revoke its credentials, or replace its model safely?
That ambiguity is the AI version of an undocumented production system. It may produce value, but the business cannot reliably govern, scale, or explain it.
The five fields in an agent job description
| Field | Decision to document | What it produces |
|---|---|---|
| Mission and outcome | What business result does the agent support, and what is explicitly outside its role? | A bounded use case, success metric, and prohibited-use list. |
| Owner and escalation | Which human owns the result, reviews performance, and handles exceptions? | A named business owner, technical owner, and escalation path. |
| Authority | What may it recommend, draft, approve, or execute without human confirmation? | Approval thresholds, transaction limits, and a kill switch. |
| Identity and access | Which data and tools does it need, for how long, and on whose behalf does it act? | A unique identity, least-privileged permissions, and short-lived credentials. |
| Performance and lifecycle | How will quality, cost, drift, incidents, changes, and retirement be managed? | Evaluations, logs, review cadence, version history, and an offboarding checklist. |
The document can fit on one page. Its value comes from forcing a cross-functional decision before implementation quietly becomes policy.
A practical example: the support-triage agent
Imagine an agent that reads new support tickets, finds relevant account history, suggests a priority, and drafts a response. “Help the support team” is not a sufficient job description.
Mission. Reduce first-response time without lowering response quality or exposing customer data.
Authority. Classify and draft. A person must approve refunds, commitments, account changes, and outbound messages.
Access. Read only the ticket and relevant account history. No payment credentials or bulk customer export.
Quality bar. Measure correct routing, factual accuracy, policy compliance, acceptance rate, latency, and cost.
Now the engineering team can design a system around an explicit business contract. The agent gets a unique identity. Tool calls are logged. Sensitive actions require human approval. A test set measures expected behavior before a prompt, model, or workflow change reaches production.
Google describes the same security pattern in three principles: agents need well-defined human controllers, limited powers, and observable actions. These are not abstract ethics statements. They are architecture requirements.
The offboarding plan matters as much as onboarding
Agents change. Models are replaced, prompts are revised, connectors are added, and business processes move. An agent that was safe six months ago may now have broader access, a different risk profile, or no active owner.
A workable offboarding plan answers five questions:
- How is execution stopped? Disable schedules, event triggers, tool calls, and queued work.
- How is access removed? Revoke the agent identity, delegated access, API keys, and third-party tokens.
- What records remain? Retain the approved configuration, evaluation results, activity logs, incidents, and change history.
- Who owns unfinished work? Route open cases and exceptions to a named person or replacement workflow.
- How is retirement verified? Test that the agent can no longer access data or perform actions.
This follows the broader lifecycle approach in the NIST AI Risk Management Framework: define organizational roles, monitor systems after deployment, support override and incident response, and plan for decommissioning.
How this connects to the work I do
Founders rarely need another executive presentation about AI. They need help turning a promising experiment into a capability the company can operate. That is where my work as a Fractional CTO and software architect fits.
I work with leadership to choose the workflows where AI can create measurable business value, then make the operating decisions the demo avoided. We define ownership and human handoffs. We decide whether to buy, build, or integrate. We design the cloud architecture, identities, permissions, evaluation pipeline, deployment path, monitoring, and incident response around the real risk of the use case.
I also help the engineering team make those decisions repeatable. Agent definitions and prompts belong in version control. Material changes go through review and automated evaluation. Deployments leave a durable record. Access is periodically reviewed. The same system that operates the agent creates evidence for customer diligence, internal governance, and future SOC 2 work.
This is the throughline across my architecture, delivery, and leadership work: technology should make the business easier to run, easier to explain, and easier to scale. An AI agent with an undefined job does the opposite.
Do not start with an AI policy
A company-wide policy has value, but it cannot make an ambiguous workflow safe. Start with the first agent that touches meaningful data or takes meaningful action. Write its job description with the business owner, engineering lead, and security or compliance owner in the room.
If the team cannot agree on the outcome, authority, owner, access, and quality bar, that disagreement is not blocking the AI project. It is exposing the work the company must do before the project should scale.
An agent should never have more authority than the company can observe, evaluate, and revoke.
Give the agent a narrow job. Give a person clear accountability. Give the system its own identity and guardrails. Then expand its responsibilities only when the evidence shows that it is ready.