Agent Workflow Architect: who decides what agents may do

An Agent Workflow Architect decides which tasks go to agents, which stay with people, and where approvals sit. They take a messy business process, break it into steps, and write down who or what does each one.

The role is becoming necessary because agents no longer work alone. Teams now run several agents on one goal, and the hard part has moved from making an agent work to making a group of agents and people work together with clear limits.

Few people carry this title yet. The work usually sits inside application engineering, automation or integration jobs, so you will need to look past job titles.

What agents already do

The coordination itself is increasingly automated. Orchestration software assigns work, passes context between agents and checks results. Without it, one agent can score a prospect while the next never sees the score, and people chase each handoff by hand.

Agents also take on defined roles. One published guide describes a pipeline where one agent finds candidates, another scores them against a brief, and a third sends outreach, with each agent holding only the accounts its role needs and leaving its own trace.

In operations, a case study describes a platform team where one-sentence requests hid ten to twenty-five sub-tasks. The pilot split these across specialist agents and kept people in control of high-impact actions.

Job adverts show the same shape. Employers ask for people who can design the orchestration model, the tool-use architecture and the human-in-the-loop protocol, and stand up a sandbox to test it in.

Where agents help and a person decides

Much of the job is shared. An agent can draft a workflow map from process documents, propose a split of tasks, and suggest permission scopes. The architect judges whether the split is sound.

Approval points work the same way. An agent can prepare the case for a reviewer: the summary, the evidence, the proposed action. The person decides. The design question is what the reviewer sees, and what happens when they say no.

An approval step nobody can realistically evaluate is not a control. It is a delay with a signature on it.

Testing is shared too. Agents can generate awkward cases for the sandbox and run them at volume. A person reads the failures and decides whether the fix belongs in the design, the permissions or the process itself.

What still needs a person

Deciding what is safe to delegate. Risk, reversibility and ambiguity are business judgements. An agent can describe them but cannot own them.

Setting permissions. Least privilege means knowing what an agent could do wrong with each tool. Guidance on agent teams points the same way: give each agent the narrowest possible job, especially one that sends as a person.

Making decisions accountable. A workflow that can run is not yet one an organisation can rely on. Teams need ownership, status, permissions, review and traceable outcomes. Someone has to name the owner of each decision.

Understanding how people actually work. Reviewers get tired and queues back up. Spotting reviewer fatigue takes time spent with the people doing the work.

Designing for exceptions. The happy path is easy. The job is categories of failure, escalation paths, owners and stop conditions.

What this means for who you hire

Hire for judgement about limits and handoffs first, then check technical depth. Most candidates are strong in one or two of systems design, security thinking, evaluation and operational understanding. Decide which gap your team can cover.

The profile gaining value is the operations-minded engineer who has redesigned a process end to end and can explain why each step went where it did. Experience with agent frameworks, MCP and workflow engines helps, but it can be learned faster than the judgement.

The profile losing value is the person who automates whatever is technically easy and treats approvals as a box to tick. Another is the prompt specialist who answers every failure with a better prompt. Both describe the happy path well and stall when the work gets awkward.

In the first months, a strong hire should turn one messy process into a written specification that engineers, operations and risk can all read. They should get it running with explicit tool permissions and set up a rollout evaluation showing completion rates, exception handling and who made each decision.

How to spot a strong candidate

Ask them to walk through a workflow they designed. Strong people talk about failure paths, permission limits and reviewer fatigue before you prompt them. Then try these two.

• "Describe a workflow you split between people and automated steps. How did you decide where each task went?" A good answer names criteria such as risk, reversibility, ambiguity and volume, and says what changed after testing. Worry if the split followed only what was easy to automate.
• "Tell us about an approval step that did not work in practice. What did you change?" A good answer covers rubber-stamping, missing context or slow queues, and a fix to what was shown, thresholds or routing. Worry if they only added more approvals.

Where to find them

Start with application engineers who have built tool-calling features, and workflow automation specialists. Add systems integrators who have handled approvals and audit trails.

Platform and internal tooling teams are a good source. So is solutions engineering at companies that sell agent products to enterprises. Adjacent titles are worth searching too: employers advertise for AI workflow architects and AI architects to cover similar ground.

Do not rule out someone without agent experience. An engineer who has rebuilt a process end to end, with its exceptions and sign-offs, often transfers well.

Our own analysis, drawn from the role profile in our job families library and recent public reporting on how agents are used in this work. Titles and practice vary by company.