# Doing the job from the terminal Configure the agent, feed it knowledge, work the inbox, and ship the widget, without opening the console. Source: https://docs.omazy.ai/reference/cli/workflows/ 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](/reference/cli/profiles/) first, because a correct command against the wrong brand is the most annoying way to lose an afternoon. ## Configure the agent ```sh 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: ```sh omazy agent brief add --section policy --title "Refunds" --file refunds.md ``` Test it before anyone else does: ```sh omazy agent test -m "can I get a refund after 40 days?" ``` Then publish. Until you do, nothing you added is live: ```sh 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 ```sh 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: ```sh omazy agent knowledge reindex ``` 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 ```sh omazy inbox list --status open omazy inbox claim omazy inbox messages omazy inbox reply -m "Looking into that now." omazy inbox resolve --disposition solved ``` Hand it to someone else, or raise the alarm: ```sh omazy inbox transfer --to --note "billing question" omazy inbox escalate --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 ```sh omazy widget list omazy widget config get > widget.json # edit widget.json omazy widget config set -f widget.json omazy widget publish ``` Get the embed code, then confirm it is actually running where you think: ```sh omazy widget snippet omazy widget verify --url https://yoursite.com omazy widget domains # where it has actually loaded omazy widget metrics ``` `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. ```sh 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.