From project notes to a bounded approval request

A clear boundary before a commitment.

A project proposal defines the work and resources someone is asked to approve, separating scope, exclusions, estimates and dependencies from hoped-for outcomes.

Make this with my agent

Bring your notes. Review a draft before sharing.

Explore the method

01
Bound the decision
Five revised article drafts and a review log—not publication or a full rollout.
02
Keep estimates conditional
30 staff hours and a proposed two weeks depend on approval, staffing and authorized source access.
03
Don’t sell an unmeasured outcome
Clearer answers are a hypothesis; there is no support-demand baseline or measured saving.

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 proposal. Your agent. A clear commitment.

Make the decision small enough to understand: what is included, what is excluded and what must be confirmed before work starts.

Start with three things

The proposed work, exclusions and reviewable deliverables.
Supplied effort estimates, availability and dependencies.
The decision owner, approval process and unresolved evidence.

Make this with my agent

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

The method behind the project proposalAsk your agent to put the exact authorization request first, keep estimates conditional and distinguish a pilot from permission for a rollout.

How do I create a project proposal with an AI agent?

Give your agent the problem, proposed work, known constraints, and the person who can approve it. Ask for a proposal that separates scope from exclusions, estimates from commitments, and deliverables from hoped-for benefits. Review the draft, then share a readable HTML page with a clear request for a decision.

What to give your agent

The problem and supporting evidence, with dates and permission to share.
The work being proposed, explicit exclusions, and deliverables with acceptance criteria.
Estimated effort or cost, units and exclusions, who supplied each estimate, and unresolved resource availability.
Dependencies, proposed timing, risks, and the person authorized to decide.
The existing approval process and any mandatory submission format.

Name exactly what you want approved
'Approve a two-week content pilot' is different from 'approve the full redesign.' State the proposed phase, requested resources, decision owner, and any supplied deadline. If these are missing, ask before turning the idea into a commitment.
Draw a boundary around the work
Put included work beside explicit exclusions. For each deliverable, name the evidence someone will use to review it. 'Write five draft articles' describes output; 'reduce support demand' describes an outcome that still needs measurement. Do not promise one because you can deliver the other.
Show what the estimate depends on
Keep the source, units, exclusions, and uncertainty beside each estimate. Explain whether the proposed schedule starts after approval, source access, or another dependency. An available budget does not prove staff availability; a proposed duration is not a booked start date.
Make the decision smaller than the whole project
When the evidence supports only a pilot, propose that pilot and a later review. Show what the reviewer can approve, reject, or ask to revise. Do not quietly bundle a rollout into permission to explore an idea.
Review before asking for commitment
Have your agent create a static HTML page with the approval request first, followed by scope, deliverables, estimates, dependencies, and supporting evidence. Confirm the facts and audience. Keep the actual approval record in the agreed email or project workflow.

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 proposal for [decision owner] about [proposed work]. Ask only for missing essentials: the decision requested, scope and exclusions, deliverables and review criteria, resource estimates, dependencies, and approval process. Lead with exactly what I am asking them to authorize. Distinguish proposed work from approved work, estimates from commitments, and deliverables from expected outcomes. Preserve estimate units, sources, exclusions, and uncertainty. Do not invent available staff, savings, return on investment, approvals, dates, or acceptance criteria. If criteria are missing, list them as unresolved rather than making them binding. Explain what must happen before work starts and what would require a separate decision. Create readable static HTML with no scripts, forms, signature fields, or live-data claims. Use my saved artifact style if available. Keep sensitive evidence in my existing authorized tools; include only audience-safe details and links. Show me the draft and unresolved questions for review. Do not publish or change access without separate explicit approval. Keep the approval record in our existing email or project workflow. For a business-case version, state the supplied benefit hypothesis, baseline, evidence gaps and proposed checkpoint before a larger commitment. Keep benefits hypothetical until measured. Do not invent ROI, monetize staff hours without approved assumptions or convert a proposed checkpoint into an agreed approval condition.

Check before you shareAccuracy, clarity, and permission

Is the exact phase and resource commitment being requested visible near the top?
Are exclusions as clear as included deliverables?
Are estimated cost, effort, and timing labeled accurately with their dependencies?
Are acceptance criteria supplied facts or clearly unresolved—not invented commitments?
Are expected benefits separate from measured outcomes?
Does the page explain how to respond without pretending to collect approval?

