← All writing

Essay · AI enablement

From pilot to production: an adoption playbook for agent workflows in a marketing team

Most AI pilots do not fail on capability. They fail on ownership. This is the gate I use to move an agent workflow from a good demo to work a team depends on.

Essay · Published October 18, 2026 · Updated October 24, 2026

Why pilots stall

The typical marketing AI pilot dies in the week after the demo. Someone pastes a month of coverage into an agent, gets a credible executive summary in minutes, and the room is sold. Ninety days later the person who built it is the only one using it, and only when they remember.

Three management decisions are never made.

  • The pilot is judged on the demo. A demo answers one question: can the tool produce a good output on a good day? It says nothing about the fortieth run, or the week the builder is on vacation.
  • Nobody owns the output. The builder owns the prompt. The team owns the old process. When the agent gets something wrong, noticing is nobody's job.
  • The build is treated as the finish line. Shipping the workflow feels like the accomplishment. It is the starting point of an adoption problem nobody has scoped.

So I use a strict definition. An agent workflow is in production when people other than its builder depend on its output, on a schedule, and would notice within a day if it stopped. Everything short of that is a pilot, however impressive the demo.

Getting from one state to the other takes a gate. The workflow passes when it has a named owner, a human review checkpoint at every decision point, and a weekly cadence that tracks hours returned. Until all three exist, keep the old process running beside it.

Experiment freely, then gate

The fair objection is that owners, checkpoints and cadence slow everything down, and that teams learn AI by playing with it. For pilots, I agree. Years ago I argued in Think Like a Startup that established companies should test assumptions cheaply and rapidly before committing major resources. That is exactly what a pilot is for. Most experiments should die quickly and without paperwork.

The gate applies at one moment only: when someone else is about to depend on the output. That is when failure stops costing only the experimenter, and when an unowned workflow starts to fail quietly. Change of this kind can be the catalyst for immense success or supreme failure, a point I made in a change management reading list for Rhythm Systems; the rhythm has to be set early.

Choose the workflow before the tool

Teams that start with a tool go looking for problems it can solve. Before anyone opens an agent builder, write the current process down as steps, inputs and handoffs, the same discipline I described for structuring asynchronous workflows that replace status meetings.

Then test the candidate against four criteria. It needs all four.

Selection test for a first production workflow
CriterionTest questionDisqualifier
RepetitiveDoes it run at least weekly, in roughly the same shape?A quarterly or one off project
MultistepDoes it pass through several steps where time is lost between them?A single prompt that saves two minutes
Named consumerCan you name the person who receives the output and acts on it?Output that goes into a folder nobody opens
Measurable baselineCan you time how long it takes today, per deliverable?Nobody knows, and nobody will log it

At Fullintel, the four functions I rebuilt as packaged agent workflows were executive reporting, competitive intelligence, PR opportunity response and search optimization. Treat those as category examples. Yours will depend on where your team spends its hours.

In knowledge businesses, payroll is the largest expense, which is why I wrote about measuring return on payroll as a management discipline. An agent workflow does not cut a software bill. It redirects payroll hours. Pick the workflow that consumes the most skilled hours on work that does not need the skill.

Owners and review checkpoints

This is the core of the method, and it is team design, not a product decision.

One owner per workflow

Every production workflow gets exactly one named owner. Not a committee, not marketing, and not automatically the person who built it. The owner is accountable for four things:

  • The quality of what the workflow releases.
  • Every change to its prompts, sources or configuration.
  • Staffing each review checkpoint, including cover when reviewers are out.
  • Retiring the workflow when it stops earning its place.

If the owner leaves, the workflow drops back below the gate until a new owner is named.

Map the decision points

Next, list every point where the workflow makes a choice a person used to make. There are more than the builder thinks: which sources to include, what counts as relevant, what the summary claims, how it sounds, whether it ships. Each gets a checkpoint where a human looks before the work moves on.

A checkpoint is useless unless it says what the human checks. Here is the map for an illustrative competitive intelligence brief. The specifics are hypothetical.

Illustrative checkpoint map for a weekly competitive brief
Decision pointCheck typeWhat the reviewer confirms
Sources gatheredAccuracyRight competitors, right date range, nothing obviously missing
Items ranked by relevanceJudgmentThe top items are the ones a seller or executive would actually care about
Summary draftedAccuracyEvery factual claim traces to a source in the set
Implications writtenJudgmentThe "so what" is defensible and not inflated
Final draftToneReads like the team, fits the audience
DistributionReleaseThe owner or a named delegate approves sending

Four check types cover nearly everything: accuracy, judgment, tone and release. Write the reviewer's name next to each one. One person can hold several; no decision point passes unexamined.

I have argued publicly that hybrid analysis beats automation alone in media intelligence, and writing about how human expertise shapes an AI system sharpened one question I now ask of every pipeline: where exactly does expertise enter? The checkpoint map is the answer, written down. It is also the answer to the objection that review slows adoption. Checkpoints are where trust gets built. A team that has watched a reviewer catch a wrong number at the accuracy check will rely on the output. A team that has never seen a check will quietly redo the work by hand, and your adoption figures will lie to you.

