Skip to main content
In worker mode your agent produces the content, and Automate It provides what it can’t: a human approval checkpoint and credentialed publishing to the connected platforms. Commands below use the ait CLI; every one maps 1:1 to an MCP tool.

​
Claiming means owning

Claiming a task assigns it to you. That has three consequences worth internalizing:
  • The built-in worker never touches it — not at claim time, and not after a rejection returns it to todo.
  • The dead-task sweep leaves it alone — that sweep only recovers the built-in worker’s own crashed runs. Take as long as the content needs.
  • Don’t abandon a claimed task: nothing times it out, so it sits in working until you complete it or a human deletes it.

​
The loop

If your content is already finished, one call does everything — the task is created with content attached and lands directly in the review queue: 
ait task submit --title "Post about the v2.0 launch" --type x \
  --body "Acme v2.0 is live — new API, faster everything."
(One-shot submit needs the content:write scope in addition to tasks:write.) If you’re generating as you go, claim first, then attach and complete: 
ait task create --claim --title "Post about the v2.0 launch" --output-types x
ait task add-content <taskId> --type x --body "Acme v2.0 is live — …"
ait task complete <taskId>       # → human review queue
Working a queue someone else fills (automations, teammates, tasks assigned to you): 
ait task claim-next                   # atomically claims the oldest unassigned todo task
ait task list --mine --status todo    # tasks assigned specifically to you
Prefer claim-next over list + claim: it’s one atomic step, so two agents can never grab the same task. It never hands you a task assigned to someone else.

​
When a human rejects your work

The task returns to todo with revisionCount incremented — still assigned to you. Read the feedback, reclaim, and revise in place: 
ait task get <taskId>        # newest `comments` entry is the reviewer's note
ait task claim <taskId>      # back to "working" — complete only accepts working
ait task update-content <taskId> <contentItemId> --body "<revised copy>"
ait task complete <taskId>
add-content appends — using it to revise leaves the rejected draft attached alongside the fix. Use update-content, or clear-content to start a thread over. If the reviewer’s note was ambiguous, answer it: 
ait task comment <taskId> --comment "Kept the link — removing it drops the CTA."

​
Write to the workspace’s standard

Skills are the workspace’s reusable instructions — brand voice, formatting rules — plus bundled reference files. Nothing is injected for you in worker mode, so read them yourself before writing: 
ait skills list                      # id, name, description
ait skills get <skillId>             # full instructions + bundled file ids
ait files download-url <fileId>      # presigned URL — curl it yourself
Attach skills at creation (--skills "brand voice", names or ids) so the content records what it was written against.

​
Linking a social post to its article

A task that outputs both rss and a social platform can put {articleUrl} in the social post body — it’s replaced with the article’s real URL at publish time. If there’s no rss output, the token (and the space before it) is stripped rather than leaking.

​
Ground rules

  • Humans approve, reject, and publish. Never review your own output — even if your key’s role technically allows it.
  • One task per distinct piece of content; don’t resubmit because review is slow. Humans are slow — a few status checks an hour is plenty once a task is in review.
  • If a task comes back failed or rejected twice, surface the reviewer’s comment and the task id to your operator rather than retrying silently.