A client closeout packet for AI-delivered work should contain the agreed scope, exact deliverable version, evidence for each completion claim, known exceptions, a named human acceptance decision, and the next action. Keep the packet short enough to review in one sitting, with source links for anyone who needs to check the details.
This works for a weekly delivery review or a final implementation handoff. The difference is the scope being accepted. A client can accept this week's reporting update while a production rollout remains blocked.
What belongs in the closeout packet?
Use these seven sections. Keep missing information visible rather than asking an agent to fill it in from context.
- Delivery scope. State the outcome, review period, acceptance criteria, and exclusions. Link the approved brief or change request. If the scope changed, show which decision changed it.
- Versioned deliverables. List each artifact with its version, commit, or dated export. Link the actual file or deployment being reviewed. A link that always opens the latest document needs an accompanying version reference.
- Evidence by claim. Pair each claimed result with a test output, inspection, source record, or observation. Include when the check ran and which version it checked. Write “not checked” when evidence is absent.
- Exceptions and unresolved work. Name failed checks, untested cases, dependencies, and limitations. Assign each one an owner. Separate a known limitation the client may accept from a defect that blocks delivery.
- Review history. Identify who prepared the work, who checked it, and what changed after review. Preserve relevant agent and human contributions without exposing private prompts or unrelated client information.
- Acceptance decision. Record the authorized person's identity, role, ruling, timestamp, and exact scope. Useful rulings include accepted, returned for changes, and pending. If your process allows conditional acceptance, spell out the conditions.
- Next action. State what happens next, who owns it, and the due date or trigger. Include any approval still required before sending, deploying, or changing production data.
The evidence section should explain the relationship between work and result. W3C's provenance model offers a useful foundation: identify the thing produced, the activity that produced it, and the people or systems involved. You do not need to adopt the full standard to make those relationships explicit. See the W3C PROV overview.
A filled example: an automation ready for review
The following is a fictional example, not a customer result. All details are illustrative.
Scope: Prepare a staging version of a lead-routing automation. Production enablement and historical-data cleanup are excluded.
Deliverables: Routing configuration v3, field-mapping document v2, and an operator rollback checklist. Each entry links to its reviewable version.
Evidence: The staging test report covers valid submissions, duplicate submissions, and records missing a required field. Those checks passed against configuration v3. Live CRM delivery has not been tested.
Evidence timestamp and source: September 30, 2026, at 15:00 UTC. Attach the test report and the configuration v3 reference before requesting review.
Exception: The client has not confirmed who should receive leads from a newly added region. Those leads remain in the review queue. The client operations owner must resolve the routing rule.
Review: The delivery engineer checked the field mappings. The delivery lead inspected the exception handling and returned an earlier version for correction.
Acceptance requested: The client operations owner is asked to accept the staging implementation with the regional-routing exception recorded. No production deployment is included in this request.
Next action: Resolve the region owner, run a witnessed production smoke test after deployment approval, and attach that result to the next closeout.
This packet lets the client make a bounded decision. A broad statement such as “the automation is complete” would hide the untested production path and unresolved routing rule.
How should client approval be recorded?
Ask one clear question about a specific version: “Do you accept routing configuration v3 for staging, with the regional-routing exception recorded?” Link the evidence and provide a way to request changes.
Separate internal delivery review from client acceptance. Your delivery lead may authorize a packet to be sent. That does not establish that the client accepted it. A client may accept a staging result without authorizing production deployment.
Also distinguish access from identity. Someone opening a shared link proves only that the link was opened. A response entered through an unauthenticated link may have weaker attribution than an authenticated approval or a reply from the agreed client contact. Record the identity evidence your process actually captured. Do not turn a typed name into a verified identity claim.
If the deliverable changes after approval, check whether the change affects the accepted scope and request renewed review where needed. GitHub provides a concrete software example: repositories can be configured to dismiss approving reviews when the reviewed diff changes. That behavior is configurable; it should not be assumed. See GitHub's protected-branch documentation.
What can an AI agent prepare?
An agent can gather source links, organize deliverables, draft the summary, and flag missing evidence. Give it the review period and approved scope before it begins. Require each factual completion claim to point to a source.
Use this preparation prompt:
“Prepare a closeout packet for the agreed scope and review period. List versioned deliverables, evidence for each result, failed or missing checks, unresolved decisions, and next actions with owners. Keep internal review and client acceptance separate. Mark unknowns explicitly. Draft the packet for review; do not send it or record acceptance.”
Have the reviewer open the cited evidence. A passing test supports the behavior that test covered. It does not establish that the client's broader goal has been achieved. Remove credentials, personal data, and unrelated internal discussions before sharing the packet.
Where OrgX fits
OrgX records human acceptance separately from an agent's completion claim and the verifier result. An agent cannot approve its own work. Capture depth differs by client, and quality-bar checking remains in beta. See how OrgX acceptance works.
For a portable technical record, Agent Work Receipt v0.1 provides an account-free format for intent, authority, artifacts, and evidence. Format or integrity validation does not establish that a client accepted the work or that every factual claim is true.
A shared document and well-managed source links can be enough for a small delivery. Start with one real closeout: identify the exact version, attach its evidence, and ask the named owner for a scoped ruling. Carry that ruling into the next week's work.