How to volunteer for an AI agent pilot as a business analyst

Offer to write what every pilot is missing: the process map, the agent's bounds and the list of real cases it must pass. Approach the pilot sponsor with a one-page outline of the process you would map and the measures you would track. A business analyst who owns the definition of success usually ends up owning the operation.

What does a bank's agent pilot need from an analyst?

Retail banking pilots tend to start in servicing or complaints: drafting replies to account queries, preparing standing order changes, summarising complaint files for a case handler. The sponsor, often a head of operations, owns the outcome. The technical team configures the agent. The gap in between is analysis: what exactly is the job, where does it start and stop, what must never happen, and how will anyone know it works?

That gap is your trade. In a governed setup, the agent's job is written down in plain language, its sources are named, and its authority is earned on the bank's own cases rather than switched on. Someone has to write that job, choose those sources and choose those cases. The guide to AI agent jobs and careers describes how that work becomes a permanent role.

How do you make the offer?

1. Find the sponsor and the date reviewers and analysts are chosen. Pilots often staff up quietly; ask early.
2. Pick the process you know best and sketch it on one page: inputs, decisions, exceptions, hand-offs, and where money moves.
3. Mark the red lines. In servicing, they include changes to contact details without verification and anything that pays out on the strength of an emailed document.
4. Propose three measures you would track, and say where the data comes from.
5. Offer a fixed commitment, for example two days a week for the length of the pilot, and say what you will hand over.
6. Send it. The email template to volunteer for an AI agent pilot works; attach the one-page sketch.

What will the pilot workflow look like once you have mapped it?

Your map should make each step's depth and owner explicit, like this.

1. Agent, depth 1: reads the request, the customer record and the procedures it is allowed to use.
2. Agent, depth 2: drafts the reply or change. The procedures library is sealed; a customer's account of events is declared; an attachment from outside is external.
3. Person (servicing reviewer): approves, edits or holds each draft.
4. Agent, depth 3: completes routine changes within limits once certification on the bank's past cases supports it.
5. Agent, depth 4, held: prepares refunds or fee reversals above the bank's limit and holds them.
6. Person (authorised approver): releases held money movements.
7. You: read the filed verdicts weekly and turn patterns into changes to the brief, sources or limits.

Which controls will you design, and what evidence do they leave?

• The case set for certification. Certification replays the agent against real cases and scores every answer. If the case set is all easy cases, the result means little. You choose a set that includes complaints, vulnerable customers and edge cases. Evidence: the case list and the certification result.
• Limits. You propose the customer's own limits per capability. Evidence: the approved limit table.
• Escalation rules. You define what goes to fraud, to complaints and to a vulnerable-customer team. Evidence: escalations in the record.
• Change control. Every change to the brief or sources has a reason and an approver. Evidence: the change log.

In a product such as Agent Studio, the brief is assembled from a plain-language description of the job, which is exactly the document an analyst is used to writing.

What should you measure?

Measure whether the agent is earning its authority: how often reviewers change drafts, which bound decides most refusals, how long held items wait, whether certification results improve after changes, and whether any red line was missed. Pull these from the filed verdicts, not from a survey of opinions. Agree a baseline before the agent goes live, such as how long the same requests took and how often they were reworked, so that any change can be shown rather than asserted. A measure without a baseline invites argument at the review.

Where do analysts go wrong on pilots?

• Writing requirements and walking away. The value is in reading the record afterwards and changing the agent.
• Treating depth as a setting. Depth comes from evidence on real cases; a requirement that says "the agent will execute refunds" is a hope, not a design.
• Ignoring reviewers. Their corrections are your best data.
• Measuring only speed. A faster process with a missed red line is a failed pilot.

Analysts in risk functions have parallel routes: see the playbooks for compliance analysts and fraud analysts. When the pilot ends, how a business analyst can move into AI operations covers the next step, and what jobs a business analyst can get with AI agent skills lists where the work leads.