3.1.1. Task Agents
A task agent executes a defined, multi-step operation when triggered by a user or system event. It's the workhorse of enterprise automation — powerful enough to handle complex workflows, but scoped enough to remain predictable and governable.
Think of a task agent as a highly capable assistant who follows a detailed playbook. You hand them a task ("process this expense report"), and they execute the steps: extract data from the document, validate against company policy, check budget availability, route for approval, and notify the submitter. They don't decide whether to process the expense report — that's your call. They decide how to process it within the boundaries you've defined.
Design Characteristics:
| Characteristic | Task Agent Behavior |
|---|---|
| Initiation | Explicit trigger — user message, Dataverse event, scheduled time, Power Automate trigger |
| Duration | Runs until the task completes or times out |
| State | Maintains context throughout the task execution |
| Decision-making | Within-task decisions (routing, validation) — not strategic decisions |
| Human involvement | User initiates; agent may request clarification mid-task |
| Completion | Reports results back to the user or logs outcome |
When to Design a Task Agent:
- The business process has a clear start, defined steps, and a definable end state
- Users need to initiate the process explicitly (or a system event triggers it)
- The process involves multiple steps that benefit from AI reasoning (not just rule-based branching)
- The agent needs to interact with multiple systems during execution (CRM, ERP, email)
- Results must be reported back to the initiator
Design Best Practices:
- Define clear completion criteria — The agent must know when the task is done. "Process invoice" needs a specific definition of "processed" (data extracted, validated, routed, confirmed).
- Handle partial failures gracefully — If step 3 of 5 fails, what happens? The agent should report what succeeded, what failed, and what the user should do next.
- Set timeouts — Long-running tasks need maximum execution time limits. An agent stuck in an infinite retry loop wastes resources and frustrates users.
- Log actions for audit — Every action the agent takes should be traceable, especially for business processes with compliance requirements.
- Keep each task agent single-purpose. A read-only agent (for example, shipment tracking) should not be handed write access to absorb a new request such as changing a delivery address. Stand up a separate agent for the write operation, with explicit user confirmation before each change and audit logging, so each agent stays predictable and its permissions stay minimal.
- Set explicit scope and approval boundaries. Tier the agent's authority by impact — for example, auto-approve small expenses with policy-compliant receipts, route mid-range amounts to a manager, and escalate high-value or policy-exception items to a human — rather than approving everything or limiting the agent to data extraction.
- Treat residual exceptions as a business case. If 5% of items fall to manual review, first compare the cost of that review with the cost of raising accuracy — the last few points are the most expensive to win. Only if the improvement pays back does the question of how (a targeted rule fix, better data, a bigger model) come up.
Exam Trap: The exam may present a scenario requiring continuous monitoring (e.g., "watch for anomalies in transaction data") and offer "task agent" as an option. Task agents respond to triggers — they don't monitor continuously. That's an autonomous agent pattern.
Reflection Question: A procurement team wants an agent that, when a purchase order is approved, automatically checks vendor pricing, compares against contracted rates, and flags discrepancies. Is this a task agent or an autonomous agent? What's the trigger?
