Building an agentic workflow that works is the part people expect to be hard. Then comes the next conversation: the one where it has to be allowed to run somewhere that is not your laptop.
Most of what is written about that conversation is written for the person on the other side of the table - the security lead with a seven-gate approval checklist. This is for the person asking. The questions are predictable, and turning up with the answers written down changes the meeting from a request into a review.
What IT and security will ask
What does it touch? Every system, folder, inbox and tool the workflow reads from or writes to. Be specific. “Our shared drive” is a worry; “one folder of supplier reports, read only” is an answer.
Whose access does it use? A workflow running on your personal login can do everything you can do, which is far more than it needs. Expect to be asked for access scoped to the task alone.
What can it do without asking? Reading and drafting are one conversation. Sending, deleting, paying or changing records are another. If anything irreversible sits behind a human checkpoint, say so up front.
Which tool, and is it approved? Check your organisation’s list before the meeting, not during it. A workflow built in an unapproved tool is a rebuild, however good it is.
How would you stop it? Who can switch it off, and how quickly. The honest answer “I would turn off this one connection” is more reassuring than any description of how carefully it was built.
What legal and data protection will ask
Whose information goes through it? Your own drafts and internal material are one thing. Named customers, staff records or anything about identifiable people is another, and data protection law applies to it however clever the workflow is.
Which terms govern the tool? Whether the provider can use your inputs for training and how long material is kept depends on the exact plan your organisation pays for. Read those terms first, and bring the relevant sentences rather than a summary of them. The same questions come up for anything you store for AI to read.
Does a client contract say anything? Material a client gave you is governed by your agreement with them, not by your AI plan. If it is under a confidentiality clause, that clause decides.
Who is accountable for what it produces? Someone has to own the output. “The workflow” is not an answer anybody in legal will accept.
What your manager will ask
What does it replace? The task, how long it takes now, and how often. Hours a week is the clearest currency, and it is the same number you need to judge whether a pilot worked.
What counts as better? Faster, fewer errors, or simply no longer the job nobody wants. Decide before it runs, so the judgement afterwards is not a matter of opinion.
Who owns it, and what happens when they are away? A workflow only one person understands is a single point of failure with a nicer interface. Name a second person who could run it, or at least switch it off.
How would you know it had gone wrong? Agentic workflows fail quietly, so “I would notice” is not enough. Name the check.
Put it on one page
All of the above fits on one page, and writing it is most of the work. A single note covering what it touches, whose access it uses, what it can do unasked, whose data flows through it, what it replaces and who owns it lets all three conversations happen at once rather than in sequence.
Start with the smallest version that still earns its keep. A workflow that only reads and drafts, with a person sending the result, is far easier to approve than one that acts on its own. You can widen what it is allowed to do once it has a track record.
Where this gets practical
The security and stakeholder questions that decide whether a workflow sticks are part of the Oxford Agentic Bootcamp curriculum, alongside building one. You bring one real task, build the workflow against it, and leave with a concrete plan for introducing it where you work. Cohort 3 runs on 19 November at Worcester College. No coding required.