Doing the job from the terminal

Everything the console does, the CLI does too. This page is the short version of the four jobs people actually reach for it to do.

Every command here is scoped to a workspace and an app. If you have not pinned them, see Profiles and scoping first, because a correct command against the wrong brand is the most annoying way to lose an afternoon.

Configure the agent

omazy agent show                 # model, status, the essentials
omazy agent brief show           # the current instruction set

Add a prompt to the brief, either inline or from a file. A file is better for anything you would want in version control:

omazy agent brief add --section policy --title "Refunds" --file refunds.md

Test it before anyone else does:

omazy agent test -m "can I get a refund after 40 days?"

Then publish. Until you do, nothing you added is live:

omazy agent brief publish

That sequence is the whole loop, and it is the same loop the console runs. The CLI’s advantage is that refunds.md can live in a repository, get reviewed in a pull request, and be applied by CI. A brief edited in a browser has no history outside the platform.

Feed it knowledge

omazy agent knowledge list
omazy agent knowledge add --title "Refund policy" --file refunds.md
omazy agent knowledge add --title "Hours" --body "Open 9-6, Sunday closed."

If a document was updated and answers still look stale, reindex it:

omazy agent knowledge reindex <doc-id>

The --file form is the one to build habits around. Piping your existing policy documents in beats retyping them, and it means the source of truth stays wherever your team already edits it.

Work the inbox

omazy inbox list --status open
omazy inbox claim <session-id>
omazy inbox messages <session-id>
omazy inbox reply <session-id> -m "Looking into that now."
omazy inbox resolve <session-id> --disposition solved

Hand it to someone else, or raise the alarm:

omazy inbox transfer <session-id> --to <user-id> --note "billing question"
omazy inbox escalate <session-id> --reason "angry customer"

Claim before you reply. Two people answering the same customer in parallel is a worse experience than a slightly slower single answer.

Ship the widget

omazy widget list
omazy widget config get <widget-id> > widget.json
# edit widget.json
omazy widget config set <widget-id> -f widget.json
omazy widget publish <widget-id>

Get the embed code, then confirm it is actually running where you think:

omazy widget snippet <widget-id>
omazy widget verify <widget-id> --url https://yoursite.com
omazy widget domains <widget-id>      # where it has actually loaded
omazy widget metrics <widget-id>

domains is the underrated one. It tells you where the widget has really been loading, which is how you discover it is live on a staging site somebody forgot about, or not live on the page you were told it was on.

Scripting

Use -o json for anything a program reads, and -o quiet when you want bare ids to feed into a loop.

omazy agent show -o json | jq .model

# claim every open conversation
omazy inbox list --status open -o quiet | while read id; do
  omazy inbox claim "$id"
done

Never parse the table format. It exists to be read by people, and its columns are allowed to change in ways that would quietly break a script.