share/artifacts
PricingSign inConnect your agent
← All guides

From delivery notes to a clear transfer

Files received. Responsibility still pending.

A project handoff explains delivered work, acceptance state, open issues and the conditions under which the receiving owner can take responsibility.

Make this with my agent

Bring your notes. Review a draft before sharing.

Explore the method
  1. 01
    Different states, not one score

    Eight drafts arrived; six are accepted and two still need terminology review.

  2. 02
    Keep ownership explicit

    Casey remains delivery owner until Morgan explicitly accepts maintenance responsibility.

  3. 03
    Access is not permission

    Reading access does not establish publishing permission or a confirmed transfer date.

THE REAL HTML · FICTIONAL EXAMPLEView on its own

A worked example, not a customer result. September 2026 dates are sample facts.

Now make it about your work

Your work. Your agent. A clearer handover.

Help the receiving team see what arrived, what is accepted and who still owns the unfinished work.

Start with three things

  1. Deliverables, versions and actual review evidence.
  2. Open issues, current owners and transfer conditions.
  3. Approved operating references, access limits and scope exclusions.
Make this with my agent

You review the facts and access. Nothing is published without your approval.

The method behind the project handoffAsk your agent to distinguish receipt from acceptance, preserve current ownership and make the receiver’s first checks explicit.

How do I create a useful project handoff with my AI agent?

Give your agent the deliverables, review evidence, known issues, and agreed ownership arrangements. Ask for a handoff page that distinguishes received work from accepted work, names who still owns each open item, and explains what the receiving team must confirm. Review it before sharing; the page summarizes a transfer but does not perform one.

What to give your agent

  • The deliverables and their current versions, with the supplied review criteria and acceptance evidence.
  • Open issues and dependencies, their consequences, confirmed owners, and any agreed target dates.
  • The outgoing and receiving owners, the conditions for transfer, and the authoritative acceptance record if one exists.
  • Approved operating instructions, audience-safe reference links, and the receiving team's known access limitations. Never include credentials.
  • The next review request, confirmed support arrangements, and what remains outside the delivered scope.

  1. Start with what the receiver needs to know

    Name the work being handed over, its current state, and the decision or action needed from the receiving owner. Do not begin with the project's entire history. If ownership or readiness is unclear, say that at the top rather than hiding it beneath a completed-deliverables list.

  2. Separate delivery from acceptance

    For each deliverable, preserve the supplied version, review evidence, and acceptance state. Files can be received while review is still pending. A successful test is not necessarily customer acceptance, and an acknowledgement is not permission to publish. Ask for missing evidence rather than turning a delivery message into a sign-off.

  3. Give every open issue a next step

    Show its consequence, current owner, next action, and target date when supplied. Keep unassigned work visibly unassigned. Explain any restriction on using the affected deliverable. Do not label the whole project ready merely because most items are complete, or quietly move unresolved work to the receiving team.

  4. Check the conditions for taking over

    Confirm which responsibilities have actually transferred and which remain with delivery. Put required access and operating references beside the work they support. A readable link does not establish editing permission. Keep access requests in the approved process and keep credentials out of the page.

  5. Walk the handoff with the receiving owner

    Ask whether they can identify their first action, find the required references, and explain who handles an unresolved issue. Verify the draft against the sources and record actual acceptance in the established project workflow. Share the reviewed snapshot only with an approved audience; update it when an agreed responsibility or status changes.

Keep creating and revising in the agent you already use. Start with a saved artifact style and learn how to update HTML without changing its link.

Use the full promptReady for your agent and your notes

Use the conversation where you already did the work. Only attach material you are allowed to share.

Get the ready-to-copy creation request →
Using only materials I provide or have authorized you to access, create a project handoff for [receiving owner] covering [delivered work]. Ask only for missing essentials: deliverables and versions, acceptance evidence, open issues, current owners, transfer conditions, required access, and the next review request. Lead with what is ready to take over and what still needs confirmation. Separate received, reviewed, and accepted work. For each open issue preserve its consequence, current owner, next action, and supplied target date; keep missing information unresolved. Distinguish a target from a commitment. Do not infer acceptance from receipt or silence, invent owners or dates, close issues, grant access, or transfer responsibility. Keep known restrictions beside affected deliverables, and preserve scope exclusions. Include only audience-safe references, not credentials or private source notes. Explain how to record acceptance in our existing project workflow; this page must not collect it. Create readable static HTML with no scripts, forms, signature fields, or live-data claims. Use my saved artifact style if available. Show me the draft and unresolved questions. Do not publish or change access without separate explicit approval.
Check before you shareAccuracy, clarity, and permission
  • Can the receiving owner see what is ready and what they must confirm without reading the full history?
  • Are receipt, acceptance, permission, and ownership transfer distinct and supported by the sources?
  • Does each open issue retain its current owner, consequence, and honest target status?
  • Are the operating references useful to the recipient at their actual access level, with no credentials exposed?
  • Are scope exclusions and conditions for transfer still visible?
  • Does the page point to the authoritative acceptance process rather than pretending to complete it?

