Aakash GuptaHow to build a Company Operating System with Hermes and OpenClaw
CHAPTERS
- 0:00 – 1:36
Meet the AI operating system at OLX: agents shipping features and validating requests
Mikhail explains how OLX’s agent acts like a company operating system, plugged into tools like Google Workspace, Confluence, Jira, and meeting transcripts. The framing sets up the core promise: stakeholders can interact with the agent directly, and teams increasingly build features with agent support.
- •Agents are building and validating many features end-to-end
- •The agent is integrated with core work systems (Workspace, Confluence, Jira, transcripts)
- •Stakeholders can query the system directly to check feasibility/status
- •The OS metaphor: one interface to coordinate company execution
- 1:36 – 2:43
Why PMs aren’t getting big AI productivity gains: the missing ingredient is organizational context
Aakash tees up the problem: many PMs try lots of AI tools but don’t feel meaningfully more productive. Mikhail positions the breakthrough as not “more prompts,” but making AI context-rich enough to do higher-autonomy work.
- •Many PMs see little productivity lift despite AI tool adoption
- •2–3× gains come from system-level setup, not one-off chats
- •AI value scales with how much company context it has
- •This episode focuses on Hermes/OpenClaw as the enabling stack
- 2:43 – 3:43
Knowledge leakage and ‘context as an asset’: the case for digitizing company knowledge
Mikhail describes the old paradigm where key context lives in employees’ heads and walks out the door when they leave. He argues that centralizing product, customer, business, and technical context increases organizational value and allows AI to take on more autonomous tasks.
- •Departing employees create knowledge bottlenecks and leakage
- •A unified store of business/product/customer knowledge becomes a durable asset
- •More context enables greater AI autonomy and higher-level delegation
- •Goal: automate and preserve institutional knowledge continuously
- 3:43 – 7:58
Knowledge graph walkthrough: what’s inside and how to interpret product context coverage
Mikhail tours the company knowledge graph built over five months and explains its layers (product, contacts, teams). He introduces ‘product context coverage’ as a KPI, linking higher coverage to an AI’s ability to act like a capable PM and eventually support strategy decisions.
- •Graph nodes represent people, projects, customers, metrics, interactions
- •Three perspectives: product nodes, contact network, team clusters
- •Coverage metric (~54%) maps to AI capability (junior–mid PM decisions)
- •Graph reveals discovery health, silos, and stakeholder involvement
- 7:58 – 12:14
How to build and measure the graph: prompts, vertical definitions, and tracking improvement
The discussion turns to implementation details: visualization tools and how coverage is scored. Mikhail explains they prompt the AI to estimate knowledge completeness across industry, business model, and customers, then watch the metric improve as teams load more artifacts.
- •Visualization can be done via tools like Obsidian or built with prompts (e.g., Fable)
- •Coverage measurement requires explicit definitions (industry verticals, P&L drivers, segments)
- •AI-generated scoring is directionally accurate and tracks progress over time
- •Coverage increases as PMs ingest transcripts, research, and RFDs into memory
- 12:14 – 15:13
From process-heavy PMing to agentic leadership: what the agentic CPO ‘owns’
Mikhail reframes CPO responsibility from building procedural scaffolding to building an operating system where AI can collaborate and make decisions. He emphasizes quality of AI output and token consumption, and argues the CPO should own the agentic architecture and rituals.
- •Traditional CPO focus: hiring principles, vision, planning cadences, reviews
- •New focus: agentic OS architecture + team training + rituals for daily usage
- •Measure impact via outcomes driven by AI outputs, not volume of artifacts
- •Quality and token budgets become first-class management concerns
- 15:13 – 16:50
Where the time savings come from: delegating rituals so PMs focus on discovery
Mikhail estimates ~50% of PM time historically goes to repetitive rituals—reports, stakeholder updates, demos. By delegating these to AI, PMs can concentrate on high-leverage customer discovery and can effectively cover more scope without adding headcount.
- •PM time sink: recurring reporting, stakeholder management, routine comms
- •These tasks often require low cognitive effort but high manual overhead
- •Offloading creates leverage: one PM can do the work of ~two
- •Human focus shifts to discovery and value definition
- 16:50 – 21:12
Live agent demo: status reports and the stakeholder ‘gatekeeper’ workflow
Mikhail demonstrates asking the agent for project status and explains how outputs can be delivered in Slack/Docs/Confluence. He then introduces the stakeholder gatekeeper pattern: stakeholders must first work through the agent, which asks clarifying questions and either rejects or routes requests into the backlog with the right owner.
- •Status reporting on-demand with structured, factual updates
- •Multi-channel delivery (Slack, Google Docs, Confluence)
- •Stakeholder feature requests are triaged by an agent before reaching PMs
- •Agent asks clarifying questions, evaluates, then rejects or escalates + logs to backlog
- 21:12 – 22:28
Why the CPO must own the agent: iteration speed and business-level decision impact
Aakash asks whether this should be delegated to AI ops; Mikhail argues it’s risky. He believes CPO ownership ensures rapid feedback-to-deploy cycles and appropriate accountability because the system affects time savings and decision-making across the business.
- •Direct ownership enables fastest iteration from feedback to deployment
- •The OS influences prioritization and business outcomes; needs executive accountability
- •Delegating to teams without ‘skin in the game’ slows improvements
- •CPO as orchestrator of organization-wide decision systems
- 22:28 – 25:23
Inside the architecture: OpenClaw + Hermes, and three layers of memory
Mikhail explains the blended stack: OpenClaw for scaffolding and Hermes for automated skill generation (with measurable recall gains). He outlines three memory layers—knowledge graph, vector database, and raw transcript storage—to create robust retrieval and continuous learning.
- •OpenClaw provides strong scaffolding; Hermes adds auto skill generation
- •Three memory layers: knowledge graph + vector DB + persistent transcripts
- •Vector DB enables fuzzy retrieval for ambiguous queries
- •Daily MD transcript storage captures meetings, chats, and reflections for continuity
- 25:23 – 31:47
Why summarizing hurts recall: keep raw transcripts and rely on hybrid retrieval
They discuss whether transcripts should be condensed to remove noise. Mikhail shares testing results showing summarization reduces retrieval fidelity due to lost nuance and forced templates, so they store raw conversations since storage is cheap.
- •Summaries drop granular details needed for accurate retrieval
- •Templates impose bias about what matters, reducing fidelity
- •Testing showed ~20–25% worse recall with summarization
- •Decision: store raw transcripts; let retrieval fetch only relevant slices
- 31:47 – 35:01
Imperatives and control files (CLAUDE.md, SOUL.md): preventing hallucinations and ‘fake helpful’ behavior
Mikhail describes building a large set of rules/imperatives to shape agent behavior—fact-first outputs, thinking before acting, no fabrications, and avoiding useless advice. They explain how CLAUDE.md and SOUL.md function as layered, prioritized context (short high-priority vs longer operating constraints).
- •Imperatives counter LLM biases toward plausible-sounding but wrong output
- •Key constraints: no fabrication, facts over guesses, avoid contradictions
- •Anti-pattern: ‘fake helpful’ responses when tools fail; add rules to prevent it
- •CLAUDE.md: highest priority, kept concise; SOUL.md: longer second-priority operating context
- 35:01 – 37:52
Tooling and workflows: MCP-style integrations, GitHub-based changes, and multi-agent IDE setup
The conversation covers how the agent connects to tools (Google, Atlassian, automations like app-review digests) and how Mikhail ships changes quickly. He describes using Claude App + GitHub commits for on-the-go updates, and using multiple IDE instances for parallel autonomous agents when local computer access is needed.
- •Tools include Google Workspace, Atlassian, and automation jobs (e.g., app review digests)
- •Natural-language-to-code workflows; changes committed directly to a repo
- •Claude App for cloud work and mobile access; IDE when local files/browser/excel are needed
- •Two IDEs enable parallel agent instances running simultaneously
- 37:52 – 41:49
Hermes auto-generated skills and measurement: the +31% recall evaluation method
Mikhail details Hermes’ ability to detect repeated tasks and generate reusable skills, improving response accuracy. He explains a simple evaluation approach: identify frequent domains, generate question sets, compare control vs skill-enabled answers, and then automate ongoing evals.
- •Hermes detects repeated workflows and creates skills proactively
- •Skills improved accuracy/recall by ~31% in their tests
- •Eval method: pick key domains, ask sets of questions, compare with/without skills
- •Once methodology is set, the system can run evals automatically with spot checks
- 41:49 – 57:19
High-leverage use cases: board ‘mental model’ skill, access control, design system, backlog, assistant, and recruiting
Mikhail showcases practical applications beyond status: a ‘board skill’ that critiques strategy decks using learned director perspectives, with access controls and privacy opt-ins. He then covers design system generation and maintenance, backlog abstraction across team spreadsheets, personal email/calendar management via digests, and recruiting automation through LinkedIn/CRM/interview transcripts.
- •Board skill: stress-test decks using synthesized board principles; restricted to exec scope
- •Access rights + privacy: opt-in transcription; scoped retrieval by role
- •Design system: generated from prompts, continuously maintained with human review
- •Backlog: agent connects to team backlogs, proposes items, and routes to owners
- •Personal assistant: scheduling, daily digests, email triage, draft replies
- •Recruiting: LinkedIn sourcing, CRM updates, transcript-based feedback + tailored rejections
- 57:19 – 1:06:22
Future of PM jobs: smaller teams, blurred role boundaries, and hiring AI-native PMs
They close with implications for careers: PM work becomes less about corporate theater and more about discovery and value creation. Mikhail predicts smaller, faster teams, blurrier PM/engineering/design boundaries around quality and token budgets, and shares how he screens for AI-native PM craft in hiring.
- •PM doesn’t disappear; it refocuses on value discovery and customer insight
- •Teams become smaller/leaner; PM-to-engineer ratios shift
- •Roles blur: PM/EM/design all orchestrate quality + token budgets
- •Staffing changes by domain complexity and error blast radius
- •Hiring: test fundamentals + depth of AI automation and evaluation practices
