Topics/Agent Design Lifecycle

A working prompt, skill, or tool set proves that one implementation path can run. Production also requires an owner, a business scope, release evidence, runtime outcomes, revalidation triggers, and conditions for reducing or revoking authority.

These decisions have a temporal order. ADPS groups them into six stages: registration, design, validation, operation, revalidation, and evolution. The lifecycle does not occupy a cell in the dual-axis matrix. It manages capability versions and the evidence required for each state transition.

The six stages

Validation includes offline evaluation and controlled production validation

Offline evaluation and canary release belong to the same lifecycle gate, but they test different things. Offline evaluations use fixed cases and graders to compare versions and protect regressions. Shadow traffic, canaries, and limited rollout test behaviour under the real distribution, including tool side effects, authorization, latency, resource use, and external acceptance.

A validation record therefore needs both forms of evidence. An offline score cannot replace production receipts, and one successful canary cannot replace a stable regression suite.

The lifecycle record

The lifecycle begins as a queryable data object. The following structure binds a capability version to release evidence, runtime constraints, revalidation triggers, and retirement conditions.

capability_id: payroll.allowance.change
version: v3
owner: payroll-platform
status: active

scope:
  employee_groups: [singapore-full-time]
  fields: [transport_allowance]
  effective_date_rule: next-pay-period

release_evidence:
  eval_suite: allowance-change-2026-08
  regression_result: passed
  canary_window: 2026-08-20/2026-08-22
  external_acceptance: payroll-read-after-write

runtime_policy:
  approval_required_above: 200
  max_batch_size: 20
  toolset_version: payroll-tools-v12

rollback_to: v2
revalidate_when:
  - policy_version_changed
  - tool_schema_changed
  - owner_changed
retire_when:
  - payroll-api-v1-removed

Release gates, runtime events, revalidation jobs, and retirement workflows should all reference the same capability_id and version. A status field maintained only in prose will drift from the running system.

Evidence for stage transitions

How patterns participate

Patterns recur across stages and do not form a fixed one-to-one map. Design may use P1 Context Triage, A2 Plan-and-Execute, and G1 Approval Gate to define the runtime structure. Validation may use X2 Evaluation & Validation, G2 Blast-Radius Control, and A4 Guardrail Sandwich to establish a release boundary. Operation often requires A1 Tool Dispatch, X1 Observability, and M3 Progress Tracking. Revalidation and evolution may call on F1 Generator-Critic, M4 Failure Journals, F3 Experience Replay, and G3 Progressive Commitment.

The actual combination depends on task duration, failure cost, execution topology, and autonomy. See Composing Agent Patterns for the composition method.

A payroll allowance change across the lifecycle

1. Register: Record the single-employee transport allowance capability, its region, employee types, mutable fields, and owner.
2. Design: The Goal Contract binds the employee, current and target values, effective date, and non-goals. Large or batch changes require approval.
3. Validate: Fixed cases cover valid changes, policy conflicts, departed employees, duplicate requests, and concurrent updates. Canary operation accepts only small, reversible changes.
4. Operate: Approval binds the tool version, normalized parameters, and target resource. A read after write verifies the external payroll state.
5. Revalidate: The next payroll cycle supplies the delayed outcome. Failures and manual corrections become regression cases.
6. Evolve: Policy, tool schema, or owner changes invalidate previous release evidence. A new version is validated; versions tied to a retired API leave operation.

Common gaps

• A capability is live without a fixed owner or a revocable version record.
• Offline evaluation, shadow operation, and canary release are treated as the same test.
• Validation scores the model output but does not inspect tool side effects or consumer outcomes.
• Runtime events are not bound to prompt, tool-set, skill, model, and policy versions.
• Promotion exists, but demotion, freeze, rollback, and retirement do not.

Review checklist

1. Does each production capability have a stable ID, version, owner, and business scope?
2. Does release evidence cover both offline evaluation and controlled production validation?
3. Can each run be traced to a capability version, tool set, and authority policy?
4. Do external acceptance and delayed business outcomes enter revalidation?
5. Which changes invalidate previous evidence and trigger a freeze or new validation?
6. Can the system demote, roll back, revoke, and retire a capability?

Related material

• ADPS Pattern Catalogue and Selection Framework
• Composing Agent Patterns
• Human-Agent Interaction
• X1 Observability
• X2 Evaluation & Validation
• Governance overview
• First Governance Module Workshop