On July 16, 2026, Andrea Griffiths hosted Brad Groux on GitHub's Rubber Duck Thursday for a conversation about OpenClaw, business agents, and where AI actually fits inside a company. The session started with OpenClaw and agent workflows, but the useful part was the discussion around ordinary business work: invoices, dispatching, lab reviews, supply-chain exceptions, reception desks, GitHub issues, and the gap between a good demo and a system people can trust.
For Digital Meld, the important point is the operating lesson behind the demo: most organizations do not struggle with AI adoption because the model is not impressive enough. They struggle because the workflow was never mapped with the people who understand it, the boundaries were never named, and the first version skipped straight from a clever prompt to a production expectation. AI can help, but it has to be wrapped around the business instead of forcing the business to bend around the tool.
Start With the People Who Know the Exceptions
Most companies have an official process and a working process, and they are not always the same thing. The official version lives in a procedure, a system diagram, a training deck, a project plan, or the way leadership explains the process in a meeting. The working version shows up when the shipment is late, the invoice does not match, the lab result needs a second look, the customer calls before lunch, or the field crew is waiting while three systems disagree.
AI can summarize the official version, but it cannot automatically know the working version unless the people doing the job make that knowledge visible. The dispatcher knows which route looks fine on a map but fails with a certain load. The accounts-payable person knows which variance is normal and which one means stop. The receptionist may know more about where exceptions really go than the org chart ever will. That knowledge sits inside the process, and the model needs it before it can help.
A Prompt Is Not a Business Process
Models will keep changing, and every serious team should expect that instead of pretending one model decision settles the stack for years. Pricing changes, context windows change, connectors improve, deployment options move, and whatever tool looks best today may be a utility next quarter. The invoice still needs an owner, the field assignment still has safety constraints, the lab result still needs release authority, the marketing claim still needs evidence, and the shipment exception still needs someone accountable for the customer.
Business AI gets sideways at this step. A team finds a clever prompt, proves the model can produce a decent answer, and starts treating that prompt like the business process. That can carry a demo, but it is a weak foundation for work people have to trust after the first week. The durable part is the operating context around the model: who owns the workflow, what starts it, which source is authoritative, what exceptions matter, what the agent may draft, what it must never approve or change, which checks run before review, and who owns the decision.
The Useful Artifacts Are Usually Boring
The session repository includes companion materials for fictional business scenarios across accounts payable, marketing, field operations, lab management, and supply-chain logistics. The examples are ordinary on purpose, because ordinary work is where most business AI has to prove itself. Source notes, SOPs, PRDs, drafts, deterministic checks, human approval, and feedback loops may not sound exciting, but they keep the business logic visible when the model changes or the original builder moves on.
Source notes keep an agent from turning missing facts into confident output. An SOP lets the people doing the work correct the process before it gets automated. A short PRD forces the team to name the user, owner, boundary, acceptance criteria, and support path. Checks catch the parts that should not depend on a model's judgment, such as arithmetic, required fields, dates, thresholds, duplicate detection, policy flags, and reconciliation. Those artifacts keep the work reviewable instead of turning the process into a pile of paperwork.
Boundaries Have to Be Designed Early
The demo materials were draft-only by design. The agent could assemble evidence, prepare a brief, flag a mismatch, or suggest the next question, but it could not approve an invoice, release a lab result, dispatch a crew, contact a carrier, send a customer message, publish a claim, or touch live records. Those limits have to be designed up front, because they shape how the workflow is reviewed and supported.
Most business teams do not need to start with autonomy. They need help preparing the work so the responsible person can make a better decision with less manual drag. More autonomy should be earned through evidence, not granted because the first answer looked good on a screen. This matters even more when agents connect to tools, repositories, Microsoft 365, Power Platform, Dataverse, GitHub, finance systems, field apps, or customer data, because a system that can take action also needs ownership, permissions, logs, rollback, and a clear stop condition.
Start Smaller Than the Roadmap
Andrea asked the practical question that comes up in almost every AI conversation with business leaders: where should a company begin? The useful answer is usually smaller than the executive roadmap. Pick one workflow that hurts enough to fix, then find the person who lives with it. Ask where the official process breaks, which spreadsheet still matters, which system nobody trusts, which handoff gets missed, and which exception shows up every week.
The first deliverable should be one reviewable artifact, not a company-wide autonomous agent. For accounts payable, that might be an exception packet that lines up the invoice, purchase order, receipt, variance, and suggested question. For field operations, it might be a morning brief that assembles work orders, equipment status, qualifications, access notes, and safety constraints without assigning the crew. For a lab, it might be a release-readiness packet that shows which checks are complete and which still need a qualified person. If that artifact helps a real person do a real job with less friction, the organization has learned something useful.
GitHub Can Hold the Working Context
Another useful thread from the session was GitHub as a place to hold business context, not only code. An issue can describe the problem, owner, acceptance criteria, and open questions. Markdown can hold the SOP and PRD. A pull request can show exactly what changed in the process. Review comments can preserve why a decision was made, and history makes mistakes easier to unwind.
That does not mean every business record belongs in a repository. Customer data, regulated records, credentials, financial details, and live operational data need the right system and access model. The repository should hold safe operating context, not become a dumping ground for private data. Used carefully, though, GitHub gives people and agents the same durable context, which is far better than burying business logic inside one chat window.
The Digital Meld View
Digital Meld calls the organizations it works with partners because useful business systems are built with people, not delivered at them. A useful engagement starts by learning how the business actually moves, finding the painful workflow, making the process visible, setting the trust boundary, choosing the right tools, and proving the result helps the person responsible for the outcome.
Sometimes that means OpenClaw, Codex, GitHub Copilot, Microsoft 365, Power Platform, Dataverse, or a custom app. Sometimes it means a better process document, a cleaner source of truth, or one small integration nobody will ever turn into a keynote. The point is to fit the tool around the work, keep people responsible for the outcome, and improve one workflow at a time.
Thank you to GitHub, Andrea Griffiths, and everyone who joined Rubber Duck Thursday. The full recording and complete session packet are public for teams that want to use or adapt the workflow. Start with one painful workflow, find the people who live with it, ship one reviewable artifact, verify it, and let the next run start from what the team learned.