You hire someone, hand them a client presentation, tell them they are not allowed to ask a single question, and promise to fire them if the first draft is bad. Nobody runs a team that way, yet it is roughly how a lot of us hand work to Claude and ChatGPT, then forward whatever comes back to a customer. This one is for anyone whose company is starting to drown in AI output nobody checked, and for the leaders tempted to ban the tool because of it.

The problem starts before the prompt. Most knowledge work is tacit: you know how to do it until you have to explain it, which is the illusion of explanatory depth, so the ask stays vague and the model fills the gap. Chris shows what that looks like with one plain Opus 5.5 prompt for the Said and Unsaid newsletter, which came back with placeholders and a guessed format, then walks through /saidandunsaid, an orchestrator skill with no logic of its own. It calls research, outline, draft, a fresh-subagent cold read, image and render subskills, and a human picks the story at the start and reads the draft at the end.

Then it moves into the enterprise: where organizational skills live in Claude under Customize, why a skill your company already published beats one you build yourself, and why banning AI after a bad draft pushes the work into shadow AI, which IBM's 2026 breach report ties to 43% of breaches. Sash adds the recipe-book view: you never have to write a skill file by hand. Have Claude interview you with the skill creator, or take a plugin someone else built and customize it.

Key takeaways:

• Make your AI ask you questions before it builds anything - say so in the prompt, or use a brainstorming or grill-me style skill that does it for you.
• Turn any task you repeat into a skill: the instructions, the rules, and two or three examples of output you consider good.
• Keep the orchestrator free of logic: one top-level skill that only calls subskills, so you can change or reuse one step without breaking the rest.
• Before you build a skill at work, open Customize, then Skills, and check the Organization section - a team may already have built it.
• Don't ban AI after one bad draft. Make a named person accountable for what ships, and give them skills that make good output the default.

Watch the video version on YouTube · Full show notes, transcript + takeaways

You have wanted to try Linux for years, and you quit in the same place every time: the install, the hotkeys, and all the ways to break the thing before you have done anything with it. After 20 years deep in Windows internals and three on a Mac, Sash hit exactly that wall, then installed Omarchy, DHH's Arch and Hyprland desktop, on a dusty Lenovo ThinkCentre off the SD card in his Sony a6000, because no USB stick in the house held six gigs. It installed in under five minutes. The first thing he did was open Codex inside it.

Omarchy ships nine agent CLIs pre-wired, Claude Code, Codex and Hermes among them, and a hotkey that launches whichever one you make the default. From there every change started as a sentence. Codex taught him the tiling hotkeys in about 20 minutes by moving the windows itself, built an app launcher bar in five, named his workspaces (Build, Comms, Studio, OS, Flex), and embedded a four-time-zone world clock in the bar. Asked what it knew about the system, it surfaced the agent skills Omarchy installs on disk: manuals for building plugins and widgets, for updating, and a crash flow where a pop-up hands the failed process straight to your default agent to read the logs and debug. When an OS update threatened 48 hours of customization, Codex built a private Git repo of the config and an update hook that backs up, updates, reviews what landed, and reloads.

The bigger point is DHH's "malleable OS": the agent is not an app running on the operating system, it can reach the source, so your Omarchy and someone else's end up genuinely different machines. It also runs on hardware the big vendors have stopped supporting, including M1 and M2 Macs, at a moment when a Mac mini has a 12-week wait. It is not set-and-forget computing - this is for people who want the customization and will own it. Sash is buying a KVM switch to make it his daily driver.

Key takeaways:

