An AI Agent Needs a Job Description Before It Needs More Tools
An AI agent does not become useful because it has access to more tools. It becomes useful when it has a clear responsibility, knows which requests belong to that responsibility, and can complete those requests within explicit boundaries. That design work appears directly in the current AB-620 exam, which emphasizes planning agent solutions before extending them, and the same architecture discipline appears across Microsoft certifications that cover production AI and application delivery.
Before adding connectors, APIs, knowledge sources, child agents, or computer-use capabilities, write the agent’s job description. The exercise sounds simple, but it forces decisions about users, outcomes, authority, data, escalation, and success. Those decisions are the architecture.
Define the outcome in business language
“Answer employee questions” is too broad. “Help employees understand travel policy and submit a complete travel request” describes an outcome and a boundary. It also reveals that the agent may need two different capability types: read-only knowledge for policy questions and an authenticated action for request submission.
The same analysis used in a business systems analyst role is valuable here. Start from the process and the decision the business needs, not from the platform feature list.
Name the users and the context they bring
An internal employee, external customer, partner, and administrator may ask similar questions but have different identity, data, and compliance requirements. Define the intended audience and channel before deciding how the agent authenticates or which knowledge it can use.
Context also includes what the agent may assume. An HR agent can reasonably know it serves employees, but it should not infer a user’s employment status, region, or authority if those facts determine access. Important context should come from identity, explicit inputs, or trusted systems.
Separate what the agent should know from what it should do
Knowledge sources support answers. Tools and flows change the world. Treat those as distinct architectural responsibilities. An agent might read a benefits policy from SharePoint, retrieve an employee’s current enrollment from a system of record, and submit a change through an authenticated action. Each step has a different risk profile.
This distinction matters because a hallucinated answer is a quality problem, while a hallucinated action can become a business incident. The job description should state which outcomes are informational and which are transactional.
Write non-goals as deliberately as goals
An agent needs a refusal boundary. A procurement agent might create draft requests but not approve spend. A support agent might reset a password but not change a user’s security role. A sales agent might summarize account history but not make contractual commitments.
Clear non-goals reduce tool-selection ambiguity and simplify testing. They also connect to the broader design of intelligent-agent behavior: performance is meaningful only when the environment, actions, and success criteria are defined.
Define the minimum toolset that can complete the job
Once the job is clear, tools become easier to evaluate. Add a capability because a required outcome cannot be completed without it—not because the connector is available. Every tool increases the agent’s possible action space, permission surface, failure modes, and testing burden.
A narrow agent with three well-described tools can be more reliable than one with thirty overlapping tools. The orchestrator has fewer ambiguous choices, descriptions can be more precise, and operators can reason about what the agent is capable of doing.
Decide where human approval belongs
The current AB-620 scope explicitly includes human-in-the-loop agent flows. Approval is not an admission that the agent is weak. It is a control for actions whose impact, uncertainty, or policy significance requires a person to confirm intent.
Good approval points are placed before irreversible or high-cost actions, not after them. The agent should prepare the evidence a reviewer needs—what it plans to do, for whom, with which inputs, and why—so the human is making a real decision rather than clicking an unexplained confirmation button.
Turn success into measurable behavior
“The agent is helpful” cannot be tested. Better criteria include task completion rate, answer groundedness, correct tool selection, escalation rate, action failure rate, user correction frequency, or time saved for a defined workflow. The metrics should reflect the job description.
This is where agile requirement practice is useful: define observable acceptance conditions, then learn from real outcomes. Agent behavior is probabilistic, so testing needs representative sets of requests rather than one perfect demo conversation.
Make ownership part of the design
Every production agent needs owners for its instructions, tools, knowledge, permissions, evaluation sets, and incident response. Those responsibilities may span business teams, Power Platform administrators, security teams, and developers. Without named ownership, stale knowledge and broken integrations accumulate quietly.
Current Microsoft guidance also treats application lifecycle management as part of the AB-620 skill set. That is appropriate: an agent is not a one-time prompt. It is a managed application with environments, configuration, releases, testing, monitoring, and change control.
Add intelligence only after the operating contract is clear
Agentic AI can adapt, plan, and compose tools in ways traditional workflow automation cannot. That flexibility is most valuable when it operates inside a clear contract. The broader trend described in agentic AI for business systems does not remove the need for requirements; it increases the value of precise objectives and boundaries.
A practical job description can be written as a one-page operating contract. Include the audience, primary outcomes, information sources, actions, prohibited actions, escalation triggers, and owner. Add examples of requests that belong and examples that do not. This artifact becomes useful far beyond design: security reviewers can evaluate permissions, testers can build representative prompts, and support teams can understand whether a reported behavior is actually a defect.
Risk classification should be attached to outcomes rather than to the agent as a whole. The same agent may answer low-risk policy questions and perform a high-risk account change. Those paths deserve different authentication, approval, logging, and evaluation requirements. Treating the entire agent as “low risk” or “high risk” hides the variation that matters most.
Channels also change the job. An agent used inside Teams with authenticated employees has different assumptions from one embedded on a public website. The job description should state where the agent is expected to run and whether each channel provides trusted identity. A capability that is appropriate in one channel may need to be disabled or gated behind sign-in in another.
Latency and cost are part of the operating contract too. A conversational lookup may need to return in a few seconds, while a multi-step research task can tolerate longer execution. If the agent routinely invokes many expensive tools or models for a simple request, the architecture is mismatched to the job. Define what “fast enough” and “worth the cost” mean for the workflow.
Escalation should specify a destination and payload. “Hand off to a human” is incomplete if the human receives no summary, evidence, or action history. A good escalation includes what the user asked, what the agent already tried, which data was retrieved, and why the agent stopped. That prevents the user from repeating the entire interaction and gives the reviewer enough context to continue safely.
The job description should evolve through evaluation. If test sets repeatedly show that users ask a closely related task, decide whether to expand the role deliberately or make the refusal clearer. Do not let capability creep happen accidentally because a new tool was easy to add. Every expansion should update permissions, tests, documentation, and ownership together.
Versioning matters because agent behavior can change when instructions, tools, knowledge, connected agents, or models change. Release notes should identify which part of the operating contract changed and which test cases protect it. That discipline makes the agent easier to govern and gives teams a way to roll back when a new capability causes unexpected planning behavior.
Data retention and privacy should appear in the job description as well. If the agent handles employee, customer, or regulated information, define which data may enter conversation context, which may be stored in logs, and how long operational traces are retained. A capability that technically works may still violate the intended role if it exposes more information than the business process requires.
Finally, write down the conditions under which the agent should stop. Repeated tool failures, conflicting source data, missing authorization, or low-confidence interpretation may require escalation rather than another planning attempt. A strong job description includes exit criteria because responsible autonomy depends on knowing when not to continue.
Ownership should include a periodic capability review. Compare the agent’s actual tools, knowledge sources, channels, and connected agents with the job description. Remove capabilities that no longer serve the defined outcomes and investigate commonly used capabilities that were never documented. This review keeps the technical implementation aligned with the business role instead of letting experiments quietly become permanent production authority.
An AI agent therefore needs a job description before it needs more tools. Define the work, audience, authority, data, non-goals, approval points, and measures of success first. Then every knowledge source and tool can be justified against a concrete responsibility instead of turning the agent into a collection of capabilities looking for a problem.