When HTML fits

Use an HTML proposal when someone needs to understand the proposed commitment asynchronously, with a short opening and supporting detail below. Your agent can reuse authorized context without moving the project into another editor.

When another format fits better

Use the required submission template when procurement or a client mandates one. Keep negotiation, signatures, resource allocation, and the authoritative approval record in their established systems. A shared page does not authorize work or enforce contractual terms.

What we started withThe same facts, as a wiki page

Fictional team wiki

Maple Support — five-article pilot proposal

Context

Prepared September 7, 2026, by Sam for Lee. We want clearer help instructions. Clearer content and reduced support demand are hypotheses: there is no support-demand baseline or agreed reduction target.

Decision and scope

Decision requested by September 11: approve a five-article pilot and the proposed staff effort. Nothing is approved yet. Scope is to audit five selected help articles, draft revisions and run an editorial review. Article selection needs confirmation. Publishing, site redesign, software changes, the remaining help library and full rollout are excluded.

Deliverables and review

Deliverables are five revised drafts and a review log. An as-yet-unassigned reviewer must verify product steps, flag missing evidence and record unresolved issues. Review is not automatic acceptance or permission to publish.

Estimated effort and duration

Sam estimates 24 writer hours plus 6 reviewer hours, totaling 30 staff hours. Availability is unconfirmed; there is no monetary rate, cost estimate or available budget. Proposed duration is two weeks after approval and authorized source access, with no agreed calendar start.

Dependencies and next decisions