• Check the closet before you buy an agent machine. Omarchy installed in under five minutes on an old i7 ThinkCentre with 16 GB of RAM, and it runs on M1 and M2 Macs that can no longer take the latest macOS.
• Use the agent as a tutor before you use it as a builder. Ask it to walk you through the hotkeys and let it move the windows while you watch - that is how Sash learned tiling in 20 minutes.
• Ask the agent what skills and context it has on the system before you ask it to change anything. On Omarchy that question surfaced the built-in manuals for plugins, widgets, updates and crash diagnosis.
• Have the agent build its own safety net before you customize heavily: a private Git repo of your config and an update hook that backs it up, updates, and reloads what the update touched.
• Find a USB stick with at least six gigs before you start, or an SD card adapter. Sash lost 90 minutes to that alone.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Your shipping carrier sends a bill. Your invoicing system sends invoices. Nobody has ever compared the two, because the systems were never connected and the reconciliation was a spreadsheet import somebody did by hand. Drummond's CIO pointed an MCP at both sides, extrapolated a year out, and found more than $600,000 in shipping charges the company had absorbed and never passed on to its clients. The same tooling caught carrier overcharges worth filing claims against.

Chris Brock runs IT for a 90-year-old family-owned commercial print and fulfillment company in Atlanta and Jacksonville, just under $100 million in revenue, where the industry-standard ERP has atrocious reporting and a lot of the data going in is hand-typed. The working pattern is specific and repeatable: build an MCP over whatever legacy API or Postgres connection exists, plan on a frontier model, then hand that written blueprint to a cheaper model to execute inside explicit "only work in these lanes" guardrails. In CI/CD, agents security-check and end-to-end test other agents before a developer signs off. Licensing is centralized and allocated mainly to IT and some management, less for cost than for the MSA problem: a CSR dragging a customer-address CSV into an open model is a real contractual exposure. Nothing runs lights-out. Every process still has a human on green light, red light.

The part that answers the budget question is what happens after the win. A hard-dollar number converts the next AI request from a forecast into a case study, and it changes how you can approach a department. Lead with evidence of what a prior automation actually recovered and people stop hearing "we are automating you out of a job." The distinction Brock draws is between busy and strategic, not between human and machine.

Key takeaways:

• Reconcile two systems nobody has ever compared, such as a carrier bill against your own invoices, and extrapolate a year out before you ask for any AI budget. That is where the hard-dollar number comes from.
• Plan on a frontier model, then hand the written blueprint to a cheaper model to execute. Put the "only work in these lanes" constraints in writing first, because an unconstrained agent gets a mile down the road before you catch it.
• Put an agent on your agent. Security-check and end-to-end test the output in CI/CD before a developer ever sees it for sign-off.
• Build the MCP over the legacy system rather than waiting for better reporting. Most old software still exposes an API or direct Postgres, which is enough.
• Lead a funding ask with money you already recovered, not a productivity estimate, and open the same way when you go hunting for automatable work so the department does not get defensive.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Picture your company a year from now with two dozen agents running in it. One of them starts returning a number that is quietly wrong. Nobody is named as its owner, nothing recorded which data it touched, and the model underneath it changed three weeks ago without anyone noticing. No better model fixes that, because the model was never the problem.

That is the gap between two numbers from the same BCG read: 82% of CEOs are more optimistic about AI than they were a year ago, and 6% of companies see meaningful value. The companies inside that 6% are working three pillars at once - people, data, and agent ops - and missing any one makes the other two stop mattering. The framing comes out of the ITIL discipline Sash and Chris both ran at Microsoft, updated for agents. On people it means three tiers rather than a single training push: baseline AI fluency for everybody, an orchestration layer of the people who own operational processes, and a small group of stewards who carry the message. Generic training does not move it. Training on your own workflows, with every AI-assisted result required to be explainable, does.

On data the number that lands is 7%, the share of organizations that believe their data is ready for AI, and the advice is deliberately small: pick one workflow, find the data sources it needs, go to the owners, fix and document the lineage for that one path, then reuse the process. If an answer cannot be traced to a source, the agent does not ship. Agent ops gets the most concrete treatment. Map a workflow step by step before deciding where AI belongs, and leave the steps code already handles deterministically alone rather than forcing tokens at them. Put a human checkpoint ahead of anything touching finance, external sending, or a system of record. Give every agent a named owner and a traceable action log, and stand up the eval layer before the agent count grows, because agents quietly atrophy as models change underneath them. The closing stretch looks at where this goes: Mastercard and Visa building a Know Your Agent framework, Mastercard expecting one in ten purchases to be agent-made by 2030, and Microsoft Scout putting an agent into Entra ID as a named identity that inherits DLP and compliance.

