TASK: delegate bounded agent work
A TASK is a bounded assignment for known, defined work, derived from an approved PLAN and assigned with relevant context, scope, acceptance criteria and expected evidence. It gives an agent one reviewable responsibility instead of an open-ended instruction to build a feature.
TASK is the third Core phase of AI Architect Mastery's AI Driven Development Methodology. It connects the approved approach to bounded execution and verification.
Why one responsibility matters
Broad instructions make multi-file or multi-agent work difficult to review. One agent can change a contract while another still assumes the old behavior. A tightly scoped TASK makes the expected contract, permitted change and review boundary visible.
The goal is not simply a smaller prompt. It is enough context that the agent does not have to guess and enough constraint that it cannot quietly expand its own scope.
What a working TASK establishes
- The applicable approved PLAN step.
- Relevant files, interfaces, context and constraints.
- Expected outputs and acceptance criteria.
- Permitted scope and tools, plus an autonomy boundary: what the agent may decide and when it must stop or ask the human.
- The evidence needed to verify the result and support human review.
Inputs, output and responsibility
Input: one approved plan step and the context needed for it. Output: an authorized, bounded assignment. Owner: the human directs delegation and acceptance; the agent performs the assigned responsibility.
The handoff must make the current approved assignment explicit rather than relying on conversational memory. Confirm the relevant context, tools and permissions before execution; a written instruction cannot supply a missing verification environment.
Constructed TASK: one export correction
Apply the approved owner-only rule to the existing export handler using the established authorization helper. Preserve the public response format. Include owner-success, non-owner-denial and format regression evidence. Stop if the ownership policy or helper cannot support the agreed rule.
Example handoff E3: the illustrative human owner authorizes only P2 of approved example PLAN E2, based on PRD E1, after P1 confirms helper support. Edit only the handler and its directly related tests; do not change the shared-record policy or reporting architecture.
Required return: identify the revision, supply the diff and each actual check result with its environment, and list failures, unexecuted checks and limitations. Missing permissions or a test environment require a stop and report. This constructed authorization permits bounded implementation, not merge or deployment.
When the assignment is insufficient
If relevant context, permitted scope or verification is missing, return the assignment for clarification. A valid PRD and PLAN do not excuse an agent from working against an inadequate TASK. Refresh the handoff before continuing.
Related concepts
Watch the TASK methodology overview on YouTube (optional video; this text is the current reference).