Purple Orange AI
Short version
The first live draft is the moment a reviewable AI workflow stops being a concept and starts touching operations. It should be created from a real source record, delivered in the agreed review channel, and held behind a human approval gate before anything is sent, posted, or written back.
If the reviewer cannot see the source evidence, proposed action, destination system, owner, reject path, and run log, the workflow is not ready to be called live.
This is why the Reviewable Agent offer uses the first live draft as the second-payment milestone. It is concrete. A founder can inspect it. An operator can approve or reject it. A technical owner can trace how it was produced.
Use this guide after an AI workflow audit brief, acceptance criteria, or evidence packet when the team needs to decide whether the workflow is real enough to keep, repair, expand, or stop.
Why the draft matters
A demo can hide every hard part: stale source data, missing fields, ambiguous ownership, weak approvals, broad credentials, bad edge cases, and unclear handoff. The first live draft cannot hide as much. It has to survive the real channel where work already happens.
The draft forces five practical questions:
- Is the source real? The input should be a live lead, ticket, email, quote, doc, task, or record the team would have handled anyway.
- Is the output useful? The draft should save thinking, writing, routing, summarizing, or updating time for the reviewer.
- Is the evidence visible? The reviewer should see why the draft says what it says without opening five tools.
- Is the action bounded? The workflow should make the allowed action clear and block any risky action that still needs judgment.
- Is the next decision obvious? Approve, edit, reject, escalate, repair, or pause should be clear enough that the queue does not rot.
A good first draft creates trust because it is inspectable. A weak one is still useful if it shows exactly what needs repair.
What the draft must show
Do not judge the first draft as a piece of generated text alone. Judge the whole approval object.
1. Source record and context
Name the record, thread, ticket, opportunity, document, or task that triggered the run. Include the relevant fields, notes, transcript, files, or prior messages the agent used. The reviewer should not have to guess which customer, prospect, project, or internal request is being handled.
2. Proposed output
Show the actual draft: reply, follow-up, quote summary, CRM note, task update, routing recommendation, report comment, or document extract. The output should be close enough that the reviewer edits for judgment, not because the workflow missed basic facts.
3. Proposed action
Separate the draft from the action. "Send this email," "update this CRM field," "create this task," "route this ticket," and "post this reply" are different decisions. The draft should tell the reviewer exactly what will happen after approval.
4. Approval controls
The reviewer needs a simple path to approve, edit, reject, and escalate. Approval should not require copying text across tools or remembering a hidden command. If the queue is clumsy, the workflow will quietly move back to manual work.
5. Exceptions and confidence
The first draft should name what it could not determine: missing fields, conflicting records, stale context, risky language, uncertain owner, failed lookup, or low confidence. A workflow that admits uncertainty is easier to trust than one that pretends every case is normal.
6. Run log
Capture trigger, source record, prompt or workflow version, retrieval context, tool calls, output, approval state, cost, latency, and final action. This becomes the evidence base for QA, maintenance, incident response, and expansion.
Approval test
Use this table before calling the workflow live. Green means the first draft is a legitimate milestone. Yellow means repair before volume. Red means the workflow is still a demo.
| Area | Green | Red flag |
|---|---|---|
| Input | Real source record from the normal workflow. | Synthetic prompt, cherry-picked example, or copied sample. |
| Channel | Draft appears where the reviewer already works. | Output lives in a separate demo tool nobody will check. |
| Evidence | Source facts and relevant context are attached or linked. | Reviewer sees only the generated answer. |
| Control | Approve, edit, reject, and escalate paths are obvious. | Approval depends on manual copying or private knowledge. |
| Write-back | No send, post, or system update happens before approval. | The agent can act before the human sees the draft. |
| Trace | Run log explains what happened and what changed. | The team cannot reconstruct the run after the fact. |
Pair this test with the deeper AI approval workflow automation guide when the workflow needs several reviewers, risk labels, deadlines, escalation paths, or write-back rules.
Stack fit
The first live draft often reveals whether the operating stack can carry AI work. The model may be good enough, while the CRM fields are stale, the inbox labels are inconsistent, the source documents are scattered, or the review channel is too slow.
Use Purple Orange Stack's AI automation audit as supporting owned research when checking CRM readiness, lead routing, inbox rules, docs, reporting, workflow tools, and implementation priority. The first draft should be judged against the team's actual stack, not a fantasy version of it.
For a narrow workflow, the existing stack may be enough: Slack or email for approval, CRM or docs for source records, and a simple run log. For a workflow that crosses several systems, use an integration map before expanding. If the first draft needs custom tool access, audit logs, evals, or MCP servers, treat it as production AI infrastructure.
Decision path
The first live draft should end in one clean decision.
| Decision | Use when | Next move |
|---|---|---|
| Accept the milestone | The draft is useful, evidence is visible, approval works, and no action happens without review. | Move into the fix window, collect more runs, and prepare handoff. |
| Repair the workflow | The draft is close, but source context, prompt rules, review labels, or destination behavior need cleanup. | Turn reviewer edits into a small repair list and rerun against real records. |
| Narrow the scope | The agent can draft one part of the work, but the requested action is too broad or risky. | Reduce the workflow to a safer draft-and-approve shape. |
| Scope a sprint | The first draft proves demand, but integrations, controls, telemetry, or QA need more build depth. | Use a two-week sprint with acceptance criteria and a production gate. |
| Stop the build | The first draft exposes weak value, bad source data, unclear ownership, or a workflow nobody wants to review. | Keep the evidence and choose a better automation candidate. |
The practical test: if the first live draft cannot be approved, edited, rejected, or escalated by the real owner in the real channel, it is not a live workflow. It is still a demo with better lighting.
For the next layer, use the handoff checklist once the draft works, the maintenance plan once it runs weekly, and the ROI model before funding expansion.
Bring one workflow to the audit.
We will map the source record, draft shape, approval channel, write-back boundary, and first live milestone, then tell you whether the next move is a reviewable agent, cleanup, sprint, buildout, infrastructure, or no build.
FAQ
Is the first live draft the same as a demo?
No. A demo can use staged inputs. The first live draft uses a real workflow input and appears in the real review channel before the agent sends, posts, or writes back.
Does the first draft need to be perfect?
No. It needs to be useful and inspectable. Reviewer edits are expected. The question is whether the workflow is close enough to repair quickly and worth keeping in the operating path.
Who should review the first draft?
The person who owns the real outcome should review it. For customer, revenue, legal, hiring, or public-facing work, that owner should not be replaced by a purely technical reviewer.
What if the stack cannot support approval?
Then the right next move may be cleanup, a narrower reviewable agent, or a scoped sprint. Do not grant broader autonomy to compensate for weak approval infrastructure.