Key takeaways:

• Pick one workflow before touching the data estate. Identify its sources, find the owners, fix and document the lineage for that single path, then reuse the process on the next one.
• Do not ship an agent on data whose answers cannot be traced back to a source. If the trace is missing, you will not be able to reconstruct what went wrong.
• Put a human checkpoint in front of any agent action that touches finance, external sending, or a system of record.
• Give every agent a named owner and a traceable action log, and stand the eval layer up before the agent count grows. Agent behavior shifts as models change underneath it.
• Find the 5 to 10% of people already building without waiting for permission and make them your stewards. Train on your own workflows, not generic courses, and require that every AI-assisted result be explainable.
• Leave the steps that code already handles deterministically alone. Not every automation needs a model.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Chris has spent months trying to get his agents to talk to each other, and this episode is the honest tour of three attempts: what broke, what held, and what he actually runs now. He frames it against four trust levers borrowed from how a person climbs through the ranks - human IS the loop, human IN the loop, human ON the loop, human OUT of the loop - and pins the current shift to Gary Vaynerchuk's 15/80/5 model: own the first 15 percent of an initiative, get out of the way for the 80 in the middle, come back for the last 5.

Attempt one was AgentMail, a webhook service that bills itself as Gmail for agents. Silas, Chris's Hermes chief-of-staff agent, had his own inbox and would email Neo, the coder agent, to hand off work. It worked on vibes. Conversations died silently after about the third message, and worse, they died without telling Chris - the failure mode every manager recognizes. Sash draws the distinction that explains it: these are separate Hermes profiles, peers rather than sub-agents under one parent, so there is no hierarchy to carry the handshake. Attempt two, Hermes's Kanban feature, fixed exactly that. Kanban is really a wake-up mechanism with a native acknowledgement handshake: the orchestrator posts a task to another profile's board, that profile gets a heartbeat, picks it up, and links its subtask back. Chris runs it autonomously at 4 AM against a backlog board, with a Postgres ledger tracking the traffic. It still runs, and it still only works between Hermes profiles on one gateway.

The gap that Kanban could not close is that Claude Code is Chris's real building harness and it cannot clear its own context window. His SDLC runs the superpowers plugin - brainstorming on Sonnet, design on Opus, writing plans on Sonnet, then the build loop on Opus or Fable - and every handoff between those steps needed a human to clear context, relaunch, and switch models. That is the thing that killed autonomy. Grove Rooms are the answer: a dedicated tmux session, synced to the Postgres ledger, that Silas spins up and then drives. Silas watches for the spec file to be committed, types /exit, relaunches Claude Code in the same session on the right model, and kicks off the next skill, unattended. Chris answers the brainstorming questions, walks away, gets a notice when the room moves from plan to build, and comes back to review and run close. The next move he talks himself into on air is cross-harness: have Silas hand Claude Code's finished work to a Codex-backed agent for review before it ever reaches him, and eventually replace the whole arrangement with the native A2A protocol that Hermes, ElevenLabs, Copilot Studio, and Foundry Agents already speak.

Key takeaways:

• Separate agent profiles are peers, not sub-agents. If your orchestration depends on a parent-child hierarchy that does not exist, messages will die silently. Check whether your transport has a real acknowledgement handshake before you trust it with unattended work.
• A ledger is what makes stepping back survivable. Chris tracks every agent-to-agent transition in Postgres, so oversight is a lookup rather than an argument about what happened overnight.
• The bottleneck in autonomous building is usually context, not capability. Claude Code cannot clear its own context window, so any pipeline that spans multiple skills needs something outside the session to relaunch it.
• Run different models for different phases. Brainstorming on Sonnet, design on Opus, planning on Sonnet, build on Opus or Fable - and let the orchestrator do the switching so the phase boundary costs you nothing.
• Apply 15/80/5 to a build pipeline literally: answer the brainstorming interview, leave, and come back for review and close. If you cannot name your first 15 percent and your last 5, you are not delegating, you are just hoping.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Eric Brown, a Solution Engineer at Microsoft focused on Copilot and agents, joined Chris and Sash to walk through Copilot Cowork the way he demos it for enterprise customers. The framing up front: the bottleneck in most organizations was never a lack of knowledge, it is coordination across email, meetings, chat, and scattered documents - and Cowork is built to act as an agentic teammate inside that mess rather than another place to search.

Eric ran a live screen share showing the difference between Copilot Chat (single question, single response) and Cowork (connects to tools and data, reasons, and executes multi-step work). A big piece of what makes that possible inside Microsoft 365 is Work IQ - the graph layer that already knows a user's files, meetings, emails, and chats, now paired with an LLM that can reason over it. Eric was clear that Cowork's access is bounded by the same permissions the user already has in Exchange, SharePoint, and OneDrive - "your digital assistant only has access to the items that you have access to" - and described the governance posture as wanting to build "a casino, not a prison," enabling exploration inside real guardrails rather than locking things down entirely.

The back half moved into automations: Eric used voice to ask Copilot to pull meeting transcripts off his calendar and generate a recurring daily digest, live, showing the step-by-step planning Cowork does before it commits to a scheduled task. Chris connected it to his own "orchestrator method" - define the end state with clarity first, then let the agent work backward into steps - and the conversation was headed into how Microsoft 365's credit system prices this kind of agentic work when the recording cut short.

Key takeaways:

• Copilot Cowork's real differentiator over Copilot Chat is that it acts on tasks (connects to tools, plans, executes) rather than just answering a single question - if you are still only using it for one-off Q&A, you're leaving the agentic half on the table.
• Enterprise Copilot's data access is bounded by the user's own existing permissions (Exchange/SharePoint/OneDrive) - it doesn't grant new access, so oversharing risk is closer to "existing permission hygiene" than "AI-specific risk."
• Voice input plus Cowork's task/automation builder can turn a recurring manual chore (pulling meeting transcripts into a summary) into a standing background job with a few spoken sentences - worth trying on your own most-repeated weekly task first.
• Start with "auto" model selection in Copilot if you're not sure which underlying model fits your task; Copilot will route it for you.
• Define the end state before you prompt for the task - Chris's orchestrator framing (clarity on the output shape first, then the steps) mapped directly onto how Eric was structuring his own Cowork requests.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Sash drives this one, and he does not start with the tool. He starts with the failure. He was running Claude Code across two Macs, so his first move was the obvious one: put his intelligence folder of Markdown context files in a git repo and sync it to both machines. That worked until it did not. Every session ended with a push he had to remember, and every session started with a pull he had to remember, and forgetting either one meant an agent was working from yesterday's truth. Then he added a Hermes agent on a Hostinger VPS, then revived an old OpenClaw agent on another one, and suddenly there were four agents and no shared understanding between them.

The fix was not better discipline, it was a different layer. Sash looked at Obsidian vaults and Karpathy's LLM Wiki before landing on gbrain, the open-source project from Y Combinator's Garry Tan, which Tan describes on the repo as "the production brain behind my OpenClaw and Hermes deployments." gbrain sits on top of the git repo as a semantic layer: it chunks the Markdown, indexes it into Postgres with pgvector, and exposes an MCP endpoint agents can query. The git repo stays the durable source of truth and stays human-editable. What changes is retrieval. Instead of loading CLAUDE.md plus status.md plus decisions.md into every context window, an agent asks gbrain for the chunk that matches the task and pulls more only if it needs it. That is the moment Chris stops the demo to repeat it back, because just-in-time context is the part that actually changes a working day.