Noor owns the pending authorization request for sanitized support examples. No actual customer material is included. Before starting, confirm article selection, reviewer, staffing, approval and source access. At the end Lee reviews the drafts and issues; publication or rollout needs a separate recorded decision in the existing project workflow. No savings or reduction in support demand is promised.

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>Maple Support · Five-article pilot proposal</title><style>
*{box-sizing:border-box}html{color-scheme:light}body{margin:0;background:#faf7f0;color:#242b28;font:17px/1.65 system-ui,sans-serif}main{max-width:960px;margin:auto;padding:clamp(20px,5vw,64px)}h1,h2,h3,p{margin:0 0 18px}h1{font:500 clamp(32px,5vw,58px)/1.12 Georgia,serif;letter-spacing:-.025em;overflow-wrap:anywhere}h2{font:500 29px/1.25 Georgia,serif}h3{font-size:18px;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:#214c3e;color:#fff;padding:24px;margin:28px 0}.lead p:last-child{margin:0}.grid{display:grid;grid-template-columns:repeat(auto-fit,minmax(min(100%,220px),1fr));gap:20px;margin:24px 0}.card{background:#fff;border:1px solid #c8d2c5;padding:24px}.metric{font:500 40px/1.1 Georgia,serif;display:block;margin-bottom:12px}section{margin:36px 0}ul,ol{padding-left:22px}li{margin-bottom:12px}.note{color:#46594f;font-size:14px}.pending{border-left:5px solid #946116;padding-left:20px}footer{border-top:1px solid #bac8bf;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 / Maple Support / September 7, 2026</p><h1>Five better drafts. Not a full rollout.</h1><p class="intro">A bounded pilot to improve help instructions, with the work, effort, and unanswered questions visible before anyone commits.</p><p class="note">Prepared by Sam · Decision owner: Lee</p></header>
<aside class="lead"><p class="label">Proposed · not approved</p><h2>Approve the five-article pilot and proposed staff effort.</h2><p>Lee is asked to decide by September 11, 2026. This request does not include publishing or a full rollout. Nothing is approved yet.</p></aside>
<section><h2>The boundary of the work</h2><div class="grid"><article class="card"><p class="label">Included</p><h3>Audit, revise, review</h3><ul><li>Audit five selected help articles.</li><li>Draft revisions.</li><li>Run an editorial review.</li></ul><p class="note">Article selection still needs confirmation.</p></article><article class="card"><p class="label">Excluded</p><h3>No wider commitment</h3><ul><li>Publishing the articles.</li><li>Site redesign or software changes.</li><li>The remaining help library.</li><li>A full rollout.</li></ul></article></div></section>
<section><h2>What the pilot must produce</h2><p>Five revised drafts and a review log showing unresolved issues.</p><p>The reviewer must verify product steps, flag missing evidence, and record unresolved issues. The reviewer has not yet been assigned. Review is not automatic acceptance or permission to publish.</p></section>
<section><h2>Effort is estimated. A start is not booked.</h2><div class="grid"><article class="card"><span class="metric">30 staff hours</span><h3>Sam’s estimate</h3><p>24 writer hours plus 6 reviewer hours. Staff availability is unconfirmed.</p><p class="note">No monetary rate, cost estimate, or available budget is supplied.</p></article><article class="card"><span class="metric">Two weeks</span><h3>Proposed duration</h3><p>After approval and authorized source access. No calendar start date is agreed.</p></article></div></section>
<section class="pending"><p class="label">Dependency · approval pending</p><h2>Authorize the source examples first.</h2><p>Noor owns the request to use sanitized support examples. That authorization is still pending. No actual customer material is included in this example.</p></section>
<section><h2>What we cannot promise yet</h2><p>Clearer instructions and reduced support demand are hypotheses, not measured results. There is no support-demand baseline or agreed reduction target. This proposal makes no savings claim.</p></section>
<section><h2>Before work starts</h2><ol><li>Confirm the five articles and assign the reviewer.</li><li>Confirm staff availability.</li><li>Obtain the pilot approval and authorized source access.</li></ol></section>
<section class="card"><p class="label">At the end of the pilot</p><h2>Review the drafts. Decide separately what follows.</h2><p>Lee reviews the drafts and unresolved issues. Any publication or rollout requires a separate decision. Record approval in the existing project workflow; this page does not collect it.</p></section>
<footer>Fictional worked example by share/artifacts. Names, dates, and figures are invented for demonstration. Source: the fictional pilot 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

Approve the pilot—not an uncosted rollout

A fictional support team proposes a two-week pilot to improve five help articles. The same facts below become a bounded request rather than an implied commitment.

The original notes

Pilot notes: audit five selected help articles, draft revisions, and run an editorial review. Deliver five revised drafts plus a review log of unresolved issues. Exclude publishing, site redesign, software changes, and the rest of the library. Sam estimates 24 writer hours plus 6 reviewer hours; staff availability is unconfirmed. Proposed duration: two weeks after approval and authorized source access. Neither is approved yet. There is no measured support-demand baseline or agreed reduction target. Ask Lee to approve only the pilot and proposed staff effort, not a full rollout.

Request

Approve only the five-article pilot and proposed staff effort. Nothing is approved yet.

Scope

Audit, draft revisions, and editorial review. Publishing, site redesign, software changes, and the remaining library are excluded.

Deliverables

Five revised drafts and a review log showing unresolved issues—not published articles.

Estimate

24 writer hours plus 6 reviewer hours; availability unconfirmed. Two weeks is a proposed duration after approval and authorized source access.

Unknown

No measured support-demand baseline or agreed reduction target. Do not invent savings.

Approval is safer when the reader can see the boundary of the commitment.

Questions, adaptations & sourcesGo deeper when you need to

Is this the same as a decision brief?

A decision brief helps compare options. A project proposal spells out the work and resources someone would authorize. If your reader only needs to choose between alternatives, use the decision-brief workflow instead.

What if we do not know the budget or schedule yet?

Label them unresolved, preserve any supplied estimate, and say what is needed to confirm it. You may propose a bounded discovery phase if that is genuinely the decision you want; do not turn uncertainty into a confident full-project quote.

Can someone approve the proposal on the page?

No. This is a static reading page, not a signature or approval system. Tell the reader to respond through your agreed email or project workflow.

A business case for a bounded pilot

Make the benefit hypothesis, available baseline and next evidence checkpoint explicit. The case should explain why this is a useful learning investment, not manufacture a return-on-investment calculation from staff-hour estimates.

Fictional inputs: Fictional proposal: revise five support articles using 24 writer hours and 6 reviewer hours, both estimates. The intended benefit is clearer answers, but the support-demand baseline is missing. The proposed next checkpoint is a review of article quality and a plan to establish baseline demand before considering a larger rollout. Approval is pending.

A clearer result: Request the bounded 30-hour estimated pilot, not a full rollout. Label clearer answers a hypothesis. Show the missing baseline and proposed quality/evidence checkpoint. Do not monetize hours into savings or claim reduced support demand before measurement; the checkpoint and funding still require approval.