What to send before an agent-assisted operations sprint

An agent-assisted operations sprint should not begin with model selection. It should begin with the material needed to build one workflow a team can actually run.

The difference matters. A vague sprint starts by arguing about tools. A useful sprint starts with examples, a reviewer, a boundary, and the operating rule for what happens when the system is wrong.

Use this packet when the workflow has already passed the basic readiness test: it repeats, the source material exists, and someone can approve the output. If those pieces are still fuzzy, start with an audit first.

1. One workflow and one owner

Pick the workflow the sprint will build around. Do not bring a department backlog and ask the sprint to “find the AI opportunity.” That is audit work.

Write the scope in one sentence:

When [input arrives], we need [reviewable output] so [owner/team] can [decision or action].

Examples:

• When a qualified lead enters the CRM, we need a cited research brief so sales can decide whether to follow up.
• When a vendor PDF arrives by email, we need extracted fields with source references so operations can approve or correct the record.
• When a support ticket arrives, we need triage, risk flags, and a draft response so the support lead can review before sending.
• When weekly updates land across tools, we need a briefing with changes, blockers, and open questions so the owner can decide the next action.

Name the workflow owner. They are not a stakeholder in theory. They are the person who can test outputs, approve review rules, and say whether the sprint result is useful enough to keep.

2. Ten real examples, including ugly ones

Bring recent examples of the workflow as it happens now. Sanitized examples are fine. Polished examples are less useful.

A good set includes:

• five normal cases that show the main path;
• three messy cases with missing fields, unclear source material, or bad formatting;
• two edge cases that should escalate instead of producing a final answer.

For each example, include the current human output if it exists: the lead note, ticket decision, copied fields, briefing, reply draft, or escalation comment.

The sprint is not using those examples as magic training data. It uses them to define the artifact, test the rules, and catch the places where a confident answer would be dangerous.

3. Source systems and safe access path

List every system the sprint needs to read or write. For each source, state whether the first build can use an export, a test account, a sandbox, an API key, a shared folder, or a static sample.

Use a table like this:

Do not hide access constraints. If production API access is not approved, say that. A useful sprint can still build around static samples or a sandbox. Pretending access exists only creates fake velocity.

4. The review rule before launch

Write the rule for what the workflow may do and what it must not do.

Useful examples:

• May draft a customer reply, but may not send it.
• May classify urgency, but may not promise a refund, credit, or delivery date.
• May extract document fields, but may not overwrite the source record without approval.
• May summarize source changes, but may not invent context missing from the cited sources.
• May suggest a lead score, but may not enroll the contact in outbound sequences.

This review rule is part of the build, not compliance decoration. It shapes the UI, queue, logging, error messages, and handoff notes.

5. Exception cases and stop conditions

The main path is cheap to demo. Exceptions decide whether the workflow survives.

Before the sprint starts, write the cases that should stop automation:

• missing required fields;
• conflicting source records;
• low-confidence extraction;
• angry customer, legal threat, refund request, security issue, or sensitive personal data;
• request outside the approved geography, product, policy, or workflow scope;
• source material that is stale or cannot be cited.

For each stop condition, state the fallback: route to owner, request more information, mark as unverified, or hold for manual review.

A good first workflow does not solve every exception. It recognizes enough of them to avoid acting like a reckless intern with admin access.

6. Launch surface and maintenance owner

Decide where the workflow will live before the sprint builds it.

Options include:

• a spreadsheet or Airtable-style review queue;
• a CRM note or task draft;
• a helpdesk side panel or internal queue;
• an email draft folder;
• a dashboard or report page;
• a Slack/Discord-style internal handoff message;
• a small internal web form.

Also name who owns maintenance after the sprint. Someone needs to review misses, approve rule changes, update prompts or extraction fields, and decide whether the next slice is worth building.

If nobody owns maintenance, the sprint should end with a prototype and a warning, not a production promise.

7. A simple sprint input packet

Send this before the sprint starts:

Workflow name:

One-sentence scope:

Workflow owner / reviewer:

Current input source:

Desired reviewable output:

Ten recent examples or safe samples:

Current human output for those examples:

Systems involved and safe access path:

What the workflow may draft, classify, extract, route, or summarize:

What the workflow must not send, decide, overwrite, or promise:

Known exception cases and stop conditions:

Launch surface for the first build:

Maintenance owner after the sprint:

Signal that would make the sprint worth continuing:

That packet is enough to start building without pretending the first sprint is a transformation program. It narrows the work to one operating slice, one artifact, one review gate, and one maintenance owner.

If you cannot fill the packet yet, do not force a sprint. Request an audit and turn the missing pieces into the first deliverable. The unglamorous boundary work is what keeps the later agent work from becoming a mess.