A hands-on workshop where teams build, test, and refine real prompts and agent configurations against their own work, learning to instruct, verify, and correct AI rather than treat it as a black box.
Why did the agent just miscategorize that request? In most organizations, nobody in the room can answer that with any precision, because their entire exposure to generative AI has been a slide deck, a policy memo, or a licensing rollout, never a working session where a prompt fails in front of them and gets fixed by hand. A failed prompt is not a setback in this workshop, it is the raw material: someone says "it's ignoring the formatting instruction, let's move that to the top and see if it sticks," and the group reruns it on the spot. That is the entire method compressed into one moment: treat the failure as information, adjust one variable, test again.
The Agent & Prompt Design Workshop exists to manufacture that moment deliberately, on purpose, using the participants' own tasks rather than a canned demo. It is the most hands-on format in our workshop series, and it occupies a specific place in a broader engagement: after leadership has aligned on direction (the territory covered in our Executive Alignment Workshop) and after the organization has identified where AI should actually be pointed (the Use Case Discovery Workshop), someone still has to build the thing and learn to operate it. That is what happens here. It sits upstream of broader rollout, which is where our Team Enablement Workshop picks up, and it produces the working artifacts that feed directly into pilot scoping.
There is a gap in most AI adoption programs between "we decided to use AI for X" and "the people doing X can actually get reliable output from it." That gap is usually filled, badly, by individual employees experimenting alone at their desks, arriving at inconsistent personal workarounds, or giving up after a few disappointing attempts and quietly reverting to the old way of working. None of that is a training problem in the conventional sense. It is a skills-and-practice gap, specifically the skill of instructing a probabilistic system precisely enough that its output is usable, and the practice of checking that output before trusting it.
The workshop treats prompting and lightweight agent configuration as an engineering discipline with a feedback loop, not as a one-off writing exercise. Participants do not walk away with a folder of prompts someone else wrote for them. They walk away having personally diagnosed why an instruction failed, rewritten it, and watched the output improve or fail again for a different reason. That loop, repeated across a real task several times in one day, is what builds the underlying capability: instruct, verify, correct.
This distinguishes the format from generic "prompt engineering" training in three ways. First, the material is not hypothetical; it is drawn from tasks the participants actually perform, brought into the room as real inputs (a contract template, a customer email thread, a reporting spreadsheet, a code review checklist). Second, the workshop treats failure as the primary teaching tool rather than something to be avoided; a prompt that produces a plausible-looking but wrong answer is worth more instructional time than one that works on the first try, because it exposes what the model does not know or cannot verify about itself. Third, the workshop explicitly builds the habit of verification alongside the habit of instruction, because an organization that gets good at writing prompts but never gets good at checking outputs has traded one blind spot for another.
The workshop is built for the people who will actually be doing the work with AI day to day, not exclusively for AI champions or IT staff. A typical cohort is eight to fourteen people drawn from one or two functions with genuinely overlapping task types: a customer service team, a finance and reporting group, a legal or contracts team, a marketing content group, or a software engineering team looking at coding agents specifically. Mixing wildly different functions in one session dilutes the value, because the exercises depend on shared task material that the group can reason about together.
We ask for a mix of skepticism and openness in the room rather than only enthusiasts. Somebody who thinks the whole thing is overhyped and says so out loud is often the most useful participant, because their objections tend to be the same objections the rest of the organization will raise later, and it is far better to work through them live than to have them surface after rollout as passive resistance. We do ask that at least one person with process authority over the workshop's chosen task area attends (a team lead, a senior practitioner) because some of the corrections that come out of the day require someone empowered to say "yes, that's actually how we want this done."
We generally discourage sending only the most senior or only the most junior members of a team. Senior staff often carry tacit judgment about what "good" looks like that needs to be extracted and written into a prompt or a verification checklist; junior staff often have the freshest, most literal read on where instructions are ambiguous because they have not yet learned to silently fill gaps the way experienced staff do. Both perspectives sharpen the output.
Where the workshop touches on agent configuration rather than single-shot prompting (giving a system access to a tool, a document set, or a multi-step task), we ask that someone with basic technical fluency, though not necessarily a developer, joins as well, since a few of the exercises involve configuring permissions, connecting a document source, or reviewing what an agent is and is not allowed to do autonomously.
The single biggest predictor of whether a workshop day goes well is what happens in the two weeks before it, not the facilitation itself. We run a short intake process with the sponsoring team to collect real work artifacts: representative documents, sample outputs the team currently produces by hand, examples of edge cases that go wrong, and a plain description of the task in the team's own words rather than a management summary of it. We deliberately want the messy version, not the idealized process-map version, because prompts and agent instructions have to survive contact with real inputs, not clean ones.
We also ask the sponsoring team to nominate two or three concrete tasks as workshop candidates, ranked by how well-bounded and how frequently performed they are. A task performed fifty times a week with a fairly stable structure (a weekly status report, a first-pass contract review, a standard customer response category) is a better workshop subject than a rare, highly judgment-dependent task, because the former gives the group enough repetitions within one day to actually iterate, and because a workable prompt for it has an obvious path to daily use afterward. This selection work often overlaps with, and benefits from, prior output of a Use Case Discovery session; when a client comes to this workshop without having done that discovery work, we spend part of the intake call doing an abbreviated version of it, but the workshop itself works best when that prioritization has already happened.
Access and tooling are also settled before the day, not during it. We confirm what platform participants will use during the session (whichever large language model or agent platform the organization has already licensed or is evaluating), that accounts and permissions actually work, and that any documents used in exercises have been cleared for use in that environment. Nothing burns workshop time faster than a login failure or a legal team member realizing mid-exercise that a customer contract cannot be pasted into a given tool.
Most engagements run this as a single intensive day, six hours of working time, though we can split it into two half-days for teams that cannot free up a full day, or extend to a day and a half when agent configuration (rather than prompting alone) is the primary focus and requires more setup and testing time.
The morning opens with a short framing block, no more than thirty minutes, that sets expectations rather than delivering theory. We explain the instruct-verify-correct loop, show one live example of a prompt failing and being fixed in front of the group, and set the ground rule that failed attempts are the expected and useful output of the morning, not an embarrassment to be avoided. This is also where we address the black-box anxiety directly: we explain, in plain terms and without hand-waving, why the same prompt can produce different outputs on different runs, what that means for how much verification a given task actually needs, and why "it worked once" is not the same as "it works reliably."
The rest of the morning is spent in small groups, usually three or four people, each working on one of the pre-selected tasks with their own real material. The facilitation pattern here is deliberately not "here is the correct prompt, copy it." Groups draft a first attempt, run it, and are asked to articulate specifically what is wrong with the output before touching the prompt again: is the format wrong, is a piece of context missing, is the instruction ambiguous, is the model inventing information it was not given, is it applying a rule inconsistently. Naming the failure precisely, before fixing it, is itself a skill, and it is the one that transfers most directly to independent use afterward.
After lunch, groups reconvene and each presents their task, their starting prompt, and the sequence of corrections that got them to a working version. This cross-group review is where a lot of the durable learning happens, because a legal team's discovery that a prompt needs an explicit instruction not to invent case citations turns out to be exactly the lesson a finance team needed for a prompt that was inventing plausible-looking numbers to fill a gap in a spreadsheet. Patterns of failure repeat across very different tasks, and seeing that repetition is more convincing than being told about it in the abstract.
The afternoon then moves from single prompts toward more structured configurations for teams whose tasks warrant it: reusable prompt templates with clearly marked variable fields, saved instructions bundled with reference documents, or a simple agent setup that chains two or three steps together (retrieve a document, extract specific fields, draft a first-pass response) with a defined checkpoint where a human reviews the output before it goes anywhere. We keep the agent configurations built in the room deliberately narrow and supervised. This is not the venue for building an autonomous, unsupervised multi-step system; that belongs in a scoped pilot with proper monitoring, which is exactly what the upcoming Pilot Projects work is designed to carry forward. The workshop's agent exercises are meant to teach the underlying logic of tool access, context boundaries, and checkpoints, using a task small enough that a mistake costs nothing.
The day closes with each group writing down, in their own words, a short verification checklist for their task: what a correct output looks like, what a wrong-but-plausible output looks like, and what they will personally check before using the output for real. This checklist is arguably the single most important artifact of the day, more important than any individual prompt, because prompts get updated constantly as models and tasks change, while the discipline of knowing what to check does not.
A few specific techniques separate a workshop that builds real capability from one that produces a memorable but forgettable afternoon.
We insist on real tasks and real documents, never toy examples. A prompt that summarizes a fictional email is not the same exercise, cognitively, as a prompt that summarizes the email thread a participant received that morning. The former teaches prompt syntax; the latter teaches judgment about what matters in that specific kind of content, which is the actual transferable skill.
We deliberately introduce a broken example early, one we know will fail, before anyone has built confidence. Seeing a facilitator's own prepared prompt fail, and watching them diagnose it calmly, does more to normalize iteration than any amount of saying "failure is normal" would.
We require participants to predict the failure mode before running the fix. Before rerunning a corrected prompt, we ask "what do you expect to change, and what might still be wrong." This forces active reasoning about the model's behavior rather than passive trial and error, and it is what actually builds a mental model of how these systems respond to instruction.
We rotate who drives the keyboard within each small group. It is easy for one confident person to do all the typing while others watch; rotating ensures everyone personally experiences writing an instruction, watching it fail, and rewriting it, rather than delegating the uncomfortable part to someone else.
We keep a visible "graveyard" of failed prompt attempts on a shared document rather than deleting them. Reviewing the graveyard at the end of the day, seeing the arc from a vague first attempt to a precise final version, is often the moment participants realize how much of the improvement came from specificity and structure rather than from any special trick or secret phrase.
Several predictable ways that AI adoption efforts stall are directly addressed by the structure above.
The first is treating the tool as magic rather than as a system with a comprehensible failure surface. Teams that only ever see AI in polished demos develop an unrealistic mental model, either overestimating reliability (leading to unchecked use of flawed output) or dismissing it entirely after one bad experience (leading to abandonment). Working through real failures with the group replaces both extremes with an accurate, workable model.
The second is prompt-writing as folklore, where a few individuals accumulate personal tricks and phrasings that work for them and never share the underlying logic, so the rest of the team either copies phrases without understanding them or never improves at all. Because the workshop makes participants articulate why a correction worked, the underlying logic becomes shareable rather than tacit.
The third is skipping verification entirely once a prompt appears to work, which is how AI-generated errors quietly enter real business processes. The explicit verification checklist built at the end of each session exists specifically to prevent "it worked in the workshop" from becoming an unexamined license to trust every future output from that prompt without checking it.
The fourth is scope creep in agent configuration, where a team that gets one small automated step working immediately wants to chain five more steps together and remove the human checkpoint, well before anyone has evidence the individual steps are reliable enough to run unsupervised. We deliberately hold the line on keeping workshop-built agent configurations narrow and checkpointed, and we say plainly, in the room, that expanding scope is a pilot decision with its own governance, not something to bolt on informally after a good afternoon.
The fifth is a mismatch between the task chosen for the workshop and the organization's actual priorities, which produces a technically successful day that nobody uses afterward because it solved the wrong problem. This is why task selection during preparation matters as much as facilitation on the day, and why we push back on task nominations that look good on paper but are rarely performed or too idiosyncratic to generalize.
A successful workshop does not produce a single perfect, permanent prompt; models change, tasks change, and any prompt is a living artifact rather than a finished product. What it does produce, reliably, is a small set of working prompts or lightweight agent configurations tied to real, frequent tasks, each accompanied by a verification checklist written by the people who will use it; a group of participants who can look at a bad AI output and say specifically what is wrong with it rather than a vague "that doesn't look right"; and a shared vocabulary for talking about prompt and agent behavior across the team, so that troubleshooting later on does not require reinventing terminology every time.
Just as important is what the day exposes about the organization's readiness beyond the room. Facilitators typically leave with a clear read on where data access is a real constraint (documents that cannot be used in a given tool for legal or security reasons), where a task that looked well-bounded on paper turns out to have too much hidden judgment to templatize easily, and where the appetite for a follow-on pilot is genuine versus performative. That read feeds directly into pilot scoping conversations, and where governance or data-access gaps surface, into the broader advisory work covered under /beratung.
This workshop rarely stands alone as a first engagement, and we generally recommend against running it as the very first AI-related activity a company undertakes. Without prior alignment on direction and priorities, a prompt-design workshop risks optimizing a task that leadership does not actually consider a priority, or building enthusiasm in one team that has no clear next step because the organization has not decided what pilots to fund. For organizations unsure where they stand, the AI Readiness Check is a fast way to establish that baseline before committing to a workshop series at all.
Where the sequence works best is roughly: executive alignment to establish direction and appetite, use case discovery to identify and prioritize where AI should be applied, this workshop to build the concrete artifacts and the practical skill to use them, and then either broader team enablement to extend the skill beyond the initial cohort, or a scoped pilot to take a promising configuration further with proper monitoring and governance. The workshop's real value is in the middle of that chain: it turns strategic intent into something a team can actually run on a Tuesday afternoon, and it turns "we should use AI for this" into a working prompt, a tested checklist, and a group of people who know exactly what to check before they trust the output.
If your team already has a task in mind and the material to bring into the room, or if you are not yet sure whether this is the right starting point relative to alignment or discovery work, get in touch and we can help figure out where in the sequence to start.