When HTML fits

An HTML handoff is useful when a receiving team needs a concise reading page assembled from delivery notes, issue records, and approved instructions already available to your agent. It can put the next action first and leave supporting detail below.

When another format fits better

Keep authoritative issues, approvals, access grants, and ownership records in their existing tools. Use a required handover document or signature process when your organization needs one. If your existing project page already answers the receiver's questions, share it rather than maintain a duplicate. This static page does not track acknowledgements or update itself.

What we started withThe same facts, as a wiki page

Fictional team wiki

Cedar Help — delivery and maintenance handoff, September 7, 2026

Delivered files

Delivery D-08: eight revised article drafts and maintenance guide version 1 were delivered September 7. Morgan acknowledged receipt of all files, not acceptance of maintenance responsibility. Individual article titles and versions are not in this excerpt.

Review status

Review R-06: six articles are accepted; two await terminology review. Consult the full review log to identify the accepted articles. Content acceptance is not permission to publish.

Open issues

Issue I-02: Casey owns terminology review, targeted for September 10, not guaranteed. One outdated reference must be removed before affected articles are published. Casey also owns identifying those articles and correcting the reference; the identifiers and a separate correction date remain open.

Ownership and access

Ownership O-03: Casey remains delivery owner until Morgan explicitly accepts maintenance in the existing project record. Morgan has not accepted, and the transfer date is unconfirmed. Access A-01: Morgan can read the draft folder, but publishing permission needs verification through the approved access process.

Scope and references

Scope S-01 excludes software changes and the rest of the knowledge base. Authoritative references are the full review log, draft folder, maintenance guide and ownership record; their URLs are not supplied. Post-transfer support coverage also needs confirmation.

Next review

Casey and Morgan should review article outcomes, identifiers and reference correction, publishing permission, support coverage and recorded acceptance. No review date is agreed. Sharing this record does not publish articles, grant access, close issues or transfer responsibility.

Inspect the HTMLOne self-contained file

The example is sanitized and isolated from this site. No scripts, forms, or live data.

