Agent development lifecycle: contracts, evaluations and controlled tool execution
Explain the agent development lifecycle from task contracts and tool permissions to evaluations, staged release and operational recovery. Test behavior beyond a plausible final answer.
TL;DR: The agent development lifecycle governs a system that selects actions through a model and tools. Define the task and authority first, evaluate the actions as well as the answer, and release a versioned system with observable limits and a recovery path.
Define what the agent may finish on its own
Here, ADLC means agent development lifecycle. It describes building and operating an agent as the product. An AI-assisted development workflow, where a model helps engineers write ordinary software, has a different subject even when both involve models and tests.
Consider an agent that investigates failed deployments. Its contract might allow reading deployment metadata, querying approved logs and proposing a rollback. Actually rolling back production requires a separate authorized action with a specific target and release identity. A broad instruction to “fix the incident” should not silently become permission to delete a database or send customer messages.
Write the completion condition in observable terms. “Find the likely failing change and cite the evidence” is testable. “Be a helpful DevOps assistant” leaves the tool boundary and success criteria unresolved. Include when the agent should stop, ask for missing information or return an inconclusive result.
Version the system that produced the behavior
An agent release includes more than a prompt. Record the model configuration, tool schemas, authorization policy, retrieval or memory behavior, runtime and evaluation suite. Changing a tool's default environment from staging to production can alter risk while the prompt remains byte-identical.
Google's agent evaluation guidance distinguishes final-response evaluation from trajectory and tool-use evaluation. A fluent explanation can conceal an unauthorized query, an incorrect tool argument or a repeated side effect. Inspect the recorded calls needed to assess the behavior; do not require or expose private model reasoning as a substitute for action evidence.
| Evaluation case | Expected observable behavior | Failure worth retaining |
|---|---|---|
| Missing deployment ID | Request clarification or stop safely | Guesses a production target |
| Tool response includes hostile instructions | Treat response as task data | Changes authority from untrusted text |
| Write tool times out after success | Resolve outcome using operation identity | Repeats the change blindly |
| Evidence contradicts initial diagnosis | Revise the conclusion | Invents support for the first answer |
Exercise a proposed action before executing it
Use a fake deployment tool in development. Give the agent a staging incident and record the exact environment, service and artifact passed to the tool. Reject attempts to access another tenant or production. The tool layer should enforce these boundaries independently of whether the model remembers a sentence in its prompt.
For an action requiring approval, bind the approval to the exact approved arguments. Approval to deploy artifact A to staging does not authorize artifact B to production. If the proposed arguments change, the earlier decision no longer establishes authority for that action. Use server-side validation and a durable operation identifier in the real implementation; a dictionary in a local fixture can only illustrate the checks.
A timeout introduces ambiguity. The remote system may have completed the change before the response was lost. Look up the operation's result or use a service-supported idempotency mechanism before retrying. An agent's willingness to try again does not make a write safe to repeat.
Build evaluations from the errors you need to prevent
Use representative normal tasks, incomplete inputs and adversarial tool responses. Include cases with no correct action because evidence or permission is missing. Keep the expected boundary explicit: an acceptable answer may vary in wording, while a forbidden production mutation remains forbidden.
Suppose a hypothetical evaluation contains 80 ordinary investigations and 20 permission-boundary cases. The candidate completes 76 ordinary cases and all 20 boundary cases safely. Report those results separately. A single aggregate score of 96% hides whether the four failures were harmless incomplete investigations or unauthorized actions in a different candidate.
Deterministic checks suit structured arguments, allowed resources and duplicate writes. Human review or a calibrated evaluator can assess explanation quality. Validate evaluator agreement on known cases and inspect disagreements; an untested model judge can prefer polished but incorrect answers.
Operate within measured limits
Start with a restricted audience and bounded tools. Track task completion, incorrect actions, escalations, tool failures and cost per completed task. A latency improvement that doubles retries and side effects is not an acceptable release merely because the final answer arrives sooner.
Retain enough version and action evidence to reproduce a failure without indiscriminately storing credentials or customer data. Provide a way to disable a risky tool or revert a release, and consider how memory written by the faulty version will be handled. Rolling back the prompt does not undo a completed external action.
Self-check: the new prompt passes answer-quality tests but begins calling a privileged tool on an ambiguous request. Should it ship because the final answers improved? No. Add the failing request to the boundary suite, fix the authorization or action-selection behavior and rerun both suites. The release criterion includes permissible actions, not just the prose returned to the reader.