Hamel-Husain

Adam — Modal engineer, maintainer of Prefect and FastMCP — on Hamel Husain’s channel, making the case that environment engineering, not agent design, is the hard part of background agents. ~27 minutes. The thesis Agents have converged on a universal design (harness + context); the differentiator is the environment they operate in An homage to Anthropic’s “Don’t Build Agents, Build Skills” — one layer up: “the hard part of background agents is the background part, not the agent part” Dev boxes, not sandboxes A bare sandbox can’t run a server, take screenshots, or profile on a GPU — an agent is doomed without a machine prepped for its task CI/CD treats environments as jobs: clone, run deterministic tests, throw away Agents need sessions: resumable state (snapshot the filesystem, resume mid-thought), an environment that’s alive (repo drifted, ffmpeg now needed), a different security boundary, and cold starts that don’t make you wait 2-10 minutes every spin-up What Ramp and others converged on Per-repo images defined in code, rebuilt on a 30-minute schedule so agents boot warm in under a second Secrets kept out of the environment — agents submit requests to a proxy sidecar that attaches credentials deterministically Result: ~1M sandboxes, ~70% of Ramp’s PRs from background agents Async image builds mean humans never pay for the expensive rebuild Control plane vs data plane The old pattern (agent + tools in one process) means one aberrant tool call kills the agent holding the state Put a fire door between the planner and the executor: the agent lives in the control plane and executes work in a throwaway dev box — at worst the data-plane environment gets corrupted, never the agent Same principle as Airflow never running Spark itself Build vs buy The dev box supply chain is where to invest; Modal’s docs/examples cover single coding agents, a Lovable-style builder, LangGraph, computer-use, code interpreters Observability of “software factories” — instrumenting the impact of hundreds of agents, not one agent — is an underexplored open problem “The hard part of the background agents is always the background part and not the agent part.” ...

Shreya Shankar (evals researcher, taught the evals course now at 4,500+ students) and Hamel Husain on Peter Yang’s channel — 54 minutes of live demo: using Claude Code to turn your taste into evals, plus Hamel’s benchmark of the “auto-eval” vendor tools. Evals still start with data The fundamentals haven’t changed: look at data first, do error analysis, externalize your taste and judgment before writing any eval What changed: agents are now good enough to help you look at the data — running in the background while you review, giving you leverage in that first stage They’ve become bigger fans of LLM judges: an LLM judging a trace against one very specific, well-defined criterion (too long? too short? follows structure?) is now quite accurate Top-down vs bottom-up evals Top-down: from the task description alone — what makes good output? Word length, action verbs, actionable takeaways. Claude is very good at generating these Bottom-up: discovered by reviewing many sample outputs — your gut vibes and feedback externalized into criteria. Claude is very bad at coming up with these. That’s all you. And it’s why they accumulate over time Peter’s podcast-takeaway skill is the live example: he has the top-down half (character-length checks, “understandable without watching the episode”), but the bottom-up half is where the question mark lives — is it exhaustive of all the feedback he’s given across every episode? His loop: run the skill → go back and forth → “reflect on our entire conversation and update the skill and evals so we don’t have to do this again” — with the honest worry that it overfits (one interview’s MECE complaint may not matter for the next) Three practical tips for eval-heavy skills Separate your evals into top-down and bottom-up inside the skill itself Fan out to sub-agents: with lots of criteria, give one sub-agent one criterion (or group) — give a model the whole list and it gets lazy and ignores things; focus it on one piece and it really focuses Have the AI write a spreadsheet / pivot table of criteria × pass-fail indicators, so you can see the hierarchy yourself and make judgment calls on what matters for this particular case The error discovery skill (the live demo) Open-source, free (link in the episode description) — invoked from Claude Code; it built the whole review interface from scratch in ~15 minutes, live on camera Five steps: Read the dataset and figure out its semantic type (article? code? traces?) Design a visual encoding — color, spacing, opacity (Gestalt principles) to show what varies in the data Build an interface — an HTML review app (Python backend); “so much better than me looking at my data in Google spreadsheets” Pick which samples you should look at — clustering, diverse initial sample Interactive loop — the agent watches your in-situ feedback via the monitor tool and proposes new samples or rubric criteria in real time Design philosophy: the human reads and gives open-ended feedback; the agent’s job is not to invent feedback but to group and distill it into actionable rubric criteria The writing demo: he reviewed AI-generated articles and gave taste feedback — “I don’t like negative contrast (‘it’s not X, it’s Y’)”, “I hate the list of threes”, staccato fragments — the agent annotated 361 suggestions across the dataset, and the most frequent failure mode was staccato fragments (he’d have guessed negative contrast) Live reflection beats reflect-at-the-end: interleaving human think time with AI think time, and the ~10-notes threshold works as a “carrot” that makes you actually read samples Once the rubric exists: turn it into a skill, one LLM judge per criterion, a dashboard, or live monitoring — the hardest part of evals is error analysis, and this automates the discovery half Bonus: how you eval something should inform how you design its interface — the same failure-mode annotations that power evals would make a great IDE that flags staccato as you write, instead of silently rewriting Do automated evals actually work? (Hamel’s benchmark) Vendor “auto-eval” tools (BrainTrust, Arize, LangSmith) promise: upload traces, chat with an AI, get your evals done Benchmark vs a human-annotated dataset: the tools recover a lot of the errors a human would — but all of them miss the same thing: errors that require product judgment and taste (e.g. a rental bot that doesn’t handle sales objections, or markdown leaking into text messages) Coding agents (Claude, Codex) performed about the same — the harness is thin; it’s someone else’s prompt The real benefit of the vendor tools is integration into your stack (traces in LangSmith → use LangSmith); precision is 80–90% best case, so 10–20% of “errors” found are red herrings — check recall AND precision, and sanity-check what the tool found Bottom line: automated tools get you a good baseline; manual review of the data is the edge — “actually reading stuff” is the edge, in evals and in code “There is no world in the future — even if you have AGI — if you’re building a product, you have to look at your data. You have to be able to inject your taste into the development of your product.” ...