<!doctype html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1"><title>Cedar Help · Project handoff</title><style>
*{box-sizing:border-box}html{color-scheme:light}body{margin:0;background:#f6f4ee;color:#182e36;font:17px/1.65 system-ui,sans-serif}main{max-width:980px;margin:auto;padding:clamp(20px,5vw,64px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(34px,5vw,60px)/1.12 Georgia,serif;letter-spacing:-.025em;overflow-wrap:anywhere}h2{font:500 29px/1.25 Georgia,serif}h3{font-size:19px;line-height:1.4}.label{font:700 12px/1.5 system-ui,sans-serif;letter-spacing:.12em;text-transform:uppercase}.intro{font-size:20px}.lead{background:#173f4b;color:white;padding:24px;margin:28px 0}.lead p:last-child{margin:0}.grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,230px),1fr));gap:20px;margin:24px 0}.card{background:#fff;border:1px solid #b9c8c9;padding:24px}.metric{font:500 42px/1.1 Georgia,serif;display:block;margin-bottom:12px}section{margin:36px 0}ul,ol{padding-left:22px}li{margin-bottom:12px}.note{font-size:14px;color:#425c62}.warning{border-left:5px solid #a96215;padding-left:20px}footer{border-top:1px solid #b9c8c9;padding-top:24px;margin-top:40px;font-size:14px}@media print{body{background:white}.card,.lead{break-inside:avoid}}
</style></head><body><main>
<header><p class="label">Fictional example / Cedar Help / September 7, 2026</p><h1>The files arrived. The transfer is still pending.</h1><p class="intro">Eight article drafts and a maintenance guide are delivered. Review and responsibility are separate questions.</p></header>
<aside class="lead"><p class="label">Ownership · not yet transferred</p><h2>Casey remains delivery owner.</h2><p>Morgan has acknowledged receipt, not accepted maintenance responsibility. The transfer date is unconfirmed. Record acceptance in the existing project workflow.</p></aside>
<section><h2>What was delivered—and what is accepted</h2><div class="grid"><article class="card"><span class="metric">8 drafts</span><h3>All files received</h3><p>Delivered September 7 with maintenance guide version 1. Individual article titles and versions were not supplied.</p><p class="note">Source: delivery note D-08.</p></article><article class="card"><span class="metric">6 accepted</span><h3>2 await terminology review</h3><p>Check the full review log to identify the accepted articles. Content acceptance is not permission to publish.</p><p class="note">Source: review log R-06.</p></article></div></section>
<section class="warning"><p class="label">Open issue · I-02</p><h2>Resolve the terminology and outdated reference.</h2><p>Casey owns the terminology review. Target: September 10, 2026, not a guaranteed completion date.</p><p>One outdated reference must be removed before the affected articles are published. Casey also owns confirming the affected article identifiers and correcting the reference. Those identifiers are not supplied; no separate correction date is agreed.</p></section>
<section><h2>What each side still needs to do</h2><div class="grid"><article class="card"><p class="label">Delivery · Casey</p><h3>Keep ownership until acceptance</h3><p>Complete the review and reference follow-up. Do not move open issues to Morgan by default.</p></article><article class="card"><p class="label">Receiving owner · Morgan</p><h3>Confirm readiness to take over</h3><p>Reading access to the draft folder is confirmed. Publishing permission and post-transfer support coverage are not confirmed.</p><p class="note">Check permissions through the approved access process.</p></article></div><p class="note">Sources: ownership note O-03, access note A-01, and reference inventory.</p></section>
<section><h2>References to check before taking over</h2><ul><li><strong>Full review log:</strong> identify accepted articles and confirm the two outstanding reviews.</li><li><strong>Draft folder:</strong> check article versions and affected identifiers.</li><li><strong>Maintenance guide version 1:</strong> review the operating instructions and confirm support coverage.</li><li><strong>Ownership record:</strong> record any explicit acceptance.</li></ul><p class="note">Source URLs were not supplied. This example does not invent links or provide credentials.</p></section>
<section><h2>Outside this handoff</h2><p>Software changes and the rest of the knowledge base are excluded.</p><p class="note">Source: scope note S-01.</p></section>
<section class="card"><p class="label">Next review · date not agreed</p><h2>Casey and Morgan: confirm the remaining conditions.</h2><ol><li>Confirm the two articles' review outcome, affected identifiers, and reference correction.</li><li>Confirm publishing permission and post-transfer support coverage.</li><li>Record ownership acceptance when agreed in the existing project workflow.</li></ol><p>This page does not collect acceptance. Sharing it does not authorize article publication, grant access, close issues, or transfer responsibility.</p></section>
<footer>Fictional worked example by share/artifacts. Names, dates, and records are invented for demonstration. Source: the fictional handoff notes accompanying this example. Static snapshot; no live data or automatic updates.</footer>
</main></body></html>
The original worked scenarioThe source scenario, step by step

The files arrived. The transfer is still pending.

A fictional help-center refresh. Delivery, review, and ownership notes describe different states; the handoff preserves all three.

The original notes

Eight article drafts and a maintenance guide were delivered. Morgan acknowledged receipt of all files. Six articles are accepted; two await terminology review. Casey owns the terminology review, targeting September 10, not a guaranteed completion date. One outdated reference must be removed before the affected articles are published. Casey remains delivery owner until Morgan explicitly accepts maintenance responsibility in the existing project record. Morgan can read the draft folder; publishing permission is unconfirmed. Software changes and the rest of the knowledge base are excluded. The transfer date is unconfirmed.

Received

Eight drafts and the maintenance guide reached Morgan. Receipt is not ownership acceptance.

Review state

Six articles are accepted; two await terminology review. Remove the outdated reference before the affected articles are published.

Still with delivery

Casey owns the terminology review, targeting September 10. Casey remains delivery owner until Morgan explicitly accepts maintenance responsibility in the existing project record.

Receiver must confirm

Morgan can read the draft folder; publishing permission and the transfer date are unconfirmed.

Outside this handoff

Software changes and the rest of the knowledge base are excluded.

A useful handoff prevents the gap where both teams assume the other one is responsible.

Questions, adaptations & sourcesGo deeper when you need to

How is a handoff different from a status report?

A status report explains changes while work continues. A handoff helps someone take responsibility for delivered work: the operating context, unresolved issues, access prerequisites, and conditions for transfer matter most. Link to the status history instead of reproducing it.

What if the receiving owner has not accepted yet?

Mark the transfer as pending and state the confirmed current owner. Ask for the missing decision through the existing approval process. Do not treat an email acknowledging files, a page view, or silence as acceptance.

Can a project be handed over with open issues?

That depends on the agreed criteria and authorized decision-makers. Describe the remaining issues and their ownership accurately. The agent should not decide that they are minor enough to waive, or invent an agreement to transfer them.

Further reading

By share/artifacts · Published · Updated