Revise a document with a human editor
An agent writes a draft. You accept it, request a revision with feedback, or decline it. The same process retains the draft and feedback through at most three rounds. An accepted draft is a…
Revise a document with a human editor
An agent writes a draft. You accept it, request a revision with feedback, or decline it. The same process retains the draft and feedback through at most three rounds. An accepted draft is a result you can inspect; this workflow does not publish or send it anywhere.
# An agent drafts; the person who starts the run directs up to three revisions.
# Acceptance returns the draft. It does not publish or send it anywhere.
TEAM editorial
writer USING "document-author"
editor USING HUMAN("owner")
END
PROCESS prepare_document(brief) WITH writer, editor
REPEAT UP TO 3 WITH work = {draft: "", action: "revise", feedback: ""}
draft = ASK(writer, "Write the complete document using the brief and editorial feedback.", {
brief: brief, previous: work.draft, feedback: work.feedback
})
decision = ASK(editor, "Accept this draft, request a revision, or decline it.", {
brief: brief, draft: draft
}) EXPECT {action: "accept" | "revise" | "decline", feedback: string}
YIELD {draft: draft, action: decision.action, feedback: decision.feedback} UNTIL decision.action != "revise"
END
END
brief = "Write a short notice: the fictional library opens Sunday from noon to 4 pm. Admission is free."
review = prepare_document(brief) USING editorial
HUMAN("owner") assigns the editor to the authenticated person who starts the
run. The writer uses its own continuing conversation. The editor receives the
brief and current draft in the question's Shared context. Their validated
reply becomes ordinary process data; its feedback reaches the writer through
the next iteration's explicit context.
The service-action starter uses HUMAN("service-owner") for the same authenticated
initiating person. Start and recovery resolve both reserved selectors consistently.
The service adapter additionally requires that person to own the installed service
grant; the selector itself grants no service access. Other selector strings name
explicit respondent accounts.
Run and review in Desktop
- Save the source in Author and open Agent → Tasks → Processes.
- Select
reviewand choose a model fordocument-author. - Open Run limits. For this example, allow three model calls and enough time to read and answer the questions, then Start process. New host Starts default to one contribution at a time; the panel shows the host concurrency default in Run limits. Reopening an existing run keeps its original limits.
- When the process waits, open Shared context to read the draft. Choose
revise, enter feedback, and Send reply. - Inspect the revised draft, choose
acceptordecline, and send your reply. The final result retains the draft, decision, feedback, iteration count and reason the loop stopped.
You can close the panel and return to the waiting run while the host remains available. The owner can cancel instead of answering. An invalid answer leaves the same question open; it does not trigger another model call. The existing reply identity prevents accepting two different answers to one question.
If you request revision after the third draft, the loop ends at its iteration
limit with action: "revise". That is unfinished work, not acceptance. A decline
also returns the draft for inspection but retains action: "decline".
Bound the work
Model call limit accepts 0–64. A human-only process can use zero. The writer in this example makes one model call per draft; human replies use participant turns without consuming model calls. The runtime stops before a further call would exceed the selected allowance. Earlier calls keep counting after a revision, failed reply, or resume. A limit below a workflow's needs can leave partial work; it does not change the source's stopping condition.
Time limit accepts 1–3600 seconds and includes time spent waiting for a person. It starts with the admitted run and is never renewed by a reply or resume. Host and provider limits can stop work earlier. Cancelling or expiring an already dispatched model request does not prove the provider did no work.
At waiting and terminal checkpoints, Run usage reports model calls, turns started and operations from the runtime. A turn that starts but exhausts its call allowance before dispatch still counts as a started turn. These are execution counts, not token usage or a price estimate. The complete run still has the host's existing bounds on context, responses, logical work and retained results. An uncertain Start retries the same selected limits and identity; it cannot silently start another run with a fresh allowance.
Current boundaries
This guide demonstrates one person's editorial decisions in a bounded workflow. It does not confer permission for an external publication or API command. Multi-episode case handling, appeal windows, event subscriptions and distributed handoff remain separate unfinished capabilities. On macOS and Linux, Desktop keeps a waiting run in its private recovery store across a host restart; answer it after an explicit Resume. Windows Desktop and hosts without a selected store do not retain a waiting run across restart.