Hamel Husain hosts Marek Galovic, CEO and co-founder of Top-K (ex-Pinecone data plane lead, ex-Shopify), on scaling multi-vector / late-interaction retrieval. ~24 minutes. Why single-vector embeddings fail agents Pooling is a lossy summary — it captures high-level semantics but drops the low-level detail precise queries need Agents issue many specific parallel queries; single-vector retrieval returns the same documents for all of them Agentic retrieval is sequential — noisy retrievals compound errors over multiple hops DeepMind’s limit paper: single vectors can’t capture arbitrary relevance matrices, even with infinite dimensions (embeddings are low-rank) Multi-vector = chop off the pooling layer Keep one embedding per token; score every query token against every document token (max-sim), then aggregate Preserves low-level detail; much better on out-of-domain and long-context retrieval Cost: 10-100x more storage, ~3 orders of magnitude more flops per score Existing workarounds (ColBERT-style compression into IVFPQ indexes) make updates and filtering hard in production Sparse multi-vector encoding (Top-K’s approach) Random projections map token embeddings into tens-of-thousands-dimensional space, then sparsify (keep top-k per token) Aggregating token-level sparse vectors into one document/query vector makes the dot product approximate max-sim Retrieval becomes inverted posting lists like BM25 — cost scales with non-zeros, not ambient dimension Two-stage: prune a billion docs to a few hundred candidates, then re-rank with exact max-sim (1-2 bit quantization, custom kernels, tens of thousands of docs/sec/core) Production numbers Sub-50ms P99 at billion scale; hundreds of QPS; 70MB/s writes with no query-latency impact Object storage as the durable layer + stateless compute; separate read/write pools Quality: a 100M-param multi-vector model outperformed an 8B dense model by ~40% on some video-doc retrieval; on BrowseComp an off-the-shelf 120B open model + multi-vector matched a proprietary GPT-5 setup; OfficeQA Pro went 18% @ $6/query → 42% @ $0.50/query Practical tuning advice Start with evals on your own private data, then hill-climb Dimensions are usually 128; you can prune tokens and quantize without hurting recall Relevance tuning (content score × user signals like distance/popularity) is underrated — e-commerce does it better than RAG teams “If you just vibe it, you can get better vibes from the system, but that’s not systematic. You need evals to know where you stand — and know if you’re improving or regressing.” ...

