How AI Architects Run Discovery Workshops With Stakeholders

13 July 2026 · Bedrock AI

An AI architect structures a discovery workshop as a facilitated conversation, not a presentation: small groups of four to seven people, mapping the real workflow as it happens today, in language that never requires the room to understand a model or a framework. The goal is a ranked list of pain points and constraints, not a pitch for a tool. Nothing gets built until that map exists.

Why do most AI discovery workshops with non-technical stakeholders fail?

Most AI discovery workshops fail because they are built around information transfer instead of conversation: a technical presenter explains what AI can do, the room nods, and nobody’s actual problem gets surfaced. Communication gaps between the people building AI systems and the people who fund and use them kill more AI initiatives than any model limitation does. A workshop that opens with “here is what large language models can do” has already lost the room, because it asks non-technical stakeholders to translate their problem into the presenter’s vocabulary instead of the other way round. The fix is structural: the architect enters the room with questions about the business, not slides about the technology, and holds every technical concept until a stakeholder’s own problem calls for it.

Who should be in the room, and who should not?

The right workshop group mixes altitude deliberately: a sponsor who can authorise budget, a process owner who manages the workflow day to day, and at least one frontline operator who actually does the work by hand. Four to seven participants is the workable range; fewer than four leaves gaps in the picture, more than seven turns the session back into a presentation because quieter voices stop speaking. Senior leaders describe the process they believe happens; frontline staff describe the workarounds, exceptions and manual patches that keep it running in practice, and the gap between those two accounts is usually where the real opportunity lives. An architect who only interviews management gets a clean, wrong picture. IT and data owners belong in a separate, later session, not this one: their presence early makes non-technical participants defer to them on questions only the business side can actually answer.

How should an AI architect structure the workshop itself?

A discovery workshop runs best as five short phases in a fixed order, because skipping straight to solutions before the problem is mapped is the single most common way these sessions go wrong.

The discipline is resisting the pull toward phase five before phase two is finished. Stakeholders will often propose a tool by minute ten of the process walkthrough, because “we should just use AI for this” is a more comfortable sentence than describing a broken process in detail. The architect’s job is to redirect that energy back into mapping, gently and repeatedly, because a tool named in minute ten is almost never the right one once the full process is visible.

What questions actually surface the real problem?

The questions that surface a real problem are about the workflow as it is, never about the workflow as anyone wishes it were. Three question types do most of the work in a well-run session:

1. Reality-check questions, such as “walk me through the last time this actually happened” rather than “how does this usually work.” The first produces a specific, checkable account; the second produces a polished summary that smooths over the exceptions where the real cost lives.
2. Ownership questions, such as “who actually approves this, and who just thinks they do.” Discovery workshops routinely surface that the person who signs off on a process and the person who does it day to day are different, and that the sign-off step itself is where delay accumulates.
3. Data-reality questions, such as “where does this information live right now, and who is allowed to see it.” Non-technical stakeholders rarely think of their own workflow in terms of data at all until asked directly, which is exactly why the question needs to be asked directly rather than assumed answered by an IT diagram drawn up beforehand.

Questions framed around a hypothetical future state (“if you could wave a wand”) produce wish lists, not findings. Questions framed around the last concrete instance of the process produce evidence an architect can actually act on.

How does an architect translate technical constraints into business language?

An architect translates technical constraints by replacing every model or infrastructure term with its cost, time or risk consequence before it reaches a non-technical stakeholder. Nobody in a discovery workshop needs to hear that a model scored 0.85 on an evaluation metric; they need to hear that the system gets the answer right roughly four times out of five, which for this workflow means a human still has to check every result before it goes to a customer. Latency becomes “how long the customer waits,” not milliseconds. Data governance becomes “who is allowed to see this if it goes wrong,” not a compliance framework name. This translation is not simplification for its own sake: it is the only way a non-technical stakeholder can meaningfully approve, reject or refine a decision, because approving a decision you do not understand is not really approval at all.

What should come out of the workshop, and what should not?

A discovery workshop should produce a written findings memo naming the two or three highest-value problems, the people and data involved, and the constraints that will shape any solution, and it should never produce a chosen vendor or tool. That last point is the one businesses push back on hardest, because a room full of stakeholders who have just spent ninety minutes describing a painful process wants a fix named before they leave. Naming a tool at that point locks in a choice before anyone has checked whether the data is clean enough, whether the process is stable enough to automate, or whether a cheaper fix exists that does not involve AI at all. This is the diagnose-first discipline in practice: the workshop’s entire value comes from resisting the pressure to conclude with a purchase, because architecture decisions made under that pressure are the ones that cost six figures to unwind eighteen months later.

FAQ

How long should a single discovery workshop session run? Ninety minutes to two hours per department is the workable range. Shorter sessions rush the process walkthrough, the phase that produces the most value; longer sessions lose the room’s attention and start generating vague, tired answers instead of specific ones.

Should the workshop be recorded? Written notes captured by a second facilitator work better than recording in most cases, because participants speak more candidly about workarounds and failures when they are not being recorded, and a note-taker can flag contradictions between what different stakeholders say in real time.

What if stakeholders disagree about how the process actually works? Treat the disagreement itself as a finding, not a problem to resolve in the room. A gap between how a manager and a frontline operator describe the same process is often the clearest signal of where the real friction sits, and it belongs in the findings memo exactly as it was heard.

Can this be done remotely, or does it need to happen in person? It can be done remotely with a shared whiteboard tool for the process map, though in-person sessions tend to surface more candid detail during the pain-point capture phase, where body language and side comments often carry as much signal as the direct answers.

How many workshops does a typical diagnosis need? One per department or major workflow is standard, usually three to five sessions for a mid-sized business, run across the first one to two weeks of an engagement before any opportunity scoring or vendor conversation begins.

Bedrock AI maps your systems, team and workflows to show where AI actually pays, before you spend a pound building. Book a strategy call.