Traditional project management defines done in terms of feature completeness: all requirements are implemented, all tests pass, and the system is deployed. This definition fails for agentic projects in three specific ways. First, feature completeness is ambiguous when the agent's behavior is emergent rather than explicitly programmed — the agent does not have features in the traditional sense. Second, all tests pass is a weak standard when the test suite cannot cover the range of inputs the agent will encounter in production. Third, deployed is not a final state for an agentic system because the model, the tools, the data, and the agent's effective performance all change over time. An agentic project is never done in the way a login feature is done.
A more productive definition of done for agentic projects has three levels. Deployment-ready means the agent meets its acceptance criteria on the evaluation set, the tool permissions are verified, the human review paths are operational, the observability infrastructure is in place, and the rollback procedure is documented and tested. This is the minimum bar for production access. Operationally stable means the agent has been running in production for a defined observation period, performance on live inputs matches the evaluation set within acceptable bounds, review escalation rates are within forecast, and the on-call team understands how to respond to the failure modes identified during development. Continuously improving means the team has an active eval improvement loop, is collecting reviewer feedback to identify new failure modes, and has a scheduled review cadence for the agent's performance metrics. Most projects hit deployment-ready and declare victory. The difference between a successful agentic deployment and a failed one is usually whether the team invested in the second and third levels.
Sprint planning for agentic projects should treat these three done levels as distinct milestones with explicit work items. The path to deployment-ready includes evaluation set construction, acceptance criteria definition, tool permission audit, review path design, and observability setup — none of which are engineering tasks alone. The path to operationally stable requires running the agent in production with a reduced scope or controlled rollout, monitoring performance against forecast, and conducting a structured retrospective on the gap between evaluation and live performance. The path to continuously improving requires product and engineering investment in the eval loop, which should be planned and resourced before the first deployment, not after the first failure.
What this means in practice
The practical implementation question is not whether the idea is interesting. It is how a team turns it into a workflow that can be inspected, repeated, and improved. For this topic, the operating focus is direct: Replace binary done definitions with a three-level framework that accounts for probabilistic behavior, ongoing performance changes, and the investment required to reach operational stability.
That means the engineering work starts before the first model call. The team must decide what the agent is allowed to know, what it is allowed to do, what evidence it must produce, and which actions require a human decision. This is the difference between an impressive demo and a system that can survive real users, changing inputs, and production constraints.
A credible implementation also includes a feedback path. Every agent run should leave behind enough context for another engineer to answer four questions: what goal was attempted, what context was used, which tools were called, and why the system believed the task was complete. If those questions cannot be answered from logs, traces, or structured outputs, the agent is still operating as a black box.
A simple architecture to reason from
Use this diagram as a starting point, not as a universal blueprint. The important move is to make the stages visible. Once stages are visible, you can assign owners, define contracts, set permissions, measure quality, and decide where human review belongs.
Acceptance criteria met, tool permissions verified, review paths live, rollback tested.
Live performance matches eval within bounds, escalation rates within forecast, on-call team trained.
Active eval loop, reviewer feedback collection, scheduled performance review cadence.
Three-level done checklist
The example below is intentionally small. Production agentic systems should start with compact contracts like this because small contracts are testable. Once the boundary is working, you can add richer orchestration without losing control of the core behavior.
const agenticDoneChecklist = {
deploymentReady: [
"acceptance_criteria_met_on_eval_set",
"tool_permissions_verified_against_approved_scope",
"human_review_paths_operational",
"observability_infrastructure_in_place",
"rollback_procedure_documented_and_tested",
],
operationallyStable: [
"agent_live_in_production_for_observation_period",
"live_performance_within_bounds_of_eval_set",
"review_escalation_rate_within_forecast",
"oncall_team_trained_on_failure_modes",
],
continuouslyImproving: [
"eval_improvement_loop_active",
"reviewer_feedback_collected_and_analyzed",
"scheduled_performance_review_cadence_established",
"improvement_velocity_documented",
],
};Implementation notes
Treat these notes as the first design review checklist. They are deliberately concrete because agentic systems fail most often in the gaps between the model, the tools, the data, and the human operating process.
Plan and resource the eval loop before the first deployment — not after the first failure.
Include all three done levels in sprint planning as distinct milestones with explicit work items.
The gap between deployment-ready and operationally stable is where most agentic projects fail.
Common failure modes
The fastest way to make an article useful is to name how the pattern breaks. These are the failure modes to watch for when a team moves from reading about this idea to deploying it inside a real workflow.
Operating checklist
Before this pattern graduates from experiment to production, require a short operating checklist. The checklist should include the owner of the workflow, the allowed tools, the risk rating for each tool, the data sources the agent can use, the completion criteria, the review path, and the rollback plan. If a team cannot fill out that checklist, the workflow is not ready for higher autonomy.
The checklist should also define how the system will be evaluated after launch. Useful metrics include task success rate, human correction rate, average iterations per completed task, cost per successful run, escalation rate, and the number of blocked tool calls. These metrics turn agent quality into an engineering conversation instead of an opinion about whether the output felt good.
Finally, make the learning loop explicit. When the agent fails, decide whether the fix belongs in the prompt, the retrieval layer, the tool contract, the permission model, the evaluation suite, or the human process. Mature agentic engineering is not the absence of failures. It is the ability to classify failures quickly and improve the system without expanding risk.
Build real fluency in agentic engineering.
The Academy turns these concepts into a full curriculum, AI tutor, templates, and the CAE credential path.