Hamel Husain hosts Will and Florian from Prime Intellect — the open-source reinforcement learning training team — on using evals to actually improve models. ~36 minutes. An evaluation has three parts Task set — your data, prompts, and scoring methods (what everyone focuses on first) Harness — the program that drives the LLM: Claude Code, Codex, or open-source harnesses like Prime / OpenCode Environment — where it runs: Docker, sandboxes, your own infra “If you are unable to express your task or your problem in any way or capacity, you’re also unable to improve your results.” ...

Shreya Shankar (Stanford, Bargain/LLM cascades) live whiteboards model cascades on Hamel Husain’s channel: cut LLM classification costs by ~90% with no fine-tuning and no accuracy sacrifice. 26 minutes. The problem: the Oracle plan Every record (e.g. customer support tickets) goes to one high-quality LLM (say GPT-5.6) → yes/no label (escalate to human or not) Great accuracy, brutal at scale — back-of-envelope: tens of thousands of dollars for a million tickets Goal: match the Oracle’s accuracy at ~95% agreement on your data, but much cheaper The fix: a model cascade Proxy model first: every ticket hits a cheap nano LLM, which returns a prediction AND a confidence score C(x) (0–1) Decision point: if C(x) ≥ threshold τ, accept the proxy’s label; otherwise route to the Oracle Confidence scores come free from every LLM API (token log probabilities); ground truth = “what the Oracle would say,” not absolute truth Step 1 — find the threshold (offline) Sample 200–500 tickets, run the proxy on each → (prediction, confidence) pairs Label each sample ticket with the Oracle Simulate the cascade for every possible τ = one of the observed confidences: record accuracy and cost Return the τ with minimum cost that still meets the target accuracy — sort ascending and take the first one that qualifies Trivial sanity check: τ = 1 routes everything to the Oracle → 100% by definition; the real question is how low you can go Lower τ = cheaper (more accepted by the proxy) — but the proxy’s mid-confidence predictions are where it gets wrong Step 2 — run the cascade Run the proxy on ALL tickets; accept every C(x) ≥ τ; query the Oracle only on the rest That’s the whole inference path Caveats and results Target accuracy on the full set is an estimate, not a guarantee — you measured it on a sample Statistical guarantees are possible via concentration inequalities; their open-source package/paper (“Bargain”) adds adaptive sampling — plain random sampling wastes effort on low-confidence points that are probably wrong anyway In practice: 90%+ cost cuts on a wide variety of classification tasks with just a nano model Cascades vs. model routers Routers are black boxes — no way to estimate the accuracy you’re actually getting Cascades are sample-driven and fit to YOUR data; the threshold search tells you whether any τ even meets the target Works for binary AND multi-way classification (well-calibrated confidence from logits over the class tokens); not for open-ended tasks — poorly calibrated probabilities there often mean no τ exists Don’t trust the nano model’s confidence a priori — that’s fine. The simulation either finds a threshold that meets the target or it doesn’t; “the procedure is not going to lie to you.” “You don’t have to have any confidence in the confidence.” — Hamel Husain, on why the simulation matters more than trusting the nano model ...

