Launch your first agent workflow

Choose a job with a visible finish line

Agent Operations is the practice of keeping agent-assisted work useful and repeatable: defining the task, controlling access, inspecting results, recovering from failure, and improving the process. Start with one job whose output a person can judge. “Run marketing” is too broad. “Prepare a weekly draft briefing from these five approved sources” has a clear boundary.

Pick a frequent, reversible task with known inputs. Record how a person completes it today and how long review normally takes. This gives you a baseline rather than a promise of savings.

Name the person accountable for the output.
Specify the input folder, source list, or system of record.
Define one deliverable and where it should be saved.
State what the agent must not do: for example, send, publish, delete, or spend.

Write the contract before the prompt

A workflow contract should be readable without knowing which model will run it. Include the trigger, allowed tools, output format, review gate, budget, and stop conditions. Put reusable instructions under version control so a change can be reviewed and reversed.

A skill stores reusable guidance; a schedule starts work; a permission policy restricts access. They serve different purposes. A sentence telling the agent to ask permission is not a substitute for a runtime control where that control exists.

Job: Weekly source briefing
Input: approved-sources.md
Output: drafts/YYYY-MM-DD-briefing.md
Done: every claim has a source; links open; editor has reviewed
Boundary: write drafts only; no email or CMS access
Stop: source unavailable, conflicting evidence, or budget reached
Owner: assign a named reviewer before the first run

Run a supervised pilot

Use a copy of realistic input with sensitive details removed. Watch the first run and save the output, tool failures, elapsed time, and review notes. A completed process is not necessarily a useful result: compare the deliverable with your contract.

The briefing example is illustrative, not a reported customer result. Test it on your own sources and permissions.

Try a normal input, a missing input, and a conflicting input.
Check that forbidden actions are unavailable or blocked.
Record every intervention, including manual fixes.
Change one part of the workflow at a time and rerun the same cases.

Schedule only after the output is repeatable

Choose a cadence that leaves enough time for review. Keep a single accountable owner and a visible place for failures. Start in draft-only mode; expand access only when the job needs it and the evidence supports it.

Your first success metric can be simple: accepted outputs divided by attempted runs, alongside review minutes per accepted output. Keep measuring after you change the harness, model, instructions, or tools.

Sources and further reading

These guides combine linked documentation with our suggested operating practices. Examples are illustrative; they are not customer results or harness benchmarks.