The second half is the part most people skip, which is access. Sash runs three agents against one brain with deliberately different permissions: Nuro is the only thing with write access to the git repo, Kyra has full read/write on gbrain but read-only on the repo, and Blaze can only read the course-related slice and cannot see client work at all. His framing is that this is not novel, it is just how you build an IT team - help desk does not get admin on the database, engineers do. Sash closes with the smallest version worth doing: if you run one agent and nothing always-on, hand the gbrain repo to Claude Code or Codex, point it at the files you already work in, and describe the thing your agent keeps forgetting.

Key takeaways:

• Put the durable source of truth in a git repo of plain Markdown you can still open and edit by hand, then treat gbrain as an index on top of it rather than a replacement for it.
• Stop loading whole context files into every session. Wire a hook so the agent queries the brain for the chunk the task needs, and let it pull the full page only when the chunk is not enough.
• Separate the three things an agentic system needs: context lives in the brain, canonical instructions stay in CLAUDE.md or AGENTS.md, and tools are wired per agent.
• Decide read versus write per agent before you connect the second one. Give exactly one agent write access to the source repo and scope every other agent to the slice it actually needs.
• If you are starting cold, do not install it by hand. Give the gbrain repo URL to Claude Code or Codex, tell it what your agent keeps forgetting, and let it work out the setup and the sync job.

Watch the video version on YouTube · Full show notes, transcript + takeaways

Kevin Johnson - KJ - leads the AI and automation practice at Pinnacle Financial Partners, a bank that closed a merger of equals in January between two institutions north of $60 billion each. He has been doing this hand-to-hand since ChatGPT launched in November 2022. Chris and Sash brought him on to answer the question every enterprise team is quietly stuck on: what actually has to be true before generative AI works in production.

His answer is that almost none of it is about AI. Pinnacle's ability to move fast on generative AI traces back five or six years, to a modernization journey that ripped workloads out of a traditional data center, rebuilt the data and networking and security layers, and reorganized teams into pods around the new work. That unglamorous foundation is the reason the AI work has anywhere to land. KJ's sharper point is that the same modernization has to happen to people, and that half gets far less attention: reinventing yourself as a contributor after two decades of doing the job one way is hard, and the organizations that win will be the ones that move fluidly through that change. As he put it, that is as human as it gets.

The back half is about discipline. Value in generative AI is genuinely hard to measure, and KJ is blunt that if you are not already measuring your KPIs well, layering AI on top makes measurement harder rather than easier. He and Sash land in the same place on tooling: automation and AI are two different tools in the toolbox, deterministic solutions never actually died, and you do not need a cannon or a bazooka for a mosquito. Chris connects that back to skills as the middle ground - a way to get an agent to follow the same process every time, even when the wording varies - and notes how often his skills end up becoming automations. The advice KJ would give his 2023 self is not technical at all: get real leadership buy-in, make continuous innovation part of the DNA, and meet the organization where it actually is.

Key takeaways:

• Do the modernization work first. Cloud, data, networking, and security foundations are what make a generative AI program possible, and skipping them is the same mistake teams made pushing BI projects ahead of data cleansing.
• Budget for team member modernization, not just technology modernization. The hard part is people reinventing how they work, and that is a change management problem rather than a tech problem.
• Fix your measurement before you add AI. If your KPIs are not instrumented well today, proving generative AI value on top of them gets harder, not easier.
• Match the tool to the problem. Deterministic automation and RPA still solve plenty of things more cheaply and more reliably than a frontier model, and orchestration plus observability matter more than horsepower.
• Use skills to put determinism back into agent work. Define the pattern once so the process runs the same way every time, and expect the good ones to graduate into automations.
• Ship tools that make someone's day measurably easier and adoption becomes organic. Finding an answer in ten seconds instead of two and a half minutes is the kind of win a frontline team feels immediately.

Watch the video version on YouTube · Full show notes, transcript + takeaways