What decides whether an AI workflow survives inside a real company is where you put the human. The model matters less than people expect, and the prompt matters less still. Put the human in the wrong place and the workflow gets demonstrated once, admired, and quietly abandoned, and everybody blames the technology.
I do product marketing without a team, and over the past year I have built several of these. The ones described here are the ones still running. The difference between those and the ones that died was never the model. It was the gate.
A gate is a point where the work stops and waits for a named person to act. This article is about where that point belongs, what it has to show you when you get there, and what happens when you put it in the wrong place, which I have also done.
What a gate is, and what it is not
A gate is a stop. The work does not move until a person acts. Everything before it belongs to the agent, everything after it belongs to you, and the whole design question is where to draw that line.
A notification is not a gate, because the work continues whether you read it or not. A logged audit trail is not a gate, because it tells you what already happened. A checklist somebody is supposed to run is not a gate either, for the same reason a policy is not a lock.
Three properties separate the gates that survive from the ones that get switched off, and each of the systems below is one of them.
The agent that is allowed to produce nothing
The first property is that a gate can be the entire product.
The inbox agent reads the day's email and produces no work at all. It sorts each message twice. First by which product the message concerns, then by what is actually being asked for, using the categories that genuinely recur: a custom pitch deck, a one-pager, a case study, an RFP document, access to decks in Highspot, and miscellaneous.
For each message it gives me a summary, tells me whether I need to act, and if I do, what the action is. When the ask is a custom pitch deck, it also hands me the link to that product's existing deck and the customisations being requested. A one-pager works the same way. When there is no reference material to point at, it skips that step rather than inventing something to fill it.
That is the whole system. It writes nothing, sends nothing and changes nothing. Its only output is a decision about what deserves my attention, which is the same decision a stream of last-minute requests forces you to make badly, one message at a time, all day.
Go one level up. This is the cheapest workflow to build and the one people skip, because it produces nothing you can put in a demo. An agent that drafts a reply is a demo. An agent that tells you which replies are yours to write is a habit.
It was not good at first. Sorting the type of ask was easy; working out which product a thread was about was the hard part, and it got that wrong often enough to be annoying. Retraining it across a couple of months brought the failure rate down a long way.
I still open messages at random to check it, even when the summaries look right. That is not diligence, it is a countermeasure. Parasuraman and Manzey reviewed the research on how people supervise automated systems and found that complacency turns up in expert operators as readily as in beginners, that it takes hold specifically when other work is competing for the same attention, and that it cannot be prevented by training or instructions. Human Factors, 2010 Their setting is cockpits and control rooms rather than an inbox -- but the condition they describe, a person supervising something automatic while doing several other jobs, is the condition every solo operator works in.
So deciding to pay closer attention is not a plan. If you want to find out when an agent has started being wrong, the checking has to be structural: a few opened at random, whether or not anything looks off.
Show the thing, not a description of the thing
The second property is that a gate has to show you the finished work in the form it will actually take.
The social agent sends one email covering seven days. Every creative is attached. The copy for each sits in the body of the email with its link and its hashtags, exactly as it will go out. And there is an HTML rendering that shows how the post will look on LinkedIn once it publishes.
That rendering is the gate. Everything else in the email is a list. Approving a paragraph of copy means approving a paragraph. Looking at the rendering means seeing what somebody scrolling will see: where the text truncates, what the image does at that size, whether the first line survives the fold. Those failures cannot travel inside a description, and they are most of the failures.
This system took the longest to get right, and the reason was scope rather than gating. It was built to speak to more than one kind of buyer through a single post, and that confused it for a long time. Settling what the asset should look like and which brand rules it had to follow took far more rounds than building the publishing step ever did.
The gate goes where the work stops being reversible
The third property decides placement, and it comes from one question: what is the first step you cannot take back?
Most custom pitch deck requests are not requests for a new deck. They are requests for the same slides in a different order, arranged around the story one particular buyer needs to hear. That is real work, it is most of the volume, and it needs almost none of my judgment until the last step.
So the agent does all of it. From the thread and the email it works out which product is being discussed, which deck is being referred to, and what is being asked for. It pulls the relevant slides out of the decks that already exist, builds a new presentation, and sends it to me. Then it stops.
I approve it, and I put it into Highspot myself.
That last sentence is the entire design. Building a deck is reversible, and a bad one costs only the time it took to make. Putting a deck into the library, where a rep will find it and carry it into a meeting, cannot be taken back, because you cannot unsee a version a customer has already been shown. The gate belongs between those two steps, and the agent gets everything on the cheap side of the line. Put the gate where the cost of being wrong stops being yours.
Worth saying that reordering slides is not a small thing to hand over. A deck assembled in the wrong order is beautiful and useless in the specific way that a rep discovers on a call rather than in the file. The approval step is short because the agent does the assembly, and I am reading for the story rather than for the slides.
The gate I got wrong
The content system is where I put a gate in the right place and had it check the wrong thing.
Its gate asked whether the writing read as though a person had written it. That sounds like a quality bar and it functions like nothing at all, because the question has no answer a machine can produce, and on a bad day it had no answer I could give consistently either. A description of the result you want is not a gate. It is a wish standing where a gate should be.
What fixed it was not a better prompt. I sat down with a working writer and we wrote out the process a person actually follows when they write something: the order the decisions get made in, what has to be settled before a sentence is drafted at all. Then the agent followed that process, instead of chasing a description of the finished thing. The gate stopped asking "is this good" and started asking whether each step had been done.
The same system had a second and larger problem, which was that the score it gave its own writing was measuring the wrong thing entirely. The two failures are related. Both came from trying to judge an output rather than instrument the work that produces it.
Six checks on a workflow you are about to build
Run these against anything you are building, or anything you built that has quietly stopped being used.
- Write down the first step you cannot take back. Sending, publishing, posting, filing, paying. That step is where the gate goes, and everything before it belongs to the agent.
- Ask what the gate puts in front of you. If it shows a description of the work, replace it with the work itself, in final form. A rendered preview beats a paragraph of copy, and a built deck beats a summary of what the deck would contain.
- Time the gate. If clearing it takes longer than doing the task yourself would have, the gate is in the wrong place or the agent has been given too little to do. The ones I run take seconds, sometimes a couple of minutes.
- Let an agent produce nothing when nothing is what is needed. The highest-return workflow I run creates no artifact at all.
- Keep a sampling check on the systems you have stopped watching. Open a few at random even when the output looks right. Retraining drives the failure rate down and never to zero, and you want to be the one who finds the remainder.
- If a gate is checking a description of quality, replace the description with a process. "Make it good" is not a gate. The steps a competent person follows are.
Where this leaves you
One thing I do not know is how much of this survives a team. Every gate here ends at me, which makes them cheap, and a gate that ends at somebody else is a queue with a person's calendar attached to it. I have never run one of these where the approver was not the person who built it, so treat the placement rule as sound and the cost estimates as mine alone.
If you have an AI workflow that got built and then stopped being used, the model is probably fine. Look at where the human is standing. Usually they are at the far end, being asked to approve a summary of something they cannot actually see, for a step that could have been undone anyway.
Move them to the edge of the irreversible thing, and show them the real thing when they arrive. That is the design. The agent is the easy half.