No result found
This report needs a scored result to generate.
This is a static sample and does not depend on a scored result.
Back to the course page
PRAXORALAB Illustrative example · fictional company, for format reference only
Working Applications, Built in the Room
Rosemount Family Dental Group
Participant Priya Nathan, Practice Operations Coordinator
Three real work tasks, brought into the session and turned into working applications in one 3.5-hour sitting, not demonstration scenarios built by the facilitator in advance.
Weekly clinic performance report
Tool / workflow: A structured prompt template run against the practice management system's weekly CSV export, built in the session's first hour.
Output: A five-paragraph draft report covering appointment volume, no-show rate, and revenue by treatment category, ready for Priya to review and send to the four partners by Monday morning instead of Wednesday afternoon.
New-patient welcome pack drafting
Tool / workflow: A reusable prompt that pulls the patient's intake form answers and drafts a personalised welcome email plus a pre-visit instructions sheet.
Output: A first-draft email and instructions sheet generated in under a minute per patient, down from roughly fifteen minutes of manual drafting, still reviewed and sent by Priya herself.
Meeting notes to action items
Tool / workflow: A short orchestration workflow: a transcript of the fortnightly partners' meeting is fed through a summarisation step, then a second step extracts and assigns action items to named owners.
Output: A structured action-item list with owner and rough due date attached to each line, posted to the practice's shared task board, instead of action items living only inside Priya's own notebook.
Three applications from one afternoon is a realistic outcome, not an inflated one, and I want to be specific about why these three and not a longer list. Priya arrived with five candidate tasks. We built three of them and left two deliberately unbuilt, because the session's real constraint is never how many prompts you can write in 3.5 hours, it is how many tasks are genuinely well-formed enough to turn into something reusable on day one. The weekly performance report, the welcome pack, and the meeting-notes tool all share one property the other two candidates did not: each one has a clearly defined input, a clearly defined output, and a person who already owns the task end to end. That is the actual selection criterion I use in the room, not novelty or ambition.
The performance report is the right first build of the three, and it is worth naming why it goes first rather than last. It is the lowest-risk application in the room: the input is a single structured export, the output is read by four partners who already know the underlying numbers well enough to catch an error immediately. That combination, low technical complexity and a built-in human safety net, is exactly what a first working application should be, because the goal of hour one is confidence, not sophistication. I have watched participants try to build their most ambitious idea first and lose the whole session debugging it instead of learning the underlying skill.
The welcome-pack application is doing more strategic work than it looks like on the page. Turning a one-off draft into a reusable template with named variables is the actual skill this segment teaches, not "write a good prompt." Most people who arrive with some ChatGPT experience already know how to get a decent one-time output. Very few of them have built something a colleague can run without them in the room, which is the entire distinction between a demo and a working application, and it is why I insist on the template step rather than letting a participant stop at a good first draft.
Rosemount's real exposure, if I am honest about what this page does not yet show, is that all three applications currently depend on one person. That is not a criticism of the session, it is the expected state of week one, and it is exactly what the roadmap on the final page is built to close.
PRAXORALAB Prompting & Orchestration Technique
How each of Priya Nathan's three applications above was actually built, segment by segment, not a general theory of prompting.
Application 01 — starting from a single, reusable prompt
The clinic performance report started as a single prompt, not a chain of steps, because the underlying task is genuinely one-shot: read one CSV, produce one report. The session's first working hour is deliberately spent here, on a task simple enough that a participant can see cause and effect immediately, before agent-style delegation is introduced at all.
The prompt itself was built iteratively in the room: a first draft produced a report that buried the no-show rate, the single most commercially urgent number in the whole document, in its third paragraph. The fix was not a cleverer prompt; it was adding an explicit instruction ordering the output by commercial urgency, not by the order columns appear in the source file. That one correction is the fluency point of this segment, not the report itself.
Application 02 — a reusable template, not a one-off draft
The welcome-pack prompt was deliberately built as a template with named variables (patient name, appointment type, any flagged intake concern), not a one-off prompt rewritten by hand for each new patient. That is the difference between a prompt fluency exercise and a working application: it has to survive being run forty times a month by someone who was not in the room when it was written.
Application 03 — from one prompt to a two-step orchestration
The meeting-notes tool is where the session moves from single prompting to a delegated, multi-step workflow. Step one summarises a raw transcript; step two runs only against that summary, extracting and assigning action items. Splitting these into two steps, rather than one large prompt asking for both at once, was a deliberate design decision: the first step is checked before the second one runs, so an inaccurate summary never silently produces a wrong action-item list downstream.
The choice to keep application one as a single prompt rather than dressing it up as an "agent" is deliberate, and it is the single most common mistake I see newer practitioners make elsewhere: reaching for orchestration because it sounds more sophisticated, on a task that does not actually need it. A weekly CSV-to-report job is a one-shot transformation. Wrapping it in a multi-step agent framework would not make the output better, it would only add failure surface a solo operations coordinator now has to maintain without engineering support. Fluency, in this course, means knowing when not to reach for the more complex tool, not only how to use it.
The correction made to that first prompt, reordering the report by commercial urgency rather than column order, is a small edit with an outsized lesson behind it. Most people's first instinct when a generated report reads oddly is to rewrite the whole prompt from scratch. The actual skill is diagnosing which single instruction is missing and adding exactly that, which is a debugging habit, not a prompting trick, and it is the habit I most want a participant to leave with, because it is the one that keeps working after I am no longer in the room to help.
The two-step split in application three, summarise then extract, is the part of this page I would defend most strongly if a sceptical colleague pushed back on it. A single prompt asking for both a summary and an action-item list in one pass would technically work most of the time, and that "most of the time" is exactly the problem: on the one meeting with a messier transcript, an error in the hidden intermediate summary would propagate silently into a wrong action-item list, with no visible seam where a person could have caught it. Splitting the steps creates a checkpoint, and creating a checkpoint at the one place an error is likely and consequential is the entire discipline behind agentic workflow design, not an academic nicety.
What I would push Rosemount toward next, once these three are running unattended for a few weeks, is not a fourth application built the same way. It is testing whether the two-step pattern from application three generalises to another multi-step task on Priya's list, because a workflow pattern that only ever gets used once was not really learned, it was only demonstrated.
Rosemount Family Dental Group, Priya Nathan, Practice Operations Coordinator, and every prompt, application and figure described on this page are invented for this sample only, to show the shape of the output, not a real client's actual work. In the session, these applications are built on the tasks a participant brings, not assigned from a template.
PRAXORALAB Documented Human-Check Boundary
Which steps of each application at Rosemount Family Dental Group run unsupervised, and which stay human-checked, stated per application rather than as one general policy.
Pulling the raw CSV export and generating the first draft report structure and paragraph order.
Every figure in the draft is checked against the source export by Priya before it reaches the four partners; the report is never sent un-reviewed.
Drafting the welcome email and instructions sheet from the intake form's answers.
Any patient record where the intake form flags a medical concern or unusual request is read and edited by Priya before sending, not sent as generated.
Summarising the raw transcript, and drafting the first-pass action-item list with suggested owners.
Every owner assignment is confirmed by the meeting chair before the task board updates; the tool proposes an owner, it does not assign one.
Read across all three applications, the boundary line lands in a genuinely defensible place, and it is worth naming the pattern rather than treating each row separately: the AI drafts, a specific named person checks before anything reaches someone outside the room where it was built. Nobody at Rosemount receives an AI-generated document that has not passed through Priya first. That is not a conservative default chosen for the sake of caution, it is the correct boundary for a practice this size, where one operations coordinator is currently the only person who can catch an error before a partner or a patient sees it.
The distinction I would draw out for Rosemount, which the checklist opposite states but slightly under-emphasises, is that "checked" means genuinely different things across the three rows, and conflating them would be a mistake. Checking a performance report against a source export is a factual verification, a person confirming numbers match. Checking a welcome email for a patient with a flagged medical concern is a judgement call, a person deciding whether the tone and content are appropriate for a specific, sensitive situation. Those are different cognitive tasks, and treating them as the same "human review" step risks the second one getting rushed the way the first one reasonably can be, once Priya has run the report enough times to trust the pattern.
The action-item owner assignment in application three is the row I would flag as the most consequential going forward, not because it carries the highest current risk but because it is the row most likely to quietly slide from checked to unsupervised without anyone deciding that on purpose. A suggested owner that turns out correct nineteen times in a row invites the twentieth to go unchecked out of habit, not decision. My advice to Rosemount, stated plainly, is that any move of a line from this page's checked column to its unsupervised column should be a deliberate decision made by the practice's partners, not something that happens by attrition because Priya got busy one week and stopped double-checking.
None of this is a criticism of where the boundary sits today. For a first working set of applications built by one person in one afternoon, this is close to the right answer, and the discipline of writing it down at all, rather than leaving it as an unstated assumption, is most of the value of this page.
PRAXORALAB Keep Building, Without the Facilitator in the Room
What Priya Nathan and Rosemount Family Dental Group do next, sequenced by what protects today's three applications first, not by department or ambition.
- Run all three applications once more on real data before the next partners' meeting, this time without the facilitator in the room.
- Write down the exact prompt text for each application in a shared document, so a colleague can run it if Priya is on leave.
- Pick one further task from Priya's own list of candidates raised but not built in the session: appointment-reminder message drafting.
- Time each of the three built applications against the manual process it replaces, so the practice has its own evidence of the time saved, not a vendor's claim.
- Review the human-check boundary on the checklist page opposite; move a step from checked to unsupervised only after a defined run of error-free use, not on confidence alone.
- Decide, as a practice, whether a fourth application is worth building in-house or worth bringing back for a follow-up session.
The reason this roadmap runs this week, then this month, then this quarter, rather than listing six equally weighted actions, is that the first two items are the only ones that protect what was actually built today. Running all three applications again without me in the room, and writing the exact prompt text down somewhere a colleague can find it, are not optional follow-up tasks, they are the difference between three working applications and three applications that quietly stop existing the day Priya takes a week of leave. I have seen this exact failure mode before: a participant leaves the session able to run something themselves, but nothing about how they did it survives outside their own head, and eighteen months later a very similar exercise gets funded again from zero because the previous one was never actually institutionalised.
Timing the built applications against the manual process they replace, in the "this month" tier, is the item I would fight hardest to protect if Rosemount's time gets squeezed later. Without it, the practice has no evidence of its own, only a felt sense that the new way is faster, which is a fragile thing to defend to a partner asking whether this was worth the afternoon a year from now. It does not need to be a rigorous study. It needs to be one number, minutes saved per report or per welcome pack, that Priya herself can point to.
The "this quarter" tier is where I want to be most explicit about pacing, because it is the tier most people get impatient about. Moving a step from checked to unsupervised should follow a defined run of error-free use, not a feeling of confidence, and defined is doing real work in that sentence: it should mean a specific number of clean runs the practice agreed on in advance, not "it's been fine for a while now." A boundary that moves on vibes is not a boundary, it is a countdown to the first uncaught error.
What "done" looks like at the end of this roadmap is not five applications instead of three. It is three applications that keep running correctly without me, with their prompts written down, their time savings measured, and their human-check boundary moved only on purpose. That is a materially more durable outcome than a longer list built in the room and forgotten the following week, and it is the only outcome this course is actually trying to produce.
Every application, quote and figure on these four pages is invented for Rosemount Family Dental Group, a fictional company, so the format of what a participant leaves with can be judged before enquiring. It is not a real client's deliverable, and no dental practice named Rosemount Family Dental Group is a Praxora Lab client. The session itself builds working applications on your own real tasks, in the room, on the day.
3.5 hours, one session, facilitated by Dr. Joshua Lau.