Human in the Loop: Two Ex-Microsoft Builders on AI

Chris Shanku

Chris Shanku and Sash Mohapatra - two ex-Microsoft builders - demo one real AI tool per episode, live and unedited. Real people. Real tools. No retakes.

  1. 8h ago

    The Harness Outweighs The Model

    Sash drove this one, and the framing he opened with does most of the work: a model is a faucet of intelligence, but a faucet on its own does not plumb a house. An agent is a model plus a harness, and the harness is the environment the model actually runs inside. It is the app. The chat window is a harness. Claude Code is a harness. Hermes and OpenClaw are harnesses. What the harness supplies is everything the model cannot supply itself: tools, memory, skills, and a scheduler. Take those away and an agent collapses back into a chatbot. The useful part of the episode is the ladder Sash laid out. Chat sits at the bottom, the simplest harness there is, with almost nothing to break. A session-based agent harness like Claude Code or Codex sits above it, capable of pulling tools, running skills, spawning subagents, and looping. Always-on harnesses like Hermes and OpenClaw sit at the top, waking on a schedule, reading a task list, and working without a human in the session. The catch is that fragility climbs right alongside capability. Chris and Sash both hit it: OpenClaw dying silently on background tasks with no signal until you go turn on traceability, and Chris discovering he could not take a clean update after forking Hermes, because customization is exactly what makes an always-on harness yours and exactly what makes it yours to maintain. The number worth carrying out of the episode is 8x. Sash cited a controlled study showing the right harness multiplied agent capability roughly eightfold with the model held constant. That reframes where the leverage is. Chris landed the analogy that ties it together: the harness is to agents what retrieval augmented generation was to GPT three years ago, the surrounding machinery that turns a generic model into something grounded in your context and useful on your problems. Both hosts expect enterprises to start building their own harnesses, partly to run cheaper open-source models and partly to hedge the cost and geopolitical exposure of depending on frontier providers. Harness engineering is already showing up as a taught discipline, which is usually the sign that something has stopped being a niche. The show also changes format starting next week: YouTube instead of LinkedIn, Wednesdays at 2 PM ET instead of Fridays, and 25 minutes instead of 15. Key takeaways: When an agent underperforms, change the harness before you change the model. A controlled study put the capability difference at roughly 8x with the model held constant, so the scaffolding is usually where the leverage actually is.Pick the lowest rung of the ladder that does your job. Chat, session-based agent, always-on. Capability and fragility climb together, so buying capability you do not need means buying failure modes you did not want.Instrument always-on agents for silent failure before you rely on them. OpenClaw dying quietly on a background task is invisible until you deliberately enable traceability, and an agent that fails without telling you is worse than one that does not run.If you fork an always-on harness, you own its updates. Chris forked Hermes, customized it, and then could not take a safe update. That is the real price of the control, and it is not payable in AI time.If you are at a company weighing frontier model dependency, start scoping what your own harness would look like now. The argument for it is cost and concentration risk, not capability, and the tooling and teaching around harness engineering is arriving quickly.Watch the video version on YouTube · Full show notes, transcript + takeaways

  2. Jul 24

    My Agent Writes My Emails. A Review Gate Decides If They Go.

    Chris drove this one solo-demo style, no guest, closing out the AI-for-enterprise arc for now to make room for other topics. He walked through TheGrove, his personal agent system, and specifically the Follow-up Engine: an agent that reads meeting notes and call transcripts and drafts the follow-up email in his own voice. The demo used a sanitized mock transcript (a made-up company, "Harborline Financial") - the agent identified attendees, pulled out three to five commitments, let Chris reassign a miscategorized commitment to the right person, and then drafted a follow-up email trained on hundreds of his real emails and Teams messages for tone, format, and sentence length. The core mechanic: the agent only ever produces a draft. It lands in a review gate before anything sends, and the system logs the diff between what the agent wrote and what Chris actually sent - word changes, tone changes, punctuation - so it keeps learning from his edits over time. Every Friday he gets a "Follow-up Friday" digest on Telegram: how many emails sent, average edit rate, how many went out verbatim. The goal isn't a smarter agent, it's fewer edits, earned one draft at a time. Chris also showed the daily morning digest (calendar, blind-spot detection between work and personal calendars, overdue commitments) and the one-click "action debrief" summary send, which has a safety-mode toggle so it can't accidentally reach real customers. They closed by teasing next week's episode: the harness (not the model) is often what actually determines agent capability, and they're breaking down the spectrum from chat to agentic to always-on autonomous systems. Key takeaways: Constrain what the agent is allowed to generate (one paragraph, not a whole email) so the review step stays fast and the failure mode stays small.Log the diff between agent draft and human-sent output. That diff is the training signal for reducing future edits, not just an audit trail.A "blind spot" check (comparing personal vs. work calendars) is a simple, high-value use of an always-on agent that has nothing to do with generation quality.Feed an AI writing tool your own transcripts and sent-item history if you want it to actually sound like you, not a generic assistant voice.A safety-mode toggle on any agent action that can reach a real customer is a cheap insurance policy against an expensive mistake.Watch the video version on YouTube · Full show notes, transcript + takeaways

  3. Jul 17

    AI for Enterprise: Institutional Knowledge

    This is episode four of the AI for Enterprise series and the most practical one yet. Sash walks through what Claude skills actually are - a folder with a skill.md file written in plain English, plus any reference files, templates, or scripts the workflow needs. The standard was released by Anthropic in November 2025, and within two months 16 other vendors adopted it, including Microsoft (it shows up as skill.md in M365 Copilot Agent Builder). That portability is the point: a skill you write for Claude today can move to Replit or Cursor unchanged. The bulk of the conversation is about why skills beat agents for most enterprise use cases. Sash's rule of thumb is direct: only reach for an agent when a skill would overflow the context window and lose quality. Otherwise a skill running inside Claude chat or Claude Cowork delivers consistent, predictable output at predictable token cost - which is exactly what you need when ten SDRs or twenty marketers are all hitting the same process. He showed his own skill library live: a simple create-doc skill with just a skill.md, versus a multi-agentic deep-research skill with four reference files providing process context. Chris tied it to the enterprise governance angle the series has been building toward. Skills are a pro-code-to-low-code bridge: your AI architects build and vet the skills, the Centre of Excellence promotes them, and frontline workers get approved, consistent AI behavior at scale. Chris also confirmed this entire show - the episode pipeline, website updates, everything - runs on orchestrating skills that call other skills. The episode closes with a tease: the series is getting a fifth week, and they're bringing in a guest from the enterprise world. Key takeaways: A skill is a folder with a skill.md (plain-English instructions) plus optional reference files, templates, or scripts. No code required to create one.Use an agent only when a skill would overflow the context window. For everything else - outreach sequences, briefing, battle cards, brand copy - a skill is cleaner and cheaper.Claude Teams and Claude Enterprise let you provision skills at three tiers: owner-only, team-level, or org-wide. Marketing gets marketing skills. Sales gets sales skills. You can centrally update and evaluate them.Let Claude build the skill for you. Run the process in chat, iterate until the output is right, then ask Claude to package it into a skill. It reads the conversation history and produces the skill folder.Skills created in Claude chat and Claude Cowork are interchangeable. Skills created in Claude Code use a different packaging mechanism and will not appear in Cowork - you may need to recreate them.Watch the video version on YouTube · Full show notes, transcript + takeaways

  4. Jul 10

    AI for Enterprise: Shadow AI

    Chris and Sash spend this episode working through a problem most enterprise leaders already know exists but haven't acted on: employees running AI tools the company never approved. They define Shadow AI plainly - using a model or AI system your company hasn't sanctioned to do work - and draw a direct line from the old Shadow IT problem (pulling data into a personal Dropbox) to the new one (uploading confidential documents to a personal Perplexity or OpenAI free subscription with model training not disabled). The key difference they land on is that with Shadow AI, there's always a third party involved from the jump, and the exposure doesn't stay contained. Sash makes the stakes concrete: run OpenClaw on your home Mac, plug in your company email, and you now have a fully autonomous always-on agent with access to everything - and the people most likely to do this are executives, the exact employees carrying the most sensitive data. Chris connects this to his BI background - Shadow IT in Power BI meant bad analysis on a local Excel file, low stakes. Shadow AI means confidential strategy going into a free-tier model and potentially becoming training data for a competitor's next GPT. The back half of the episode is where it gets actionable. Sash's rule for agent governance: no agent runs in production without a harness that lets you trace it, period. Chris pushes the parallel to how enterprises managed the cloud migration - the same people/process/technology pillars (ITIL, NIST, ISO) apply here, just moving 10x faster. Both agree banning doesn't work - the more you restrict, the more people find workarounds - and that governed AI means giving employees the tools they actually need, with guardrails in place, not cutting off access and waiting for the breach. The episode closes with a preview of week four: skills as institutional knowledge, and how deploying consistent agent skills across a team is how you get predictable costs and consistent outputs. Key takeaways: Define Shadow AI clearly for your org before you try to govern it: any AI model or system not approved by the company, used on company work, with a third party receiving your data.The real risk isn't the casual browser user - it's the executive running an autonomous agent connected to their company email on a personal subscription.Banning doesn't work. Employees who find AI useful will route around restrictions. Give them sanctioned tools with guardrails instead.Every agent running in production needs a monitoring and evaluation harness that lets you trace what it's doing. No exceptions, no matter how small the agent.Apply the frameworks you already know - ITIL, NIST, ISO, data classification, sensitivity labels - to AI governance. The technology is new; the governance pillars are not.Watch the video version on YouTube · Full show notes, transcript + takeaways

  5. Jul 3

    AI for Enterprise: Token Budgeting

    This is the re-record of episode two of the AI for Enterprise series - the first take went out with Sash's audio muted, so Chris and Sash ran it back. The topic is the one landing in every CFO and CTO inbox right now: why AI token budgets are blowing up and what to actually do about it. The catalyst is real - Uber gave engineers $1,500 a month of API budget and the whole company burned its entire year's allocation in four months. The point Sash keeps returning to is that an AI budget cannot be a single line item. The money has to go across people, process, and technology - rethinking workflows and re-skilling teams, not just paying for tokens. The spine of the episode is a model for enterprise AI spend split into three workloads, each with a different cost curve. Chat is table stakes: 80-90% of an organization gets incremental productivity from browser-based assistants, and that cost is trending to zero (Microsoft M365 Copilot, free chat tiers). Coding carries the highest and most defensible spend, because software ROI is a solved measurement problem - faster features and shipped products tie straight to revenue, so the high token output is justifiable. Agentic is the fuzziest and most dangerous: agents are non-deterministic, run a lot of background work, and if you are not watching the meter one stuck long-running agent can burn the budget overnight. Sash's cautionary number is a real one - an agent that got stuck in a loop ran up a $35,000 API bill. The practical guidance is concrete. Start everyone on $20 plans, detect power users from real usage patterns, and use plan-plus-usage as a middle tier before jumping to the $100 5x plans. Build every production agent with an eval harness and a kill switch, and set hard token and time budgets before you deploy. For coding and agentic volume, take frontier-model risk seriously - if Opus or GPT gets turned off tomorrow, teams running production processes on it are stranded - so pair a frontier strategy with an open-source one: self-host a strong open model (Qwen 32B fits in 24GB, plus Kimi K2 and GLM) on your own hardware, controlling both cost and risk. This is the cloud-era dual-provider playbook applied to models. It closes on the phrase that names the show: own the harness, run a powerful open model, harness in the loop. Tools like Codex Bar (Peter Steinberger) for token monitoring and Paperclip for per-agent budgets and auto-kill are where the governance layer is starting to form. Key takeaways: Split enterprise AI spend into three workloads before budgeting - chat, coding, agentic - because each has a completely different cost curve and risk profile.Coding is the highest and most justifiable spend; its ROI is measurable because it ties directly to shipped features and revenue. Chat is trending toward zero; agentic is the fuzzy, dangerous one.Do not deploy an agent without a hard token/time budget, an eval harness, and a kill switch - one stuck long-running agent ran up a $35,000 API bill.Tier your plans by real usage: start everyone at $20, detect power users, and use plan-plus-usage as a middle step before the $100 5x plans.Pair a frontier-model strategy with an open-source one. Self-hosting a strong open model (Qwen 32B, Kimi K2, GLM) on your own hardware controls cost and removes the risk of a frontier model being turned off.Monitoring is the whole game - you cannot budget what you cannot see. Bring in token monitoring (Codex Bar) and a governance layer (Paperclip) with per-agent caps and auto-kill.Watch the video version on YouTube · Full show notes, transcript + takeaways

  6. Jun 26

    AI for Enterprise: Responsible AI

    Chris opens this episode - the first of a four-part AI for Enterprise series - with a challenge to the room: Responsible AI is the part of every AI presentation where people pull out their phones. Not anymore. The regulatory environment has shifted, and a $35 million EU AI Act fine has a way of making even the most skeptical CIO lean forward. Chris draws directly from his time at Microsoft, where he presented the company's OpenAI partnership to enterprise executives and got deep into how Microsoft embedded Responsible AI into every engineering group, reporting to Satya's ELT. The core of the episode is Chris walking through Microsoft's six Responsible AI principles - fairness, reliability and safety, privacy and security, inclusiveness, transparency, and accountability - and showing how he has applied that same structure inside his own personal build system, TheGrove. The key moment is when he reveals that he runs a Responsible AI agent as a mandatory gate in his SDLC: after Red Team and CTO architecture review, Responsible AI must sign off before any feature ships. More pointedly, he has blocked builds from ever reaching a development environment because they failed to satisfy all six principles. He acknowledges the tension directly - a Claude agent evaluating a Claude-built plan is not an objective reviewer - which is precisely why the flag goes to him for human sign-off, not automatic rejection. Sash grounds the conversation in the practical cost argument: the cost of doing this right now is not close to the cost of a fine. Chris brings in two vendor-neutral reference points - the NIST AI Risk Management Framework as a non-Microsoft alternative, and Azure AI Content Safety as a low-cost front-door filter for prompt and response classification across hate, violence, jailbreak, and hallucination categories. The episode closes with a tease of what is coming: EP.014 on token maxing and EP.015 on shadow AI, with the series building toward a full enterprise AI governance picture. Key takeaways: Responsible AI governance is cheaper to build in than to bolt on after a violation - the EU AI Act can fine organizations up to $35 million for major infractions.Microsoft's six principles (fairness, reliability and safety, privacy and security, inclusiveness, transparency, accountability) are a practical starting checklist for any enterprise building AI systems.Run Responsible AI review before build, not just after - Chris gates features at the planning stage and has stopped builds from reaching dev because they did not satisfy all six principles.If you prefer a vendor-neutral framework, look at the NIST AI Risk Management Framework - same governance intent, no Microsoft alignment required.Azure AI Content Safety is one of the cheapest Azure SKUs and acts as a configurable front-door filter for LLM inputs and outputs - covering hate speech, jailbreaking, prompt injection, and hallucination detection on a 0-7 severity scale.Watch the video version on YouTube · Full show notes, transcript + takeaways

  7. Jun 19

    Claude Code Minds OpenClaw

    Sash drives this one, screen-sharing the always-on AI agent he runs in the cloud and showing how Claude Code became the tool that keeps it alive. His agent (Blaze) runs on a standard OpenClaw image inside a Hostinger Linux VPS, controlled over Telegram, and reachable only across a private Tailscale network so no one outside his own devices can touch it. The kicker: Sash had never used Linux. He never SSH'd into the box by hand or hand-edited a config. He asked Claude Code to connect over Tailscale, generate an SSH key, install OpenClaw, and wire it up. Chris runs the same pattern with a Hermes agent on a Mac, and the two setups landed on the identical stack independently - Hostinger, Telegram, Tailscale - which becomes the episode's running joke and its real point: this is just enterprise security and operations practice applied to personal AI agents. The heart of the demo is a live debugging session. Sash had been hitting transient failures where Blaze would go quiet mid-task and silently drop work with no feedback. He pointed Claude Code at the VPS and asked it to verify Blaze's health and hunt for transient errors over the last seven days. Claude Code read the logs and found the real cause: after Sash migrated Blaze off the Anthropic API (which was costing ~$25/day) onto an OpenAI Codex subscription over OAuth, a config parameter - missing assistant retries, defaulted to zero - meant the agent never retried after a stop. It also surfaced a second, invisible failure: Codex OAuth does not expose an embeddings model, so OpenClaw's memory-indexing system had been completely broken for three days and Sash would never have known without asking. The fix is a cheap OpenAI API key just for embeddings. Sash's plan: turn this health check into a weekly skill so Claude Code self-audits the agent on a schedule. The takeaway both hosts keep circling is the orchestrator/watchdog pattern - a primary agent (Claude Code) supervising other autonomous agents, the same way you'd never ask a single SQL table to monitor the health of its own database. That framing sets up the show's next arc: starting next week, a multi-episode "AI for Enterprise" series, opening with Responsible AI (Microsoft's RAI framework, NIST), then token spend and building institutional knowledge through shared skills. Key takeaways: Don't run an always-on agent on your laptop. Put it on a cheap VPS (Hostinger, DigitalOcean), lock it behind a Tailscale private network, and reach it over SSH so no passwords sit in env files and nothing outside your own devices can connect.You don't need to know Linux. Ask Claude Code to connect to the VPS, generate the SSH key, install OpenClaw/Hermes, and configure Telegram - it does the parts you don't know how to do.Running OpenClaw/Hermes on an OpenAI Codex subscription over OAuth avoids per-call API bills (Sash's Anthropic API run was ~$25/day), but watch two gotchas: set missing assistant retries above zero, and add a cheap OpenAI API key for embeddings since Codex OAuth doesn't expose the embeddings model your agent's memory needs.Build a watchdog. Autonomous agents fail silently outside their own scope (dropped Telegram channel, missing API key, broken memory index); have Claude Code read the logs, diagnose, and turn that health check into a weekly skill.The orchestrator pattern - one supervising agent managing others - is just enterprise monitoring practice applied to AI. The health of a system is managed from outside the system.Watch the video version on YouTube · Full show notes, transcript + takeaways

  8. Jun 12

    Fable 5 Kept Its Own Work Log

    We called an audible. Fable 5 - Anthropic's first Mythos-class model the public can actually touch - dropped this week, so the planned episode went out the window. Sash drove. Instead of a launch-day reaction, he showed two days of real work: he handed Fable 5 a job he'd been deferring for weeks, a full 31-lesson curriculum review spread across roughly 40 markdown files, with instructions to reformat lesson timing, reconcile contradictions between lessons, and update the Claude Code configuration by researching current Anthropic docs. Opus 4.1 had choked on the same task earlier with context issues. Sash resumed the exact same Claude Code session, flipped the model from Opus to Fable, and let it run. What stood out was the autonomy. Unprompted, Fable created its own work-log file, spun up a review folder for its notes, confirmed the scope (31 lesson files, 5 project files), then asked a batch of strategic yes/no questions before doing anything. It ran ~26 minutes unattended, fired up six subagents to research and write in parallel, and stopped to ask follow-up questions only when it hit a real decision it shouldn't guess on - like which of two contradicting lessons to keep. Total execution was 29 minutes for work that took Sash two days to review, and he didn't have to change anything. The receipts: 665,000 output tokens (about 80% of Sash's daily 5x Max allowance), 137 file operations, 21 messages back to him, and only three tool errors across the whole run. The pricing catch matters: Fable is roughly 2x the cost of Opus 4.8, bundled into Pro/Max subscriptions only until June 22, after which it moves to usage credits (you pay API cost on top of your subscription). Chris pushed the honest question throughout - when does this actually pay off versus when is Opus still the right call? Key takeaways: Use Fable 5 for long, complex, bounded jobs where you can describe the outcome and walk away - not for trivial chores like organizing a downloads folder. You will just burn tokens.Plan first. Start with the outcome, have Fable reverse-engineer the plan, approve it, then let it execute. It is noticeably better than Opus at building a plan from a stated end state.Higher effort settings (x-high / max) make Fable re-check its own work more, so accuracy increases on longer-running tasks instead of degrading. This is the opposite of watching Opus drift while holding 400K tokens in one context window.Watch your usage. A single review pushed Sash to ~80% of his daily 5x Max limit; on a Pro plan it will eat your allowance fast. Budget Fable for your highest-value task on deck.Resuming an existing Claude Code session and flipping the model (Opus -> Fable) preserves context - a clean way to escalate a task the daily driver stalled on.Watch the video version on YouTube · Full show notes, transcript + takeaways

See All (17)

About

Chris Shanku and Sash Mohapatra - two ex-Microsoft builders - demo one real AI tool per episode, live and unedited. Real people. Real tools. No retakes.

Information