Strategy · 5 minute read
Digital FTE Job Description Template for AI Agent Roles
A Digital FTE job description defines an AI agent as a role: purpose, scope and non-scope, inputs and outputs, decision rules and prohibited actions, tools and permissions, quality bar, escalation gates, human owner, autonomy level, and cost budget. It is written first, because it is the specification the agent is built and measured against.
Organizations that get value from AI agents share a habit: before building anything, they write down the role. Not a prompt, not a ticket, but a job description that a process owner could hand to a new hire, with the additional precision an agent needs. If a section cannot be filled in, the work is not ready to delegate, and discovering that on paper is far cheaper than discovering it in production.
This is the template FISTA Solutions uses for Digital FTEs, with guidance on each section. It applies the role model from what is a Digital FTE and pairs with the engineering-side AI agent specification template.
What does the template contain?
| Section | Question it answers | Owner |
|---|---|---|
| Role title and purpose | What is this role for, in one paragraph? | Process owner |
| Scope and non-scope | Which cases are in, which are explicitly out? | Process owner |
| Inputs and outputs | What does it receive, what does it produce, in what form? | Process owner + engineering |
| Decision rules | How does it decide, with thresholds and exception categories? | Process owner |
| Prohibited actions | What must it never do? | Process owner + security |
| Tools and permissions | Which systems, which actions, classified by consequence | Engineering + security |
| Quality bar and evaluation | What does correct mean, and how is it measured? | Process owner + engineering |
| Escalation and approval gates | When does it stop, who decides, with what context? | Process owner |
| Autonomy level | Suggest, act with approval, or act with sampling, and the evidence to advance | Process owner |
| Owner and reviewers | Who is accountable, who handles exceptions | Operations leadership |
| Cost budget | Run cost, oversight allowance, and limits | Finance + owner |
| Review cadence | When the description and performance are reviewed | Operations leadership |
How should each section be written?
Role title and purpose
Name the role the way you would name a job: "Invoice Matching Specialist," "Tier-One Support Resolver," "Access Request Fulfiller." State the purpose in one paragraph: the workflow, the outcome, and why it matters. Avoid technology words; the purpose is about the work.
Scope and non-scope
List the case types the role handles and, with equal care, the case types it does not. Non-scope is a control: it is where the agent stops. "Handles invoices with a matching purchase order; does not handle invoices without a purchase order, credit notes, or intercompany invoices" is a scope statement an engineer can enforce.
Inputs and outputs
Describe what arrives (documents, records, messages, their sources and formats) and what the role produces (records created or updated, messages sent, recommendations made) precisely enough to write schemas.
Decision rules
This is the heart of the description. Write the rules as a person would need them on their first day: thresholds, tolerances, sequences, and the exception categories with what happens in each. The test is whether two readers would resolve the same case identically. Rules that need "judgment" mark steps that stay with people. The discipline is described in spec-driven development explained.
Prohibited actions
State what the role must never do, regardless of instruction: never change vendor bank details, never post above a threshold, never send external communications, never access records outside the assigned population. These become permission boundaries, not just prompt text.
Tools and permissions
| Tool | Action | Classification | Permission |
|---|---|---|---|
| ERP | Read invoice and purchase order | Read | Read-only principal, assigned entities |
| ERP | Create match proposal | Reversible write | Scoped principal |
| ERP | Post invoice | Consequential write | Withheld; human gate |
| Send vendor query | Reversible write | Template-only, internal review sample |
The classification drives the approval design and follows the model in the agent identity and access control whitepaper.
Quality bar and evaluation
State the measurable standard: accuracy against the golden dataset by category, false-exception rate, and the production sampling rate. "Accurate" is not a quality bar; "matches correctly on at least the agreed threshold of the golden dataset in every category, with zero prohibited actions" is. The evaluation approach is in the evaluation-driven development whitepaper.
Escalation and approval gates
Define the triggers (low confidence, out-of-scope case, prohibited request, consequential action) and the handoff: who receives it, with what context, within what time.
Autonomy level and evidence to advance
Record the current level and the evidence required to move up: agreement rate with humans, override rate, incident-free period, sampled quality. Advancing is an owner decision made with data, as described in Digital FTE performance review.
Owner, reviewers, budget, cadence
Name the accountable owner and the exception handlers. Set the cost budget with finance using the components in Digital FTE cost. Set the review cadence, usually quarterly, aligned with the performance review.
What does a completed example look like in outline?
Role: Access Request Fulfiller. Purpose: fulfill standard software and system access requests from intake to confirmation, within policy, so the service desk handles only exceptions. Scope: catalog items with pre-approved workflows; non-scope: privileged access, non-catalog requests. Rules: eligibility by role and policy table; approval routing per delegation matrix; provisioning only through the identity platform. Prohibited: never grant privileged roles, never bypass approval. Quality bar: correct eligibility and routing on the golden set in every category; zero prohibited grants. Escalation: any non-catalog or ambiguous request to the desk with context. Autonomy: act with approval; advance to sampling after the agreed evidence period. Owner: service desk lead. Budget: set per quarter with IT finance.
What are the common mistakes?
- Duties without non-scope. The agent has no boundary.
- Adjectives as quality bars. Nothing is measurable.
- Tools listed without classification. Approval gates cannot be designed.
- No owner. Accountability floats to engineering by default.
- Written once, never reviewed. The description drifts from the deployed reality.
How does FISTA Solutions help?
FISTA Solutions writes Digital FTE job descriptions with process owners as the first step of every AI agents engagement, through forward deployed engineers who sit with the people doing the work today, and its AI enablement practice installs the template and review cadence across teams. FISTA has delivered 150+ projects for 50+ companies across 12+ countries.
To draft a role with us, message FISTA on WhatsApp, or continue with how to onboard a Digital FTE.
Share-ready article cover
Download the generated social format.
Clear answers
Questions raised by this field note.
Straightforward guidance for evaluating scope, fit, and the next step.
01Why does an AI agent need a job description?
Because a job description is the management artifact that makes a role plannable, ownable, and reviewable. For an agent it doubles as the specification engineers build against and the standard evaluation measures against. Without it, the agent's behavior is whatever the prompt happened to produce, and nobody can say whether it is doing its job.
02Who writes a Digital FTE job description?
The process owner writes the purpose, scope, decision rules, quality bar, and escalation rules, because they define what correct looks like. Engineering writes the tools, permissions, and evaluation sections and challenges anything that cannot be specified precisely. Security and risk review permissions and prohibited actions before launch.
03How detailed should the decision rules be?
Detailed enough that two people reading them would resolve the same case the same way, and that an engineer can turn them into test cases. Vague rules such as use judgment mean the step belongs to a person. Write the rules, the thresholds, the exception categories, and what happens in each.
04How is the template different from a software specification?
It covers the same technical content, inputs, outputs, rules, tools, and tests, but frames it as a role with an owner, an autonomy level, a cost budget, and a performance review, so that operations and finance can manage the agent alongside human headcount rather than treating it as an IT project.
Continue exploring
Related capabilities
Start with the hard problem
Need the outcome owned, not merely analyzed?
Tell us where delivery is constrained. We’ll map the fastest credible path from intent to verified production.