Key takeaways
- Track the requested deliverable, selected source and content versions, relevant returned identifiers, latest observed state, required review, and next owner.
- Keep each identifier labeled by the kind of record it represents and the tool or workflow that returned it.
- Content is ready for review when the actual selected assets and copy are available and the reviewer has the source context and acceptance criteria.
An agent's content job is finished only when the intended editorial outcome has been verified. A queued operation, generated asset, reviewed carousel, scheduled delivery, and confirmed public post are different milestones, so the production record should name the one that actually occurred.
This guide focuses on the team's completion ledger rather than protocol implementation. The ledger connects the task people asked for with the records and review decisions needed to say it is complete. It helps a writer, reviewer, and publisher agree about what remains to be done.
What should the completion ledger track?
Track the requested deliverable, selected source and content versions, relevant returned identifiers, latest observed state, required review, and next owner. Define completion for the task before the agent begins reporting progress.
For a fictional architecture studio requesting a carousel draft, completion may mean that the finished slides and caption are ready for factual review. For a separately authorized publishing task, completion requires evidence about the destination delivery. The same generated asset can satisfy the first task while leaving the second unfinished.
Anthropic's workflow guidance emphasizes clear stages and checks for structured tasks. The editorial application is a ledger where each milestone has observable evidence. Avoid a single done checkbox that everyone interprets differently.
Use the content batching guide to define the handoff points. A generation stage should deliver actual reviewable material; a review stage should deliver a decision about a selected version; a publishing stage should deliver the relevant saved or public state.
How should identifiers be recorded for asynchronous work?
Keep each identifier labeled by the kind of record it represents and the tool or workflow that returned it. Do not treat an operation identifier, native generation run, post identifier, and delivery identifier as interchangeable.
The Caroush catalog documents get_job_status for an MCP operation created by the connection. Its result can refer to a separate native carousel or automation run whose own state must be read for completion. A successful operation-level response is not a blanket statement that every downstream generation or delivery has finished.
For the architecture carousel, the ledger might retain the operation reference, the saved post, and the native run used for outline or revision work. A human-readable title can accompany them, but should not replace them when locating the actual records.
The MCP tools specification describes tool responses and errors. Use the documented semantics of the specific Caroush tool to interpret the business outcome rather than treating any response as success. The ledger should record what was observed, not what the assistant hoped the request would accomplish.
When is generated content ready for review?
Content is ready for review when the actual selected assets and copy are available and the reviewer has the source context and acceptance criteria. A planning outline or queued job can support progress, but it is not the finished visual package.
Read the appropriate saved record and inspect the actual result. For a carousel, check slide availability, copy, errors, and approval state. If the job is incomplete, identify what remains pending rather than generating a confident description of slides the reviewer cannot yet inspect.
The carousel creation guide helps define what a complete review package contains. Include the caption and intended next action as well as slide images. A technically finished render can still lack the information needed for an editorial decision.
Record the selected version before requesting review. If a new generation or revision starts afterward, the old review request may no longer describe the current package. Keep that change visible so people do not approve one version while the agent prepares another.
When can the agent report publication as complete?
Report publication only when the relevant destination state supports that claim, and distinguish confirmed deliveries from pending or failed ones. A multi-account request can have different outcomes for different destinations.
Caroush's documented publishing flow runs in the background and provider processing may remain pending. Use the appropriate saved schedule or post reads, including confirmed live links when available. Do not infer a public result from the fact that a publishing request was accepted.
The social media scheduler can help the publisher inspect actual deliveries. Keep account, caption, timing, and state together. If only some destinations are complete, report the partial result precisely and identify the remaining check.
Browser approval remains required for scheduling and publication. TikTok uses the reviewed Caroush composer rather than direct MCP publishing. The ledger should show that manual branch as an explicit task, not silently include it in a claim that the agent published everywhere.
Write progress updates that support the next action
A useful update says what is complete, what evidence supports it, and what remains. For example, the carousel assets are available and awaiting factual review is clearer than the campaign is ready. A publisher can act on the first statement without guessing what ready means.
Use the approval workflow to define the review milestones. Approval of a carousel's content does not itself schedule or publish it. The destination package may still need a caption variation, account selection, and timing confirmation.
Avoid copying raw tool output into every team update. Keep identifiers in the ledger and summarize the business state in plain language. Include technical detail when it helps the next person locate or resolve the issue.
Handle an interrupted session with the ledger
When an agent session ends or the connection becomes unavailable, the ledger should preserve the last confirmed state and the next required read. This prevents a new assistant from restarting generation or publication merely because it did not see the earlier response.
An authorized person can reconcile the saved state through the application if necessary. Update the ledger with manual actions before resuming the agent. The returning assistant should compare current records with that note before proposing further work.
If the state remains unknown, say so. Uncertainty is a valid operational status when paired with a specific next check. It is safer and more useful than guessing that nothing happened or declaring success without evidence.
Test completion reporting with a mixed result
Use a fictional record set containing one finished draft, one pending generation, and two destination deliveries with different states. Ask the assistant to summarize the campaign for a reviewer and a publisher. The two audiences need different next actions, but both summaries should preserve the same facts.
Then check whether the final headline matches the detail. A summary saying everything is complete while a later bullet lists a pending destination is misleading. Completion should be stated at the scope actually achieved.
A reliable ledger makes agent work easier to resume, review, and verify. It does not require an elaborate project system. It requires a shared definition of the requested outcome, labeled records, and a habit of reporting observed state instead of treating an accepted tool request as the finished job.
Match completion language to the original request
Before closing a task, reread what the team asked the agent to deliver. If the request was a draft for review, the final update should not imply publication. If the request included confirmed delivery, a finished draft alone does not satisfy it.
This comparison is especially useful when scope changed during the work. A team may decide to hold one destination or replace a video with a text explanation. Record the accepted change and report completion against that revised scope, with any remaining work explicit.
The ledger should make this easy: requested outcome, accepted scope changes, actual evidence, and unresolved items. A clear final update helps the next person know whether to review, publish, monitor a pending delivery, or simply archive the completed production record. It also prevents a later assistant from reopening work that was intentionally held or describing a partial result as a finished campaign.
Sources
Frequently asked questions
What should the completion ledger track?
Track the requested deliverable, selected source and content versions, relevant returned identifiers, latest observed state, required review, and next owner. Define completion for the task before the agent begins reporting progress.
How should identifiers be recorded for asynchronous work?
Keep each identifier labeled by the kind of record it represents and the tool or workflow that returned it. Do not treat an operation identifier, native generation run, post identifier, and delivery identifier as interchangeable.
When is generated content ready for review?
Content is ready for review when the actual selected assets and copy are available and the reviewer has the source context and acceptance criteria. A planning outline or queued job can support progress, but it is not the finished visual package.
When can the agent report publication as complete?
Report publication only when the relevant destination state supports that claim, and distinguish confirmed deliveries from pending or failed ones. A multi-account request can have different outcomes for different destinations.
About Garry
Gaurav Sapkota builds Caroush, a workspace for creating, scheduling, and publishing social content.