Zach Mueller (head of DevRel at Lambda, ex-Hugging Face) on how to think about open models — which ones, where they run, what they cost, and how to serve them. ~41 minutes on Hamel Husain’s channel. The big claim Open models are good enough for ~90% of queries from ~90% of people — the 10% exception is people pushing the frontier (OpenAI, Google, Anthropic, frontier research labs) Compared to a year ago, massive improvement in intelligence per parameter; small models now generalize, not just hyper-specialize The current open-model landscape Qwen non-MoE (27B, e.g. Qwen3.6 27B) — “the most capable model for an everyday agent”; 4-bit ≈ 14GB → fits a 16GB card; hundreds of people run Hermes agent purely on it Qwen MoE (~30B) — better than bigger Qwen dense models GLM-5.2 (~800B) — his daily driver for coding; needs 6×96GB cards (~$60k) or a big Mac DeepSeek V4 Flash — capable smaller model, a solid Haiku replacement Kimi (3T) — great for writing/review but 8×B200 ≈ 1.5TB VRAM MiniMax — strong but enterprise license changed since 2.6 Nemotron — US-built, US data; easier to get past enterprise “scary Chinese model” objections Speed targets (tokens/sec) 20 tok/s — baseline usable: background tasks, CPU offloading of a giant model 50 tok/s — usable workflow, roughly Opus-level; GLM 5.2 self-optimized its own deployment from 20→47 tok/s in a day (200–300M tokens through it in the first week and a half) 100 tok/s — ideal for sub-agents 750 tok/s (GPT-5.6 + Cerebras) — too fast to even review what the model writes; the joke is that becomes the chain of thought, presented at 50 tok/s Quantization FP8 native — most expensive; needed when RL rollouts must match training precision NVFP4 / MXFP4 — near-lossless; NVIDIA ships its own NVFP4 weights via quantize-aware training; Kimi K2 (1T) goes from 8–16 B200s in FP8 to fitting on 4 in NVFP4 His setup: GLM 5.2 NVFP4 on half a B200 cluster, Kimi K2.7 code on the other half Cost and security thinking Don’t point company data at OpenRouter — it routes to providers anywhere (including outside the country) and routers can carry “upload your code” instructions; even American providers (Grok) did it. If you can run it yourself, that’s the lowest-risk variable Buying hardware is usually a flawed equation — GPUs run 40–60% utilization, so “pays for itself at 100%” math doesn’t hold; try 2–3 month spot instances first, track token usage, then decide Self-hosting skills advance your career (his path: Accelerate at Hugging Face → GPUs at home) Serving vLLM — out-of-the-box experience, broad model support, an “oracle” that auto-picks kernels; home/single-node default SGLang — disaggregated inference, cache-aware routing for 100–1000 users; multi-node territory llama.cpp — fine for single-user local; he ignores it for batched/multi-user work Model routing and harnesses KB cache + shared context are everything — cold caches rebuild from scratch on every provider switch, so he won’t use “magic routers” unless he picks the models, the tasks, and stays on one provider Numena Ncode (XDR’s harness): a Claude Code fork with a model stack — Soul (driver) + GLM 5.2 (implementer/overseer) + DeepSeek V4 Flash (writes the code); XDR fine-tuned Kimi K2.6 for it and swaps models to measure how much code each frontier model removes Pi — minimal open-source harness; he replaced 3–4 Claude Code workflows with GLM 5.2 + Pi Amp — opinionated routing baked in (GLM 5.2 workhorse + a “Soul Oracle” for hard problems), API-priced; “the Puck” = an agent over agents Evaluating open LLMs: “vibes” plus trusted people (e.g. XDR); Lambda publishes the LLM index — deploy recipes (Docker) + tokens/sec benchmarks Codex side-note Codex’s computer use operates any app on your Mac; mobile support shows all running sessions/threads on your phone; and Codex can control Codex — fan out a project into 12–15 threads, let them talk to each other, orchestrate “Open weight models are good enough for about 90% of queries from 90% of people.” ...

Shreya Shankar (UC Berkeley PhD) presents DAB — the Data Agent Benchmark (“Can AI agents answer your data questions?”), from her PhD work at Berkeley. ~27 minutes on Hamel Husain’s channel. Why data agents matter Huge real use case: AI answering business questions — much office work is this Enterprises struggle to use Claude Code / Codex off-the-shelf for BI tasks, so they build their own data agents: Uber’s Query GPT (1.2M queries/month at launch), OpenAI’s in-house agent, Databricks, Snowflake Existing benchmarks fall short: Text-to-SQL — assumes clean data in one Postgres/Snowflake; real enterprises have fragmented data; SQL alone isn’t enough (need domain knowledge, reasoning over outputs) Table QA — context table + question; doesn’t scale to enterprise data volume The formative study — 4 real-world challenges Interviews with enterprises + Hasura (PromptQL) surfaced four properties missing from existing benchmarks: ...

Hamel Husain demos a Codex capability most people don’t know about: Codex can control itself — spawning parallel threads, letting them coordinate, and driving computer use. ~5 minutes on his own channel. The demo setup Working project: AEO — optimizing one of his websites for AI discovery (making it findable by AI search engines) Codex listed 16 high-value tasks from the project file (aeo-to-do.md) — the fuel for the orchestration demo Spawning threads Prompt: “Open a new thread for each task and explain how you’d tackle it, along with prerequisite steps” — Codex spawns 16 parallel threads in the sidebar Codex can also rename and delete threads itself Value: manage separate tasks completely independently, no window-jumping Threads talking to threads Inside any thread you can query another: “What is AEO 1 doing? Does it need any help?” Great for orchestrating when things get stuck, or starting a supervisor thread that manages others and unblocks them Steering and queues Ask for a status table when threads finish: which can run in parallel, which need human intervention or input Broadcast guidance to all threads: “Direct threads that can work independently with computer use to start — don’t start work if you need other threads to finish first” One thread inventories the active threads and coordinates the rest — “this starts to become super powerful” Computer use A thread opens the browser itself: checks Bing Webmaster Tools, Google Search Console, etc. It tells Hamel what it needs (accepting a verification), keeps going, and reports when it gets stuck Mobile Same thread list appears on your phone — manage all parallel threads remotely, even away from the computer “You can have Codex control Codex and become a power user to do a lot of things faster and parallelize your work.” ...

