On July 21, 2026, Digital Meld CEO Brad Groux led a 45-minute Personal AI Agents LIVE workshop about moving from business discovery to working software with OpenClaw and Codex. The demonstration used a fictional, Mr. Robot-inspired E Corp scenario to build a local Cyber Escalation Command Center for organizing risks, threats, evidence, ownership, and executive decisions.
Most AI coding demonstrations begin with a polished prompt and end with an application screen. This workshop spent its time on the work between those two points: collecting messy source material, challenging assumptions, writing a Product Requirements Document, breaking the work into reviewable issues, defining the agent's authority, building the application, and preserving evidence that each step happened. The finished interface was useful, but the reusable result was the delivery method behind it.
What Did the Workshop Build?
The E Corp Cyber Escalation Command Center is a framework-free, local-only web application. It includes a command-center queue, evidence feed, executive brief, fabricated repository view, and Build Trace. Users can filter escalations, change local owners and statuses, mark evidence as reviewed, export the local state as JSON, and reset the demonstration without connecting to an external service.
The fictional setting made the cybersecurity scenario recognizable while keeping the workshop safe to reproduce. The source packet contains company context, a stakeholder brief, a discovery transcript, emails, memos, chats, people and systems data, and structured risk signals. It does not contain production credentials, private customer records, operational attack instructions, or live incident data, and the app cannot send a message, create a ticket, trigger an alert, or change a production system.
Those constraints were part of the product definition from the beginning. They shaped the source corpus, the PRD, the issue set, the implementation goal, and the final checks, which is the same discipline a business needs when an agent will eventually work near sensitive data or operational tools.
Begin With the Business Record
A blank chat window is a poor source of truth for a business application. Real requirements are usually scattered across meeting notes, email threads, spreadsheets, policies, support conversations, system documentation, and people who know how the exceptions work. If that context is reduced to one short prompt, the implementation may be fast while still solving the wrong problem.
The workshop started by turning discovery material into a source corpus that both people and agents could inspect. In the E Corp scenario, one executive wanted decision-ready business impact, the technology team needed recovery issues separated from active threats, legal needed the evidence behind each decision, and operations needed clear ownership. Those requirements came from the fictional brief and discovery transcript rather than appearing later as design guesses.
OpenClaw handled this part of the workflow because it could retain the long-running business context and keep the supporting files together. Its useful role was to preserve the original sources, show where a requirement came from, and carry unresolved questions into a planning conversation instead of filling the gaps with confident assumptions.
Grill the Plan Before Writing the PRD
Once the corpus existed, the workshop used $grill-with-docs to challenge the product direction one question at a time. Questions already answered by the source material were resolved from the source material. Decisions that needed judgment stayed visible for a person to make. The working prompt was deliberately direct:
Use $grill-with-docs.
Do not draft the PRD yet.
First, grill the product direction one question at a time.
If a question is answered by the corpus, answer it from the corpus instead of asking.
Resolve:
1. primary users,
2. app output,
3. triage workflow,
4. evidence model,
5. executive summary needs,
6. local-only safety boundary,
7. what belongs in the first app build,
8. what should be deferred.A PRD can only record decisions after the team makes them. The workshop had to settle the primary users, the difference between risks, issues, and threats, the evidence attached to each escalation, the minimum useful application, and the actions that had to remain local or manual. Only then could the PRD describe a build that another person or agent could implement without replaying the entire discovery session.
The PRD Became the Delivery Contract
The resulting PRD defined the problem, audience, product output, screens, interactions, data model, safety requirements, non-goals, risks, success measures, and acceptance criteria. It also made the division of work explicit: OpenClaw owned discovery, durable context, the grill session, and PRD generation; Codex received the approved PRD and owned issue artifacts, the implementation goal, the application build, and verification.
The PRD operated as the delivery contract. The later prompts pointed back to it, the issue acceptance criteria came from it, and the final Build Trace made it possible to compare the delivered application with the original contract. If the app had introduced a live integration, removed an evidence requirement, or skipped a review boundary, the difference would have been visible.
Digital Meld used the same pattern in a more complex client delivery described in How Digital Meld Built a Power Apps Code App with OpenClaw and Codex. In that project, the PRD connected business context, Dataverse ownership, access controls, routes, delivery sequencing, and verification gates before implementation began. The platforms were different, but the planning discipline was the same.
Turn Approved Scope Into Reviewable Work
Codex moved from the PRD into a set of scoped issues instead of one large code change. Each issue included labels, milestones, acceptance criteria, evidence requirements, implementation notes, and dependencies. The application shell and seed data came first, workflow screens followed, and the Build Trace and local proof came after the underlying artifacts existed. The issue-generation prompt kept the output bounded:
Read:
- PRD.md
- demo/app-output-spec.md
- demo/source-corpus/company-brief.md
- demo/source-corpus/stakeholder-brief.md
- demo/source-corpus/signals.json
Create issue artifacts with:
- labels and milestones,
- acceptance criteria,
- evidence needed,
- implementation notes,
- optional simulated commit and pull request notes.
Do not create live GitHub issues.
Keep all content fictional, local-only, and safe for a public workshop.Good issues reduce the amount of context that has to be reconstructed during implementation. A developer or agent can pick up one work item, see what it changes, understand how it will be checked, and avoid touching unrelated behavior. The issue also gives a reviewer a stable unit for asking whether the work meets the PRD instead of reviewing a large, unexplained application at the end.
Use a Durable Goal for the Build
The approved issue set and application specification then became a Markdown /goal. The goal named the source files, expected output, safety boundary, required interactions, and verification steps. Saving it as a file made the implementation instructions reviewable and reusable, while the durable work loop could continue through branches, checks, pull requests, and fixes without depending on a private chat history. A shortened version of the workshop goal shows the useful structure:
/goal Build the E Corp Cyber Escalation Command Center
from the checked-in workshop corpus and issue artifacts.
Read:
- PRD.md
- demo/app-output-spec.md
- demo/issue-artifacts.md
- demo/implementation-plan.md
- demo/source-corpus/
Requirements:
- static local-only app
- no backend, database, auth, or external services
- command center, evidence feed, executive brief,
fabricated repo, and Build Trace
- local workflow controls, JSON export, and reset
Verification:
- open the app locally
- confirm all tabs render
- confirm filters and local state controls work
- confirm export produces JSON
- confirm reset clears local stateThe goal did more than describe features. It established where the agent could work, which sources were authoritative, what it must not do, and what proof was required before completion. Digital Meld applies the same idea to business adoption through named permissions and scoped authority, as described in Before Businesses Adopt Codex, Define Its Permission Model.
Keep the Build Trace With the Product
The demonstration application includes a Build Trace tab that shows the source corpus, grill notes, PRD, issue artifacts, goal prompt, implementation plan, simulated repository activity, and final application state. Each jump in the chain has a checked-in artifact, a human review point, and an expected verification step.
This matters after the initial build because software always outlives some of the context that created it. A future maintainer needs to know why a screen exists, which requirement produced a control, where a boundary came from, and what evidence supported the original decision. A transcript alone is difficult to review, while a polished application alone hides the decisions and compromises that produced it. The artifact chain connects the two.
The same principle applies outside software development. A finance review packet should point to the invoice, purchase order, receipt, policy, and approval. An incident brief should identify the evidence, timeline, owner, communication decision, and closure criteria. A field-operations recommendation should preserve work orders, qualifications, access constraints, safety notes, and the person authorized to dispatch the crew.
SOPs, PRDs, Issues, and Goals Have Different Jobs
Teams sometimes collapse all of this material into one large prompt. That makes the first run convenient and every later review harder. Each artifact has a different purpose, and keeping those purposes clear makes the workflow easier to operate:
- Source notes preserve what people, systems, and records actually said.
- An SOP describes how the current workflow should operate, including ownership, exceptions, and controls.
- A PRD defines the problem being solved, the users, scope, boundaries, requirements, and acceptance criteria.
- An issue turns part of the approved direction into a reviewable unit of work with named evidence and checks.
- A durable goal gives the implementation loop its sources, authority, stop conditions, and definition of done.
- A Build Trace preserves the artifact chain so another person can inspect how the delivered result connects to the original need.
Digital Meld covered the people and process side of this approach in Business AI Starts With the People Who Know the Work. The people doing the job provide the exceptions and judgment that the model cannot discover on its own. The files then make that knowledge durable enough to support implementation, review, onboarding, and future changes.
Safety Has to Travel Through Every Handoff
The workshop used fictional public-reference material and a local application because safety was easier to demonstrate when the boundaries were visible. No real records entered the corpus, no live accounts were connected, no GitHub actions occurred inside the demonstration, and no external messages or alerts could be sent. The issue prompt, goal, app specification, and final review all repeated those limits.
Businesses need the same consistency. A privacy rule written in the PRD does little good if the implementation issue omits it, the agent receives broader permissions, a test fixture contains private data, or a deployment step introduces a live integration without review. Security, privacy, approval, logging, rollback, and external-action boundaries have to survive every handoff from discovery through operation. The same preparation discipline appears in The Incident Plan Has to Exist Before the Incident, because controls need to exist before a risky run or incident asks the team to rely on them.
The workshop also kept human review at each change in responsibility. OpenClaw could organize context and propose a PRD, but a person approved the product direction. Codex could create issues and build against the goal, but named checks and review gates determined whether the work was ready. The application could prepare an escalation and export a brief, but it could not make the legal, security, operational, or executive decision.
Where Can a Business Use This Method?
The workshop used cybersecurity because the evidence and trust boundaries were easy to see, but the method applies to ordinary business work. The following examples show practical places to begin.
- Accounts payable: collect invoices, purchase orders, receipts, vendor records, and policy into an exception packet that a finance owner can review.
- Field operations: assemble work orders, crew qualifications, equipment status, access notes, and safety constraints before a dispatcher assigns work.
- Customer support: connect account history, product documentation, prior cases, entitlement, and escalation rules into a draft response and next-action brief.
- IT remediation: combine inventory, vulnerability evidence, change windows, ownership, and rollback requirements into scoped work with approval gates.
- Internal software: move from interviews and process maps to a PRD, issue backlog, verified pull requests, deployment notes, and a support handoff.
The first release should remain small enough to inspect. Pick one painful workflow, capture the source material, ask the people doing the work where the official process breaks, and produce one reviewable artifact before adding external actions. That sequence creates evidence about the workflow and the operating boundary before the business takes on more automation.
Recreate the Workshop
The full Personal AI Agents LIVE workshop packet is public. It includes the prompts, source corpus, PRD, issue artifacts, implementation plans, goal files, static application, slides, speaker notes, runbook, fallback plan, and safety checks needed to inspect or recreate the workflow.
The full workshop is available on YouTube. The shorter Twitter video post provides another overview. Teams adapting the packet should replace the fictional corpus with approved business context while keeping the same planning questions, review gates, data boundaries, and proof requirements.
Digital Meld helps partners turn scattered operating knowledge into systems that people can understand, review, and support. That work may use OpenClaw, Codex, GitHub, Microsoft 365, Power Platform, Microsoft Foundry, custom software, or a smaller combination that fits the business. The tools can change; the source context, ownership, boundaries, and evidence still have to be designed.
For organizations trying to move from AI experiments to a working business process, start with the workflow and discuss it with Digital Meld. Bring one process that depends on scattered context, repeated handoffs, or too much institutional memory, and turn it into a reviewable artifact chain before trying to automate the company around it.