Agent Task Specifications
What exactly should the agent achieve, within which boundaries?
Reference notes by Min · Reviewed October 15, 2026
Definition
An agent task specification records the intended outcome, relevant inputs, constraints, authority and completion conditions for a particular delegated workflow.
Natural-language requests often omit assumptions that people would clarify in conversation. An agent may otherwise choose a convenient interpretation and act on it. A task specification makes the important assumptions explicit while leaving room for ordinary low-consequence choices.
What it covers
- Goal
- Describe the desired outcome in observable terms.
- Constraints
- Specify deadlines, spending limits, recipients and protected conditions.
- Authority
- Distinguish a requested outcome from permission to perform each action.
- Completion
- Define evidence of success and acceptable unresolved states.
Separate success from permitted means. Finding an available venue does not authorize a nonrefundable deposit. The specification should connect consequential actions to their actual approval conditions and identify decisions that remain with the requester or another accountable person.
In practice
Practical design patterns by Min.
- Clarify material ambiguity before consequential actions.
- Version changes to the task and reassess affected permissions.
- Provide an escalation route when constraints conflict or evidence is insufficient.
Track changes as the task evolves. If the workshop date moves, previously approved availability and pricing may no longer apply. Preserve the updated goal and affected constraints so another agent or human can continue without relying on an outdated conversational summary.
Research notes
Source-grounded details and editorial applications. Follow each link for the original document.
Requirements should remain traceable through change
NASA’s requirements-management guidance addresses managing requirements and their changes. Applying traceability to an agent’s evolving task is an editorial analogy, not a NASA-endorsed agent protocol.
Source: NASA Systems Engineering Handbook: Requirements Management ↗
Working example
Arrange a team workshop
An agent is asked to find a venue and prepare a booking.
- Record capacity, accessibility needs, budget and date constraints.
- Allow research and a draft recommendation while requiring approval for payment.
- Confirm booking from the venue’s response rather than the agent’s generated summary.
Why the controls matter
Completion evidence should come from the relevant system of record where possible. A generated message saying that a booking succeeded is weaker than a confirmed reservation identifier and agreed terms. If the external result is ambiguous, report a pending state and reconcile it.
Common pitfalls
- Treating an aspirational goal as unlimited authorization.
- Allowing a new instruction to silently invalidate earlier constraints.
- Using the agent’s own success statement as the only completion evidence.
Overly detailed specifications can still omit critical context. Give the agent a clear stop-and-clarify path for conflicts, unsupported requests and unexpected consequences. More prose alone does not solve ambiguity unless the execution system respects the resulting boundaries.
Questions for operational review
Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.
- What evidence proves completion?
- Which means remain outside the delegated authority?
- How are changed requirements carried into execution?
Articles linking here
References
Primary documents reviewed for this entry. Examples and implementation patterns are editorial synthesis.
- NASA Systems Engineering Handbook: Requirements Management ↗Accessed October 15, 2026
- NIST AI RMF: Core functions and subcategories ↗Accessed October 15, 2026