Joe Barrow (ex-Amazon/Adobe, ML lead at Pattern Data, now Adobe Research’s Document Intelligence Lab) on choosing an OCR model for AI document processing. 24 minutes on Hamel Husain’s channel. Why OCR matters Your app sits downstream of OCR quality — garbage in, garbage out, no matter what the LLM does after It’s not solved — Anthropic shipped bad PDF handling for a year because it was pulling text, not doing OCR; users noticed OCR is sticky — once you build on a vendor, swapping models is painful (Pattern learned this the hard way) Documents are evil — multi-column layouts, rotated scans, no reading order; TeX-compiled PDFs have no spaces (glyph glue), so naive text extraction gives you one run of characters The decision grid: two axes Text blocks vs. document structure Text blocks: word/line bounding boxes → grounding, evidence highlighting, cheapest Structure: headings, reading order, grouped paragraphs, tables, figure alt text, chart de-rendering → much better LLM input (LLMs are trained on markdown-like structure; raw line runs look like garbage to them) API vs. self-host API: ease of use, vendor support (startups retrain on your bad docs), minimal time — right for ~95% of teams Self-host: control throughput/concurrency (APIs cap concurrent docs — a real bottleneck), stable weights, domain fine-tuning, no lock-in, cheaper at bulk — but only if your time ≈ $0 or you run huge batches The four quadrants Big cloud APIs (AWS Textract, Google Cloud Vision, Azure) — $0.60–1.50 / 1k pages; word+line boxes only; tables/forms a la carte at $10–15 / 1k Document startups (Reducto, Data Lab, Extend, LlamaIndex) — $5–20 / 1k pages, “fast” vs “accurate” tiers; structure included (markdown/HTML, tables, figure boxes) Open pipelines (PaddleOCR, Nemo Tron, Tesseract) — 10–100M params, nearly free, edge-deployable (PaddleOCR runs on phones/e-ink); text lines only, post-process with layout models Open VLMs (LightOn OCR 2, GLM OCR, GOT-OCR, Chandra/Surya) — 600M–8B params, native document structure, ~$0.20–0.30 / 1k pages on a saturated H100; hallucination risk exists but clouds hallucinate on crusty scans too How to actually choose Ignore benchmarks (OmniDocBench, CR Bench) — they’re not run on your data Build a 50–100 page sample of your own representative PDFs Run a few candidates, diff the returned text (catches junk-on-handwriting fast), visualize the boxes ~a day of effort total — then pick Watch the license Chandra/Surya (Data Lab): free only if org < $2M revenue AND not competing with Data Lab LightOn OCR: Apache. GLM OCR: MIT (but relies on PaddlePaddle’s Doc Layout model — Apache — both apply) Self-hosting, for the ~5% who should Inference engines: VL (default, OpenAI-style client) or SGLang; infra: Modal (request-queue scaling beats SageMaker), BaseTen, or big cloud for one-off batches 1B-param models (LightOn, GLM) on H100 → ~10k pages/hr, 20–30¢ / 1k pages; 4×3090 ≈ one H100 → 3–4 pages/sec His 7M-page local-laws dataset: ran over a weekend at ~30¢ / 1k all-in “You can process 1,000 pages per second, but it doesn’t matter if they’re all wrong — then your entire app’s output is going to be garbage.” ...

Lucas Rocha, an engineer at Brazilian edtech Nova Escola and alum of Hamel Husain’s AI Evals course, tells his evals rollout story backwards on Hamel’s channel — 34 minutes on going from a messy spreadsheet to four calibrated judges running in CI and on daily production samples. ...