AtelyaOS Docs
Core Concepts

Approval and revisions

How you close the loop on agent output without paying for a full re-run.

Approval and revisions

Approve, revise, or pause. The revision loop is built around presets, not a free-text "do better" prompt.

The 30-second version

When a workroom reaches completed, you review the deliverable and pick: export it, request a revision, or leave it. Revisions are submitted via presets like tighten, add_section, change_tone, or client_feedback — each preset takes structured arguments. A revision costs roughly 40% of the workroom's original credits, with a floor of 5 credits. There is no separate "reject" path.

Why this matters

LLMs are good at producing first drafts and bad at "make it better" prompts. Vague revision requests waste credits and produce regressions. AtelyaOS forces a small amount of structure on the request — a preset and one or two specific arguments — so the Composer has something concrete to act on.

The revision loop is the main reason workrooms exist as a unit: revisions are tracked per workroom, accumulate current_round and final_round numbers, and feed back into the same task graph.

How it works

When you can revise

Revisions are available only when the workroom is in completed state and there is no in-flight revision (revision_in_flight is false). Each round increments current_round. The UI shows a soft warning at round 5+ — there is no hard cap, but if you're on round 6 the brief was probably wrong, not the draft.

Submitting a revision

A revision request has three required parts:

{
  preset_slug: "tighten",     // a slug from the active revision_presets table
  preset_args: {
    instruction: "Cut section 2 to three bullets.",
    target_section: "2",
  },
  source: "internal" | "client_feedback",
}

[SCREENSHOT: revision panel with preset dropdown and instruction field]

Common presets include tighten, expand, change_tone, add_section, remove_section, client_feedback, and custom_instruction. The full list comes from the revision_presets table and may evolve.

Credit cost

Revisions are not metered with a fixed price. Cost is computed as:

revision_credits = max(5, ceil(workroom_total_credits * 0.4))

So a workroom that cost 60 credits to draft costs ~24 credits per revision round. Credits are debited up front; if the LLM call fails, they're refunded.

The Solo / Starter / Pro plans don't enforce a per-deliverable revision cap in code today — every revision is paid out of credits. Marketing copy may quote "2 revisions per deliverable" as a rough budgeting heuristic on Solo, but it is not a hard ceiling.

Approve and export

If the deliverable is good, click Export and pick .docx or .pdf. Exporting does not consume credits. The workroom stays completed and is read-only for further changes (you can still revise, which appends a new round).

What about reject?

There isn't a separate "reject = full redo at no cost" flow. If the first draft is unusable, the cleanest move is Replan (discards non-completed tasks and re-invokes the Planner) and let the Composer run again. That re-uses the workroom's existing inputs but consumes new credits.

Common pitfalls

  • "Make it better." Useless prompt. Pick a preset and write a one-line, concrete instruction: tighten → "Cut section 2 to 3 bullets."
  • Stacking unrelated changes in one revision. One round = one focused change. If you have three independent issues, do three rounds — each one is cheaper than re-running the whole workroom.
  • Revising past round 4 or 5. If you're still revising after five rounds, the brief was wrong. Open a new workroom with a sharper goal.
  • Forgetting that revisions cost credits. They do, even if the LLM call is faster than the original draft. Watch the credit meter on the workroom.

What's next

On this page