This is the structure I used at Fullintel: packaged agent workflows with human review checkpoints built into every decision point, then adoption led across marketing, analyst and client facing teams rather than treating the build as the finish line.

Guardrails before scale

Data and disclosure rules are cheap to set for five users and expensive to retrofit for fifty. Settle them before the rollout widens, on one page, in plain language. Three questions cover it.

What data may enter a tool?

Sort information into tiers and name examples in each, because people follow examples, not definitions. Public material, such as published articles and press releases, can go anywhere. Internal material, such as plans and drafts, goes only into tools the company has approved. Restricted material, such as customer data, personal information, contracts and anything under confidentiality terms, stays out unless a named approver has cleared that specific tool for that specific use. The risk is not abstract. As I wrote in Is Your Information Safe?, AI is already embedded in daily work, and so is the risk of exposing sensitive information through it.

When is AI use disclosed?

Decide in advance which outputs carry a disclosure and to whom: content published under the company's name, deliverables a customer pays for, and anything presented as original analysis. The case for AI disclosure and usage policies is that they preserve integrity and trust. A rule written before the first awkward question is policy. After, it is damage control.

Who approves exceptions?

One person, named, with a written record of each exception. Exceptions will come, usually from your best people. A named approver keeps the answer fast and consistent, and the record shows you when a rule needs to change.

Adoption on a cadence

A launch is an event. Adoption is a rhythm, managed the way a good leadership team manages quarterly priorities: few measures, a fixed schedule, clear owners.

One critical number per workflow

Give each workflow a single critical number, the one measure that tells you whether it is doing its job. For most marketing workflows it is hours returned per week. For some it is cycle time from request to delivery. A dashboard of twelve metrics gets glanced at. One number gets discussed.

A weekly review, fifteen minutes

Put every production workflow on an existing weekly agenda rather than creating a new meeting. The owner reports three things: the critical number against last week, what the checkpoints caught, and any change to prompts, sources or reviewers. A workflow whose reviewers never find anything is either excellent or being rubber stamped, and the owner should know which.

A retrospective at every stage change

Move workflows through explicit stages: pilot, limited use by the owner's own team, full team, and cross team. Hold a retrospective each time one moves: one to two hours, immediately after the change, so the team converts what went right and wrong into practices it reuses. It is also where you decide a workflow should go back a stage or stop.

Tell people early what changes for them

The people whose work an agent touches will fill any silence with the worst interpretation. In communicating a merger to employees, the failure I described was that preparing people is often an afterthought. AI rollouts repeat the mistake. Before a workflow moves to a new team, tell that team what will change in their week, what will not, which checkpoints they will staff, and where the returned time is meant to go.

Measure hours returned and where they went

Hours returned ties directly to payroll, the cost you are redirecting. It is also the easiest number to inflate. This method keeps it honest.

  1. Baseline. Before the workflow goes live, time the manual process per deliverable for at least two cycles. Use logs, not memory.
  2. Volume. Count deliverables per month, and count again after launch, because cheaper work tends to generate more requests.
  3. After time, in full. Measure generation time plus review time at every checkpoint plus rework. Leaving out review time is the most common way these numbers get overstated.
  4. Hours returned. Baseline minus after time, multiplied by volume. Annualize only after three months of stable data.
  5. Destination. Record where the returned hours went, by name: which person, which higher value work.

An illustration with invented round numbers: a report takes six hours by hand and runs eight times a month. With the agent, generation takes one hour, review across the checkpoints takes an hour and a half, and rework averages half an hour. After time is three hours, so the workflow returns three hours per report, or 24 hours a month. Without the review time it would look like five hours per report, and the number would be wrong by two thirds.

The fifth step matters most. If you cannot say where the returned hours went, they were not returned. They were absorbed into meetings and email, and the workflow will look like a cost when budgets tighten. Assign the hours before launch, to expert analysis or client work, and report the destination in the weekly review.

For what this method produced in practice, including turnaround times and the hours figure, see the adoption case study. This essay is the how; that page is the what.

First 30 days

Do not start a program. Start one workflow, and run it through the gate in a month.

  • Week one. Pick the workflow using the four criteria. Name its owner. Start timing the manual baseline.
  • Week two. Write the process down as steps. Map every decision point and name a reviewer and check type for each. Draft the one page of data, disclosure and exception rules.
  • Week three. Run the workflow in parallel with the manual process. The owner reviews every output at every checkpoint and logs generation, review and rework time.
  • Week four. Put the critical number on the weekly agenda and hold the first review. Run a retrospective and decide whether the workflow passes the gate. If it does, retire the manual process for that deliverable. If not, name the gap and set a date.

Handing a workflow to a new user

When a workflow moves to a new user or team, the enablement lead runs the handoff the same way every time. The owner walks the new user through the checkpoint map and the one page of rules. The new user runs the workflow for two cycles with the owner reviewing alongside. Then the new user runs it alone, with every checkpoint still in place and their name now written next to the ones they staff. Training ends when the map is updated, not when the session ends.

At the end of the month you will have one workflow that a team depends on, a named owner, a checkpoint map, a page of guardrails, a baseline and an honest hours number. That is more than many pilots ever reach.

Sources