Write procedures agents can follow
Updated October 30, 2026. Educational guidance; use current official documentation and your installed version.
A good SOP turns a repeated success into a bounded, verifiable process. It is not a long motivational system prompt.
Include these sections
- Trigger: what new evidence starts the work, and what does not.
- Scope: exact account, project, course, date window, and allowed sources.
- Inputs: authoritative records and how to resolve conflicting versions.
- Procedure: dependent steps in order; separate independent work where useful.
- Permissions: read, draft, save, send, and publish boundaries.
- Verification: read back the result in the source system; record what remains untested.
- Retry rules: stable request IDs, duplicate checks, backoff, and uncertain-result handling.
- Completion: artifact location, next owner, and what counts as done.
- Budget: maximum batch size, model runs, duration, and escalation limit.
- Expiry: when to disable or review the workflow.
Example: a student email
Trigger: a new message from a verified current-course participant.
Read the complete thread, current course rules, Sent Items, and Drafts.
Research the actual question; do not infer extensions or assessment policy.
Prepare one concise source-linked reply, with verified recipient and encoding.
Save only. Do not send or change grades.
Record drafted, already answered, or blocked separately.
Do not reprocess an unchanged thread or create duplicate drafts.
Test with synthetic records before using identifiable records. Include failure cases: unavailable account, ambiguous recipient, changed submission attempt, existing draft, and a timeout after a save.
Keep codebase-specific details in that repository's docs. Keep reusable workflow instructions in a skill or SOP. Store credentials in neither.