A two-week rollout plan for shipping agents safely

Why two weeks

Two weeks is long enough to discover what the workflow actually is, and short enough that you cannot build a platform. Both constraints are the point. Teams that give themselves a quarter build infrastructure first and find out in month three that the workflow they automated was not the one anyone needed. Teams that give themselves a day skip the part where the agent proves itself read-only, and the first incident arrives before the first win.

The plan below assumes a small team, one workflow, and tools you already pay for. It does not assume a platform team, a vector database, or a budget line for "AI infrastructure."

Week 0: define the workflow and the metric

This is a few hours, not a week, but it happens before the clock starts. Pick one workflow that is recurring, bounded, and currently done by a person who would rather not. Inbound request triage. Weekly report assembly. Renewal follow-ups. Pull request first-pass review. If you cannot describe the workflow in four steps, it is two workflows; pick one.

Then write down the metric before you write any code. Not "saves time." Something you can count on Friday: hours of human review per week, median time from request to first response, percentage of items the agent handled without a correction. The metric decides whether week two happens. Without it, the project runs on vibes, and vibes always say "promising."

Finally, write the permissions matrix. One row per tool the agent will use, one column each for read and write, and a note on which resource. In week one, every write cell says no.

Week 1: narrow scope, strict tools, human checkpoints

Ship the agent read-only on day one. It reads the inputs, produces a draft of whatever the output is, and stops. A person reviews every draft and either uses it or corrects it. Record both.

Three rules for this week:

Strict tools only. The agent gets the three or four tools the workflow requires, as typed functions, with the inputs and outputs logged. No general shell, no "browse the web," no open-ended file access. If the agent needs a tool you did not anticipate, that is a finding, not a reason to widen scope mid-week.

Every output is a draft. Even if the draft is perfect, a human sends it. The approval step is doing two jobs: preventing harm, and generating the correction data you will use to judge the agent on Friday.

Log the corrections. Each time a person edits a draft, capture the before and after. By Friday you have a labeled dataset of where the agent is weak, produced as a byproduct of normal work.

End of week one, look at the metric and the corrections. If the agent is right less than about seventy percent of the time with no pattern in the failures, stop and rethink the workflow or the inputs. If it is right most of the time and the failures cluster, you have a week two.

Week 2: automation, monitoring, rollback

Now, and only now, the agent gets to act. Not on everything. On the slice where week one showed it was reliably right, and only where the action can be undone.

Automate the easy slice. Flip the write cell for the one tool that covers the high-confidence cases. Leave the human checkpoint in front of everything else. The pipeline becomes: triage automatically, draft automatically, execute automatically for the confident cases, route the rest to a person. Most teams find the confident slice is half to two-thirds of volume, which is most of the time saved for a fraction of the risk.

Monitor what matters. Three signals: volume per day, the ratio of automatic to human-routed items, and anything that started but never reached a terminal state. That last one is the quiet killer. An item that is neither finished nor failed is a bug that has not announced itself yet. Alert on it.

Build the rollback before the first automatic write. Snapshot before each change, soft-delete instead of hard-delete, an idempotency key so a retry does not duplicate the action, and a kill switch that returns the agent to week-one behavior with one flag. If the rollback takes more than a minute to execute, it is not a rollback, it is a recovery project.

The example we keep coming back to

Inbound support triage. Week 0: the metric is median time to first useful response, and the permissions matrix lists read access to the inbox and the knowledge base, nothing else. Week 1: the agent reads each new message, classifies it, drafts a reply, and stops. A person approves or edits every one. Week 2: billing questions and password resets, which week one showed were handled correctly nearly every time, go out automatically. Everything else still lands in the queue with a draft attached. The team's measured time to first response drops from hours to minutes for most of the volume, and the hard cases get a human faster because the easy ones are gone.

Triage, draft, approve, execute. The shape is the same for report assembly, renewal follow-up, and first-pass code review. Only the tools change.

Three failure modes, and how to avoid them

Write access on day one. The agent sends something it should not have, trust collapses, and the project is cancelled before it demonstrates value. Avoided by the week-one rule: every output is a draft, no exceptions, even when it feels slow.

Silent success. The dashboard shows green, nobody checks the outputs, and a month later it turns out the agent has been quietly wrong on a category nobody sampled. Avoided by monitoring terminal states and by keeping a sampled human review on the automated slice even in week two. Ten percent, forever.

Nobody owns the loop. The agent runs, but when it drifts there is no one whose job it is to notice. Avoided by naming an owner in week zero and giving them the Friday metric as a recurring calendar item. An agent without an owner is a cron job with opinions.

What you do not need

You do not need a platform team, an orchestration framework, or a memory layer on day one. You need one workflow, one metric, a permissions matrix that starts at read-only, and the discipline to leave the human checkpoint in place for a full week. The infrastructure can come later, once you have an agent worth building infrastructure for.

If you want help picking the first workflow or writing the permissions matrix, tell us what your team does every week and we will point at the one to start with.