Who Books This

The mix tilts toward people who do not need a full engagement. They need one hour with a peer who has the scar tissue. Three buyer archetypes recur.

• Senior engineers and tech leads with a specific technical blocker: an evaluation harness that does not feel right, a retrieval pipeline returning the wrong chunks, an agent that fails inconsistently, or a latency outlier they cannot explain
• Founders mid-build who want a second opinion on architecture, model selection, or build-vs-buy before they commit six months of engineering to a direction
• Engineering managers who book an hour for their team: the team has three open debates, the manager wants them resolved with an outside expert in the room, decisions documented same day
• Product managers shipping AI features who need a translator: turning ML claims from their team into business language, sanity-checking timelines, calibrating ambition
• Principal engineers preparing to make an architectural recommendation to leadership and wanting a senior peer to red-team the proposal first
• AI startup CTOs who book recurring monthly hours as a low-overhead substitute for a full advisor relationship

What Office Hours Typically Covers

The hour is most useful when the questions are stacked and the answers are mechanical. The list below is from real bookings. None of these required a full engagement. All of them got resolved or substantially advanced inside 60 minutes.

• An evaluation harness that does not feel right: scores are flat across model swaps, holdouts leak into prompts, LLM-as-judge keeps drifting
• A retrieval pipeline returning the wrong chunks: top-k tuning, chunk size and overlap, hybrid search weights, reranker thresholds, query rewriting
• A model selection trade-off the team disagrees on: GPT-5 vs Claude Opus 4.7 vs Gemini vs open-weight, with concrete latency and cost numbers
• An agent that fails inconsistently: tool selection accuracy, context rot, planning drift, recovery loops, step caps, budget enforcement
• A cost or latency outlier that is hard to explain: token accounting, prompt caching gaps, batch vs streaming, fallback chain ordering
• A vendor proposal under evaluation: reading between the lines of the SOW, what to ask in technical due diligence, what to cut in scope
• A hiring decision: calibrating an AI engineering candidate, reviewing their take-home, designing a better technical loop
• A roadmap sanity check: is this 8-week plan actually 8 weeks, or 6 months once you account for evals and observability
• A technical interview prep: helping a founder understand what investors will ask during a fundraise diligence call
• A specific bug or regression: walk through the trace logs together, find the failure surface

How a Session Actually Runs

Office hours runs on a tight format because the value is in the density. Sixty minutes is enough only if context is loaded before the call starts.

• Before the call: a short brief, ideally three to seven questions ranked by importance, plus any code, eval outputs, dashboards, or architecture diagrams that matter. Five to fifteen minutes of prep on your side
• On the call: video, screen share both ways, written notes captured in real time in a shared doc. The first 5 minutes confirms the question stack and prioritization
• Mid-call: working through questions in order. Some get resolved in 3 minutes, some take 20. The clock is shared, the prioritization is yours
• Last 10 minutes: written summary of decisions, recommended actions, and pointers (papers, repos, vendor names, frameworks) for anything that overflowed
• After the call: a written follow-up note with the captured decisions and any specific next steps. No invoice surprises, no upsell sequence
• Optional: a follow-up office hour can be booked at any cadence. Some teams book monthly. Most book once and come back two months later with the next stack

What Office Hours Does NOT Cover

The format has hard edges. Most failed bookings are people who needed a different shape of work. Knowing this saves money and time.

• Hands-on implementation: writing or refactoring code lives in a different engagement. Office hours can review code on screen, it does not produce committed PRs
• Multi-day audits: a full architecture review or code audit needs days, not an hour. Use a workshop or a multi-week engagement
• Discovery for a problem you have not yet defined: if you cannot articulate three concrete questions, you are not ready for office hours yet
• Sales pitches for vendors: this is not a procurement call. Bring vendor questions, but the answers will not be flavored by referral commissions
• Confidential due diligence on a third party: typically scoped as a separate paid engagement with appropriate NDAs and conflict checks
• Therapy: the format is not a venting session. Frustration is fine, but the hour goes to decisions, not catharsis

Pricing Context for Single-Session AI Consulting (2026)

Senior AI consulting hourly rates in 2026 cluster between $200 and $500, with specialist domains (agent systems, evaluation infrastructure, regulated AI) at the top of that range or above. Independent consultants with 10+ years of experience and deep domain knowledge typically price single sessions on the higher end because the prep work, on-call thinking, and written follow-up are bundled.

• Market range: $150 to $500 per hour for AI and ML consultants in 2026, with specialist generative AI work taking a 20 to 30 percent premium
• Top-tier independents: $300 to $500+ per hour, often with a minimum session of 60 to 90 minutes
• Single-session structure: prep, live hour, written follow-up bundled into one fee. No retainer, no minimum engagement
• What you do not pay for: discovery calls, statements of work, account managers, slide decks. Office hours is the work
• Comparison: a typical mid-size agency proposal for AI strategy assessment is $15,000 to $40,000 over four to six weeks. Office hours resolves the question class that does not need that surface area

How to Prepare for the Hour

The single highest-leverage thing you can do is write the brief well. A great brief turns a 60 minute hour into the equivalent of three hours of work. A weak brief eats 25 minutes of the call on context.

• Lead with the most important question. Not the easiest. The one that is most expensive to get wrong
• For each question, include one concrete artifact: a code path, an eval output, a screenshot of the dashboard, a vendor proposal, a roadmap doc
• State your current hypothesis. We think the retriever is the bottleneck because X is far stronger than the system is slow
• Name the decision the answer enables. We are choosing between fine-tuning and prompt engineering and need to decide by Friday focuses the hour
• List what you have already tried. Skipping known dead ends is half the value of senior input
• Bring the team members who will execute on the answer. If only the manager is on the call, the decisions get rewritten by the engineers afterward

When Office Hours Is the Right Shape vs Workshop, Retainer, or Full Engagement

Office hours competes with three adjacent formats: workshops (multi-hour or multi-day, full team in the room), monthly retainers (multi-month, ongoing decision rights), and project engagements (defined scope, multi-week, deliverables). The right format depends on the shape of the problem, not the budget.

• Choose office hours when: you have specific stacked questions, you have a working system or a concrete plan, you can articulate three concrete asks
• Choose a workshop when: the team needs to build shared competence on a topic (RAG, agents, evals), not just answer point questions
• Choose a monthly advisory retainer when: you need ongoing input across product, hiring, and architecture, not just a single conversation
• Choose a full project engagement when: the deliverable is code, an architecture document, an eval harness, or a hire, not a conversation
• Choose nothing when: the question is should I use AI and there is no defined product context. Build the product context first

Why the Format Works

Office hours works because most AI engineering questions are not novel. They are versions of problems other practitioners have already debugged. The value of a senior peer in real time is pattern recognition, not original research.

The systems are new. The failure modes are not. Retrieval that returns the wrong chunks, evals that drift, agents that loop, fine-tunes that overfit, vendor proposals that hide complexity in the SOW. These patterns repeat. A senior practitioner who has shipped multiple production AI systems has seen the failure mode you are debugging, usually within the first three minutes of the description.

The pricing reflects density, not duration. You are paying for the years that compressed into the answer, not the hour on the calendar.

FAQ