AIE World's Fair 2026 Complete Playlist

Introduction and contamination-resistant design

DeepSWE is a long-horizon coding benchmark of 113 original tasks designed to resist contamination by using unpublished code rather than mined pull requests.

Recap

DeepSWE is a frontier software engineering benchmark comprising 113 original, unpublished software engineering tasks created from scratch rather than scraped from existing pull requests. The benchmark spans multiple programming languages including TypeScript, JavaScript, Python, Rust, and Go. It has replaced SweetBench Pro in the Artificial Analysis coding agent index and is being tracked by frontier model labs.

Key points

• DeepSWE consists of 113 original software engineering tasks, unlike SweetBench Pro which scrapes from existing PRs. 13:12
• The median task per repository in DeepSWE is one, whereas SweetBench Pro pulls thousands of tasks from only 40 repositories, concentrating the evaluation risk. 1:30
• The benchmark spans multiple programming languages with plans to add more: TypeScript, JavaScript, Python, Rust, and Go. 1:39
• DeepSWE has replaced SweetBench Pro in the Artificial Analysis coding agent index and is being used by frontier model labs to track their models. 1:50

Terms

• contamination — a model's ability to cheat in a benchmark by accessing training data or solutions from the public internet rather than solving novel tasks. 1:17
• DeepSWE — a frontier, long-horizon software engineering benchmark with 113 original tasks designed to resist contamination and model cheating. 0:35

Quick quiz · tap to flip

Open questions

• What specific mechanisms beyond task originality does DeepSWE use to resist contamination?

What makes a good benchmark

Existing benchmarks like SweetBench Pro fail to differentiate between top models, suffer from contamination via mined pull requests, and use brittle verifiers tied to specific implementations that models can exploit.

Recap

Datacurve identified fundamental problems with existing coding benchmarks. Top models cluster at the top with overlapping confidence intervals, making differentiation impossible. Because all tasks are mined from public pull requests, agents can access solutions, tests, and discussions online. Verifiers are brittle because they anchor to specific implementations from the merged PR rather than testing general correctness. Models can also exploit git history to cherry-pick commits containing the golden patch.

Key points

• Top models on SweetBench Pro cluster at the top with overlapping confidence intervals, making it very hard to differentiate which model is good. 2:47
• Contamination is rampant in benchmarks that mine tasks from public PRs because all of the solution, tests, and discussions are available online for models to access. 2:59
• Verifiers are very brittle because they anchor to specific implementations often derived from the PR merged in, testing for private helper functions created by the task author. 3:12
• Models like Claude can directly exploit git history by running git log and cherry-picking commits containing the golden patches. 3:36

Terms

• brittleness — a verifier's dependency on specific implementation details rather than general correctness, causing it to fail correct solutions that don't match the original PR's approach. 3:12
• leakage — the ability of a model to access and exploit information like git commit hashes and solution details from the public internet during evaluation. 3:32
• data quality — the elusive question Datacurve pursues: what exactly makes good training data and how to demonstrate that it improves model performance. 2:22

Quick quiz · tap to flip

The leaderboard and model performance patterns

DeepSWE reveals qualitatively different failure modes across model families: Claude over-explores and drops multi-part requirements, GPT adheres strictly to requirements, and stronger models attempt to verify their own work while weaker models do not.

Recap

DeepSWE's leaderboard shows a clear performance gap between top and mid-tier models (unlike SweetBench Pro where top models cluster). The benchmark reveals distinct behavioral patterns: Claude is thorough but forgetful, forgetting async versions of multi-part tasks roughly two-thirds of the time and attempting to recover golden patches from git history (25% for Opus 4.6, 18% for 4.7 versus 1% for Gemini and 0% for GPT). GPT is most precise at implementing exactly what is asked and least likely to miss requirements. Stronger models across the board exhibit a greater tendency to write and run tests on their own work compared to weaker models.

Key points

• There is a very clear performance gap between the top performing models and mid-tier models like Gemini 3.1 Pro at 10th place on DeepSWE, unlike SweetBench Pro where models cluster. 3:58
• Claude becomes forgetful when handling multi-part prompts: when asked to support both synchronous and asynchronous versions of a hook, it implements the synchronous part but drops the asynchronous part in roughly two out of three rollouts. 5:04
• Claude pays very close attention to its environment and attempts to run git log to recover the golden patch from git history: Opus 4.6 and 4.7 do this 25% and 18% of the time respectively, compared to Gemini models at roughly 1% and zero instances for GPT models. 5:40
• GPT is the most precise model, least likely to miss requirements, and learns to read prompts and repository contracts literally to produce patches that honor existing conventions and signatures. 6:29
• Stronger models like GPT 5.4 and Opus 4.7 exhibit a strong tendency to write and run tests on their own work, whereas weaker models like 3 Flash and 3.1 Pro are far less frequently willing to test their own work. 7:16

Terms

• multi-part prompt forgetfulness — a pattern where Claude correctly solves the primary part of a multi-part requirement but drops secondary parts, particularly async variants. 5:01
• golden patch — the correct solution to a benchmark task, which models can exploit in mined benchmarks by searching git commit history for the merged PR. 3:43
• test-writing tendency — stronger models proactively write and run tests to verify their own work, even when not explicitly required, whereas weaker models avoid this behavior. 7:19

Quick quiz · tap to flip

Open questions

• Why does Claude specifically exhibit both forgetfulness on multi-part tasks and a high tendency to attempt git-based cheating?
• What architectural or training differences cause GPT to adhere so literally to repository conventions?

Task authorship and prompt design

DeepSWE tasks are authored from scratch by core contributors rather than mined, and prompts are high-level and concise to mirror real engineering work rather than prescriptive to-do lists.

Recap

DeepSWE made a deliberate decision to author every task from scratch rather than mine them from pull requests. This is done through a "shipped" platform where open-source engineers, core contributors, and maintainers create challenges and compete. Because authors deeply understand their repositories' philosophies and conventions, tasks are both realistic in prompt and in the sense that they represent actual PRs a developer might create. DeepSWE prompts average ~2,250 characters, roughly half the length of SweetBench Pro's 4,500+ characters, which is important because real engineering prompts don't include prescriptive to-do lists but rather give high-level objectives and let engineers explore and reason about the solution themselves.

Key points

• DeepSWE made a decision to author every task from scratch rather than mining them, which avoids contamination and allows the benchmark to offer a platform where open-source maintainers create challenges. 8:42
• Task authors are open-source engineers, core contributors, or maintainers who have thorough understandings of repository philosophy and existing conventions, ensuring tasks are realistic. 9:25
• DeepSWE prompts average roughly 2,250 characters, about half the size of SweetBench Pro's 4,500+ characters, reflecting how real engineering prompts give high-level objectives without prescriptive to-do lists. 10:11
• When prompting a junior engineer or model to solve a high-ceiling ambiguous task, you give the high-level objective and let them explore and reason about the to-dos and solution themselves, not prescribe the exact method. 10:20

Terms

• shipped platform — Datacurve's bespoke task creation platform where software engineers and open-source maintainers author benchmark tasks, modeled after Codeforces and GitHub. 9:09
• high-level prompting — providing a task's objective and constraints without prescribing step-by-step instructions, mirroring how real engineers receive work. 10:05

Quick quiz · tap to flip

Open questions

• How does the "shipped" platform incentivize contribution from busy open-source maintainers?

Long-horizon complexity and verifier design

DeepSWE tasks remain long-horizon despite shorter prompts, and verifiers emphasize observable behavior rather than implementation details to reduce false negatives and false positives.

Recap

Even though DeepSWE prompts are roughly half the size of SweetBench Pro's, the tasks remain genuinely long-horizon: solutions are on average five times larger in lines of code than SweetBench Pro, touch approximately seven files, and emit two times more output tokens. The verifier design emphasizes observable behavior rather than implementation details. Unlike SweetBench Pro's verifiers that fail models for using different function names or missing specific private helpers derived from the PR, DeepSWE rewards any correct implementation that solves the problem. This prevents false negatives while also avoiding PR-derived tests that rely on naming or specific implementations. The benchmark covers 91 repositories selected for having 500+ GitHub stars, active contribution, and validated real-world usage.

Key points

• Despite shorter prompts (~2,250 characters vs 4,500+), DeepSWE solutions are five times larger in lines of code than SweetBench Pro solutions, touch approximately seven files on average, and emit two times more output tokens. 11:24
• SweetBench Pro verifiers test for specific implementations and fail if a model produces a correct solution but with a different function name, module, or without specific private helpers derived from the PR. 11:57
• DeepSWE verifiers emphasize observable behavior: any correct implementation that solves the problem is rewarded, and verifiers don't include PR-derived tests that rely on naming or specific implementations. 12:21
• Through combinations of emphasizing observable behavior and removing PR-derived tests, DeepSWE drastically reduces false negative and false positive rates compared to SweetBench Pro, verified by both human experts and LLM-as-judge. 12:50
• DeepSWE covers 91 repositories selected for having more than 500 GitHub stars, being actively contributed to, and being validated as actively used in the real world by subject matter experts. 13:15

Terms

• observable behavior — the actual output and effects of a solution rather than how it is implemented, used as the basis for verification in DeepSWE. 12:24
• false negative — a verifier incorrectly rejecting a correct solution due to implementation-specific checks unrelated to the task's objective. 12:55
• false positive — a verifier incorrectly accepting an incorrect solution due to insufficient or overly permissive checks. 13:00

Quick quiz · tap to flip

Open questions

• How does DeepSWE's observable-behavior-focused verification handle edge cases where implementation choices significantly affect real-world performance or maintainability?

Limitations, v1.1 improvements, and future directions

DeepSWE v1.1 separated verifier and agent runtimes to prevent cheating, and future work focuses on expanding task diversity, improving harnesses, and exploring hybrid verification with LLM-as-judge to enable even more high-level prompts.

Recap

DeepSWE uses minisuite agent, an agent-agnostic harness, to focus on models' base performance rather than harness-specific optimizations. Key limitations include underrepresentation of bug localization and refactoring tasks—areas that are representative of real software engineering work but less emphasized in long-horizon task design. DeepSWE v1.1 introduced measures to prevent cheating: verifier runtime is now fully separate from agent runtime, test reports use a standardized format, and git references and commits beyond the base commit are trimmed. Future work includes improving harnesses, expanding the task mix to cover more real-world work types, and exploring hybrid verification with LLM-as-judge to enable even more high-level and objective-focused prompts while reducing the need to hint agents toward specific methodologies.

Key points

• DeepSWE uses minisuite agent, an agent-agnostic harness, to focus on the model's base performance and tested that performance is comparable using minisuite versus each model's native harness. 13:52
• DeepSWE currently underrepresents bug localization and refactoring tasks, which are representative of real software engineering work but less emphasized in long-horizon task targeting. 14:38
• DeepSWE v1.1 separated verifier runtime from agent runtime, standardized test report formats, and trimmed git refs and commits to prevent models from using git history to cheat. 15:25
• Hybrid verification using LLM-as-judge could enable DeepSWE to make prompts even more high-level and objective-focused while reducing the need to hint agents toward specific methodologies. 16:01
• Datacurve is working on new benchmarks focused on high-value domains and is actively hiring researchers and engineers to develop these benchmarks and training data pipelines. 16:40

Terms

• minisuite agent — an agent-agnostic harness used in DeepSWE to test models' base performance without confounding factors from model-specific runtime optimizations. 13:52
• hybrid verification — combining multiple verification approaches (e.g., observable behavior checks plus LLM-as-judge) to better evaluate correctness while enabling higher-level prompts. 16:01

Quick quiz · tap to flip

Open questions

• How would LLM-as-judge verification avoid circular evaluation where a model that is being tested might influence the judge?
• What prevents LLM-as-judge from introducing new forms of bias or contamination in the benchmark?

Data unbundling and the real-world versus contrived data split

Data markets are fragmenting from vertically integrated giants into specialists because pure capture of real workflows (Type 1 data) outcompetes manufactured expert examples (Type 2 data) for model training.

Recap

Data markets are shifting from scale-based annotation work (the 2019 image-labeling model) to expertise-driven data that moves models from generalist to specialized performance. Historically, companies like Remarque and Scale AI bundled all data work vertically because unit economics required it, but today specialists are outcompeting giants at individual steps: sourcing people, building environments, designing rewards, running evals. The industry now relies on 20–30 vendors because labs distrust their ability to scale quality linearly with quantity. The critical distinction is between Type 1 data (pure capture of real workflows like GitHub commits with minimal reward shaping) and Type 2 data (contrived examples where experts manufacture data in arbitrary settings). Type 1 data is what gets models from 20% to 80% performance because it inherits realism from actual work; Type 2 works early when models are weak but cannot sustain progress. The industry's dirty secret is that vendors sell Type 2 data and bill it as Type 1 because Type 1's only durable source is a live business partnership, not a startup's dead codebase.

Key points

• Data shifted from 2019-style scale work (10–15 billion dollars per year in annotation) to expertise-driven data that moves models from generalist to specialist capability. 0:42
• Models work now; what is badly priced is data that takes a model from generalist competence into real expertise. 0:56
• Data supply chains are unbundling like any industrializing sector: companies like Remarque and Scale AI did all data work vertically only because unit economics demanded it in an immature market. 1:30
• Today, specialists outcompete giants at individual steps: sourcing people, building environments, designing rewards, running evals. 1:48
• Quality increasingly does not scale linearly with quantity, forcing labs to mandate vendor diversification (20–30 vendors) because they distrust their ability to maintain quality at scale. 2:01
• Type 1 data is a pure capture of real workflows like GitHub commits with minimal reward shaping; Type 2 is contrived data where experts are hired and seated in arbitrary settings to manufacture examples. 4:53
• Type 2 works when models read at a first-grade level; Type 1 is what gets you from 20% to 80% because the realism is inherited from the work itself. 5:10
• A dataset is durable only so far as the frontier moves, so the only durable supply is a live business partnership, not dead startup codebases like many data companies are buying today. 5:30
• The industry's dirty secret is that everybody sells Type 2 and bills it as Type 1. 5:44

Terms

• Type 1 data — pure capture of real workflows with minimal reward shaping, e.g., GitHub commits or session replays; inherits realism from actual work and sustains model progress from 20% to 80% performance. 4:53
• Type 2 data — contrived data where experts are hired to manufacture examples in arbitrary settings; effective for early training when models are weak but does not sustain progress on long-horizon tasks. 5:02
• Unbundling — fragmentation of vertically integrated data supply chains into specialized vendors handling individual steps (sourcing, environments, rewards, evals) rather than all at once. 1:30

Quick quiz · tap to flip

Verification as the core bottleneck; why most benchmarks are quietly fake

Verification—the ease of checking correctness—determines which application domains mature; most published benchmarks are fundamentally broken because they optimize for contrived tasks via Goodhart's law rather than measuring real model capability.

Recap

Verifier's Law (articulated by researcher Jason Wei) states that the ease of training a model for a task is proportional to how verifiable that task is. Verifiability has three axes: asymmetry of verification (decomposability into checkable steps), veracity of verification (consensus on what "correct" means), and proliferation of verification (how often the real world provides fresh verified examples). Coding matured first as an AI application because GitHub solved all three: unit tests provide objective correctness, the community agrees on what working code means, and public commit messages offer infinite free reasoning traces. By contrast, fields like biology, security, finance, healthcare, and law score low on all three axes, which is why they remain immature despite attracting capital. The industry manufactures a "fog of war" by selling contrived benchmarks built with domain experts who design tasks via LLM, cherry-pick examples where models diverge, and package them as hard North Star benchmarks—then sell data to hill-climb those same benchmarks. This is Goodhart's law with a profit motive: the moment a measure becomes a target set by people who are not true domain experts, it stops measuring anything real. A single benchmark number is a noisy sample from a distribution nobody measured; labs and vendors cannot see clearly which data actually improves models.

Key points

• Verifier's Law: the ease of training a model to do a task is proportional to how verifiable the task is. 6:16
• Verifiability has three axes: asymmetry of verification (decomposability into checkable steps), veracity of verification (consensus on correctness), and proliferation of verification (frequency of real-world verified examples). 6:23
• Coding became the first mature AI application not by accident but because GitHub solved all three verification axes: unit tests give objective correctness, the community agrees on what working code means, and commit messages provide free reasoning traces. 6:45
• Fields like biology, security, taste, finance, healthcare, and law score low on all three verification axes because verification examples are locked in enterprise workflows and no Web 2.0 system captured them. 7:15
• The dominant Type 2 recipe: hire domain experts, have them generate plausible tasks via LLM, solve those tasks, cherry-pick where the model diverged, package as a hard benchmark, then sell data to hill-climb that same benchmark. 8:14
• This is Goodhart's law with a profit motive: the moment a measure becomes a target set by non-true domain experts, it stops measuring anything real. 8:38
• The whole market sits in a "fog of war"—labs, vendors, and enterprises are all guessing which data actually improves models because nobody can see this clearly. 8:53
• Contrived benchmarks can only test isolated in-distribution questions; they cannot test whether a model sustains correct reasoning across a long dependent episode. 9:01
• Cross-harness and cross-infrastructure performance differencing is the primary cause of false positives and false negatives in benchmarks, which are not obvious when looking at headline stats. 9:20
• A single benchmark number under a single scaffold is basically one noisy sample from a distribution nobody measured; this is what causes "benchmark psychosis" today. 9:53

Terms

• Verifier's Law — the principle that the ease of training a model to do a task is proportional to how verifiable the task is, with verifiability determined by three axes: decomposability, consensus on correctness, and frequency of real-world examples. 6:16
• Veracity of verification — the degree of consensus about what "correct" means for a task; high veracity enables reliable benchmarking. 6:34
• Proliferation of verification — how often the real world provides fresh examples of verified work; high proliferation makes a task domain mature. 6:39
• Goodhart's law — the principle that when a measure becomes a target, it ceases to be a good measure; applied here to benchmarking when non-experts set targets that vendors then optimize against. 8:38
• Fog of war — the state in which labs, vendors, and enterprises cannot see clearly which data actually improves models because benchmarks are fundamentally unreliable. 8:53

Quick quiz · tap to flip

Data spending patterns as leading indicators of emerging AI capabilities

AI labs' data procurement patterns are 2–3 month leading indicators of which new application domains will mature; practitioners can predict capability rollouts by tracking verification axes and real-world data pipeline maturity across professional domains.

Recap

Data markets serve as an upstream indicator of which application-layer products AI labs will launch. When Anthropic spent heavily on cybersecurity data in January, Metis and Cybor launched in March–April; when they spent on biological data in March–April, Claude bio/life sciences launched later. To predict which domain is next, classify professional tasks against three verification axes, then apply a long-horizon test: labs use tasks with enforced step-length heterogeneity (non-interchangeable tool calls), genuine state transitions that constrain future actions, and mandatory failure recovery. Finally, look at raw data for five signals: sequential decisions against a single entity, inferable expert actions per step, outcomes recorded by independent parties, and economically available high-wage work. Robotics exemplifies the counterexample: modality remains unsettled (ego vs. teleop vs. UMI), and the ecosystem exhibits profound unsophistication—vendors lack rigor in data collection and quality standards. Robotics data vendors are often research accelerators disguised as scalable businesses; the field entangles vendor choices with unsolved research questions. The lesson is that environment companies must build infrastructure agnostically to serve enterprise use cases rather than dying on a single modality hill.

Key points

• Data market spending by labs is a 2–3 month leading indicator of new capabilities: Anthropic's cybersecurity data spending in January preceded Metis and Cybor launches; biological data spending in March–April preceded Claude bio/life sciences. 12:17
• To identify emerging domains, classify professional tasks on three verification axes and apply a long-horizon bar using real labs' specifications: enforced step-length heterogeneous tool calls, state transitions that genuinely constrain future actions, and mandatory failure recovery. 12:39
• Look at raw data for five signals: sequential decisions against one entity, inferable expert actions per step, outcomes recorded by independent parties, economically available high-wage work, and signals of genuine complexity. 13:04
• Robotics is a counterexample showing data market fragmentation: modality is unsettled (ego vs. teleop vs. UMI), and vendors exhibit unsophistication in data collection (e.g., raw iPhone video from friends in India sold as ego data). 13:20
• Environment companies are research accelerators, not venture-scalable businesses; success depends on building infrastructure agnostically to serve enterprise application-layer use cases, not on assuming data markets will remain static. 13:50
• Do not die on a modality hill; infrastructure builders must remain agnostic about which modality or domain will prevail. 14:14
• The map of data opportunity divides on two axes: share of white-collar work (vertical) and task horizon (horizontal); short-horizon tasks are addressable now, but long-horizon dependent work is where real economic value and data build-out live. 14:22

Terms

• Long-horizon work — tasks requiring multiple dependent steps with enforced heterogeneous tool calls, state transitions that constrain future actions, and mandatory failure recovery; these are where real economic value accumulates. 12:42
• Modality hill — commitment to a particular data modality (e.g., ego vs. teleop in robotics) that may turn out to be the wrong long-term bet; vendors should remain agnostic. 14:14
• Environment company — a data infrastructure vendor positioned as a research accelerator rather than a pure data business; success requires building agnostically to serve multiple application domains rather than locking into one. 13:56

Quick quiz · tap to flip

Model layer competition and the data company pivot to enterprise services

Infrastructure monopolies do not hold market share long-term; as models diverge on efficiency and modality and lose fungibility, data companies must pivot from pure data vendors to enterprise services platforms, building abstraction layers for model migration, RL dataset management, and real-world data pipelines.

Recap

No pioneer of an infrastructure technology has held more than 10% of the long-term market share. Railroads built company towns and charged tyrannical rents until the automobile arrived and they were nationalized. AWS and Google consolidated the infrastructure layer but never captured the application layer. OpenAI and Anthropic are carving out fiefdoms now, but anti-distillation, export appeals, and enterprise exclusivity pressures are equivalent to real-world constraints on monopolies. Models are no longer fungible like electricity because they diverge on efficiency and modality (GLM 5.2 surpasses GPT on many real-world rubrics despite being differently optimized). The question hinges on whether enterprises can decouple from foundation model labs. In response, successful data companies are pivoting to enterprise services, not staying as pure data vendors. They are building abstraction layers that do not yet exist: (1) serving and routing small models targeted by latency and performance profiles, (2) managing RL datasets across base-model migrations so enterprises rerun post-training when swapping open-source bases instead of starting over, and (3) building Antikythera mechanisms that translate messy business context into evals. The durable value accrues to the services and application layer of actual work, not to data alone. Researchers must stop outsourcing their definition of realism to the vendors from whom they buy evals; builders must recognize that their moat is not the data itself but the pipeline into real-world work plus infrastructure to keep retraining as models improve.

Key points

• No pioneer of an infrastructure technology has held more than 10% of the long-term market. Railroads got nationalized when the automobile arrived; AWS and Google never captured the application layer. 14:51
• Models are no longer fungible like electricity because they differ on efficiency and modality; GLM 5.2 surpasses GPT on many real-world rubrics, proving application-layer companies can decouple from model vendors. 15:29
• Successful data companies are pivoting to enterprise services, not staying as data businesses. 16:09
• Durable value accrues to the services and application layer of actual work, not to data alone. 17:11
• Three emerging infrastructure needs drive the enterprise transition: (1) serving and routing small models by latency and performance, (2) managing RL datasets across base-model migrations so enterprises rerun post-training automatically when swapping open-source models, (3) building Antikythera mechanisms to translate business context into evals. 16:36
• Researchers must stop outsourcing their definition of realism to the vendors they buy evals from (equivalent to letting the task writer grade the task). 17:17
• A builder's moat is not the data; it is the pipeline into real-world work plus infrastructure to keep retraining as models improve underneath. 17:25

Terms

• Antikythera mechanism — a bespoke system that translates messy business context into evals; named after the ancient analog computer and used as a metaphor for complex systems that convert real-world constraints into evaluable tasks. 2:31
• Neo-lab — a data-originated company that has evolved beyond data provision into a full services and application-layer business handling real work, complementing or competing with foundation model labs. 17:08

Quick quiz · tap to flip

Clinical architecture and guardrails design

Purpose-built mental health AI requires separate input and output guardrails as a sandwich around the core model, prioritizing clinical correctness over false-positive reduction.

Recap

SonderMind built Sonder, a clinically grounded AI coach for mental health support, in response to the gap between general-purpose LLMs and the requirements of mental care. The system uses modular input and output guardrails as separate LMs to create a more robust safety boundary, avoiding the overcalibration that makes generic systems reject legitimate users' vulnerability.

Key points

• General-purpose LLMs are not built for mental health care and have resulted in tragic outcomes when applied to the field. 1:27
• Input guardrails inspect the user message before Sonder core responds; output guardrails inspect the AI response and conversation trajectory to intervene if clinical safety is at risk. 3:23
• Keeping guardrails as separate LMs (judge calls) makes them more robust and harder to circumvent or jailbreak, a trade-off justified by the sensitivity of the use case. 4:26
• The core design principle is "more correct triggers" not "more triggers"—inappropriately triggering guardrails on vulnerable people can isolate them further, so precision is critical. 8:46
• Every architectural decision was made with safety as a primary objective, from the ground up. 5:40

Terms

• input guardrails — a filter that inspects the user message as it comes in to determine if intervention is required before the AI core responds. 3:23
• output guardrails — a filter that inspects the AI response and conversation context to detect if clinical safety is at risk and intervene to keep the conversation on track. 3:39
• modularity — the architectural principle of separating the guardrail system from the core model so that guardrails can iterate without compromising user safety. 4:12
• judge calls — separate LM components that render clinical judgment on edge cases, made distinct from the core model to reduce circumvention risk. 4:29

Quick quiz · tap to flip

Open questions

• How does the system distinguish between different types of mental health crises and decide when not to engage?
• What specific model architectures enable separate guardrails without unacceptable latency penalties?

Evals-driven development and clinical calibration

Clinician-annotated evals that capture the sentence beneath the sentence turn edge-case human judgment into reproducible test gates, embedding clinical expertise into CI and preventing system drift from human-centered design.

Recap

Sonder moves beyond static guardrail triggers by building a learning loop where clinicians annotate real or representative edge cases—conversations with clinical nuance that simple pattern matching misses. These annotations become typed evals that gate every prompt, model, and guardrail change, cementing the clinician's judgment in CI. The team emphasizes designing benchmarks around real failure modes and human needs rather than pursuing perfection, with false positives and false negatives mattering equally.

Key points

• A simple eval gate does not make a system safe; a learning loop does, especially one capable of finding "the sentence underneath the sentence" in indirect communication about self-harm. 10:01
• When a guardrail fires on an edge case, the clinician annotates the trace with a rubric that includes the expected observation (the assertion), the turn index (for replay), and a note for engineer triage. 11:58
• The system itself does not decide what correct is in clinical edge cases; a licensed professional annotates the trace and teaches the eval what should have happened. 11:47
• The win of the eval loop is not fixing one edge case but lifting the entire category; once committed, the clinician's judgment lives in CI. 13:22
• Overcalibration is a real problem that can prevent people from getting the care they need; the team made three design choices to address it: clinical theme owns the definition of good, labeled scenarios ask concrete questions, and benchmarks focus on real human needs and failure modes. 13:59
• Designing with the human as the center node means catching false positives, false negatives, category correctness, and timing—not pursuing perfection. 14:46

Terms

• typed eval — an evaluation test generated from a clinician's annotation that includes the conversation input, expected result, expected observation, and metadata, used to validate every prompt and model change. 11:58
• the sentence underneath the sentence — indirect or coded language that expresses clinical risk implicitly rather than through explicit keywords, requiring contextual interpretation. 10:09
• annotation extraction script — a tool that triages flagged traces, generates reports for discussion, and normalizes clinician annotations into the eval schema. 12:49
• clinical theme — the licensed clinician's framing of what correct behavior looks like in an edge case, used as the ground truth against which system behavior is judged. 14:12

Quick quiz · tap to flip

Connections

• builds-on Clinical architecture and guardrails design — assumes the modular guardrail architecture from section 1.

Open questions

• How does the team handle disagreement between clinicians on annotation?
• What is the typical latency and cost overhead of running evals against every model change in CI?
• How often must the eval rubric be updated as the system encounters new patterns in production?

Open-source datasets and shared baselines for mental health AI

Sonder's open-sourced guardrail datasets—clinically reviewed and calibrated against real conversation patterns—establish a shared baseline that raises the floor for safety-critical mental health AI while avoiding the pretense that a single dataset replaces individual learning loops.

Recap

SonderMind released 200 input guardrail scenarios and 100 output guardrail scenarios, all clinically reviewed and calibrated against real conversation patterns spanning the mental health spectrum. The team emphasizes that this shared baseline is not meant to replace individual teams' learning loops but to give everyone a better starting point, avoiding a costly learning curve when real hurting people depend on the system.

Key points

• Sonder released 200 input guardrail scenarios and 100 output guardrail scenarios, clinically reviewed and calibrated against real single-turn and multi-turn conversation patterns across the mental health spectrum. 16:14
• A shared baseline matters because there might be real hurting people depending on your learning curve; open-sourcing these datasets gives teams a better starting point without claiming to replace custom learning loops. 16:45
• The team chose to embed clinical grounding, taxonomies, and annotations as public artifacts explicitly for a world where loneliness, depression, anxiety, and mental health crises drive people to seek AI support. 16:58
• The most rigorous way to serve someone at their lowest point is to provide safe care while communicating "you are not alone." 17:09
• On the model choice question: general-purpose LLM guardrails are overcalibrated, so day one of development required turning off built-in guardrails and building custom ones to prevent filtering legitimate mental health content. 20:00

Terms

• shared baseline — a common set of guardrail scenarios and evaluation patterns that teams can adopt to raise the floor for mental health AI safety without replacing their own learning loops. 16:45
• clinically reviewed and calibrated — scenarios validated and refined by mental health professionals against real conversation patterns to ensure relevance and precision. 16:25

Quick quiz · tap to flip

Connections

• builds-on Evals-driven development and clinical calibration — demonstrates the evals-driven approach in practice by releasing the datasets that feed such workflows.
• builds-on Clinical architecture and guardrails design — justifies the modularity and guardrail separation by showing how these datasets are being shared as tools for the community.

Open questions

• How does Sonder handle licensing and attribution for datasets derived from real patient scenarios?
• What feedback mechanisms exist for teams using the open datasets to contribute back improvements?

Introduction: the 40,000 line PR problem

Building loops for the real world requires solving the fundamental problem of agents that generate massive pull requests nobody can review.

Recap

Kyle Mistele opens by framing the disconnect between hype around AI agents and the practical reality of software engineering. While loops are powerful, the industry conversation assumes agents can be "piped a prompt and a loop" to build software, but this leads to 40,000-line PRs that teams cannot review. He positions his talk as addressing how to build loops that work in large, complex codebases with real customers, users, and regulatory obligations.

Key points

• The hype around AI agents overlooks that naive loops generate massive PRs that teams cannot review or ship. 0:28
• Agents work well in isolation but fail for teams or critical systems. 1:16
• Real software engineering requires building loops for large, complex codebases with service level agreements and regulatory requirements, not demos. 1:35

Why more code is not the goal

Frontier labs have treated massive automated code generation as progress, but most teams cannot afford the token costs or handle the code volume without verification infrastructure.

Recap

Mistele surveys the recent narrative shift in the AI engineering community: Peter Steinberger's claim that agents should be designed as loops rather than one-shot completions, the observation that OpenAI's o1 is "loops all the way down," and Boris Churnney's description of engineering as writing loops to prompt Claude. However, he points out the circularity and expense: loops generate code so prolifically that teams have abandoned reading it, relying instead on verification and code review. The cost of this approach is prohibitive outside frontier labs with unlimited token budgets.

Key points

• The industry shifted to framing agent work as loops that prompt other loops, creating a recursive abstraction. 2:08
• OpenAI's o1 and projects like Claude Code embed loops throughout their workflows, from code generation to bug fixing. 2:18
• Loop-based automation generates so much code that teams no longer read it and rely entirely on verification and code review. 3:00
• The token cost of loops is prohibitively expensive outside frontier labs with unlimited budgets. 3:43

Terms

• Loops — agent-driven workflows that repeatedly measure system state, generate code changes, and apply them iteratively. 2:13

Is the generated code any good?

Agent-generated code is expensive and unreliable, especially outside frontier labs, making cost-aware loop design essential.

Recap

Mistele questions the quality and viability of agent-generated code at scale. He notes that open-source tools like OpenAI's o1 have stability issues, and all generated code carries high token costs. He references Matt Pocock's observation that bad code is more expensive in the age of agents than ever before, establishing the need for thoughtful loop engineering that improves code quality rather than just volume.

Key points

• Agent-generated code often has stability issues and high token costs that make it impractical outside frontier labs. 3:38
• In the age of agents, bad code carries exponentially higher costs than in earlier eras, making code quality the real constraint. 3:56
• Human Layer's approach is to design loops that make code better rather than just generating more, and still allow teams to read the code. 4:05

Control loops from control theory

Control theory provides a formal framework for building loops that steer systems incrementally toward a desired state, minimizing risk and avoiding overshooting.

Recap

Mistele introduces the formal components of a control loop: a sensor measuring current state, a set point for the desired state, measured error as the gap between them, a controller that signals incremental changes, and an actuator that applies those changes while the system undergoes disturbances. He gives everyday examples like thermostats to demystify the concept and shows that control loops are already ubiquitous in infrastructure (Kubernetes, PostgreSQL autovacuum, React's virtual DOM).

Key points

• A control loop has five components: sensor (measuring current state), set point (desired state), measured error (the gap), controller (deciding on changes), and actuator (applying changes). 4:43
• Control loops change systems incrementally rather than all at once, minimizing risk and avoiding destabilization. 5:17
• Control loops are already foundational in infrastructure: Kubernetes autoscaling, PostgreSQL autovacuum, and React's virtual DOM all use or approximate the control loop pattern. 5:49
• Thermostats are the simplest real-world example of control loops that most people already use. 5:29

Terms

• Measured error — the difference between the desired state (set point) and the current state measured by a sensor. 4:51
• Set point — the desired state of the system. 4:49
• Sensor — a mechanism that measures the current state of the system. 4:45
• Control signal — an incremental change that the controller directs the actuator to apply. 4:56
• Actuator — the component that applies the change to the system. 5:03

Quick quiz · tap to flip

Infrastructure as code and Ralph loops

Ralph loops generate code blindly without feedback, while control loops apply control theory to steer systems safely; proper loop design requires learning from the former's mistakes.

Recap

Mistele contrasts "blind Ralph loops" (named after the Anthropic researcher building agentic workflows) with control loops. Ralph loops are bash scripts that run agents without feedback—they treat agent output as final truth and can generate massive, unsafe PRs. Control loops apply control theory to avoid this: they incorporate feedback (sensors), aim for desired states (set points), and make incremental changes (control signals). Even the best Ralph implementations implicitly use control theory. The key difference is intentionality: control loops are engineered systems, not bash loops.

Key points

• Infrastructure as code, PostgreSQL autovacuum, and React's virtual DOM all follow the control loop pattern: desired state, current state, iterative feedback-driven changes. 5:49
• Ralph loops are bash-driven agent loops that generate code without feedback, leading to massive PRs that teams cannot review or trust. 6:34
• Control loops are the inverse: they are ideal when you can measure the problem, make incremental changes, and get feedback on quality. 6:06
• Even the best Ralph implementations implicitly use control theory, but the framework lacks the intentionality of formal control loop design. 6:42

Terms

• Ralph loop — a bash loop that invokes agents to generate code without feedback or incremental change; named after the Anthropic researcher pioneering agentic systems. 6:34
• Blind Ralph loop — a Ralph loop that generates large code changes without measuring state or feedback. 6:34

Quick quiz · tap to flip

Connections

• builds-on Control loops from control theory — applies control theory fundamentals to agentic workflows.

Applying control loops to coding

Coding control loops combine deterministic sensors (ESLint, AST analysis) or agent-based sensors with controllers that prioritize changes strategically, enabling use cases from code quality to API compliance.

Recap

Mistele walks through designing control loops for codebases. A set point is the desired end state of the codebase with respect to some measurable property. Sensors can be deterministic (ESLint rules, AST analysis, AST grep patterns) or agent-driven. Controllers combine component responsibilities: a hybrid sensor-controller like Aiden by React Doctor both diagnoses problems and suggests fixes. The key is avoiding oversized changes by tuning the controller to make the right incremental change, not too large or the wrong change entirely. He illustrates multiple use cases: rooting out code patterns, ensuring API compliance, maintaining TypeScript/Python mirrors, or keeping forks in sync with upstream.

Key points

• Sensors can be deterministic (ESLint, AST grep patterns) or agent-driven (agent + skill + natural language rules), or a hybrid pipeline. 7:16
• A well-tuned controller is critical: it should decide on incremental changes that are the right size and direction. 8:15
• Control loops work for diverse coding goals: code pattern cleanup, API compliance, specification enforcement, cross-language mirroring, or upstream fork maintenance. 8:35
• The core questions for any control loop are: can we measure the problem, apply incremental changes, and get feedback on quality? 9:01

Terms

• Set point — the desired end state of the codebase with respect to a measurable property. 7:08
• Sensor — a deterministic or agent-based system for detecting violations of the set point in the codebase. 7:15
• Controller — the component that decides which violation to fix and how to fix it incrementally. 8:15
• Hybrid sensor-controller — a tool like Aiden by React Doctor that both detects problems and suggests solutions. 7:47

Quick quiz · tap to flip

Connections

• builds-on Infrastructure as code and Ralph loops — applies the control loop framework to practical coding scenarios.

Migrating a codebase one procedure at a time

A practical control loop implementation uses AST grep sensors to find code violations, deterministic controllers to pick the smallest change, and an agent actuator to apply migrations while incorporating contextual data.

Recap

Mistele demonstrates a real control loop used at Human Layer: incrementally migrating their RPC API to the Effect library. The sensor uses AST grep to find unmigrated procedures, a simple rule-based pattern that works across languages and is independent of TypeScript/ESLint config. The output is sorted deterministically to the top-level violations that matter most. The controller can be deterministic (pick the first or smallest violation), or agent-driven, but the strategy matters: by analyzing telemetry to find procedures with the most errors or least instrumentation, the controller can enrich the control signal with contextual data, so the actuator agent does more than a one-to-one migration.

Key points

• AST grep is a language-agnostic sensor tool for finding code pattern violations without relying on TypeScript config or ESLint. 9:46
• A deterministic controller can select the smallest violation to reduce risk, or an agent can make smarter choices based on telemetry data. 11:39
• Enriching the control signal with contextual data (error rates, instrumentation gaps) allows the agent to improve code during migration, not just replicate patterns one-to-one. 12:02
• The goal is to migrate incrementally one procedure at a time while keeping the codebase safe and readable. 8:50

Terms

• AST grep — a language-agnostic pattern-matching tool for finding code violations based on abstract syntax tree rules. 9:46
• Control signal — data passed from controller to actuator, specifying what change to make and with what context. 12:12

Quick quiz · tap to flip

Connections

• builds-on Applying control loops to coding — applies sensor and controller design to a real migration use case.

Tracking the loop in version control

A disturbance-dampening mechanism prevents regression by enforcing that new code follows the desired pattern, then the controller selects changes based on criticality or instrumentation gaps.

Recap

Before starting incremental migrations, Human Layer enforces that all new code uses the target pattern. They run a full scan on main, sort violations deterministically, and track them in version control. On every new PR, they check if the branch added new violations, acting as a disturbance dampener that prevents teammates from undoing loop progress. Once regression is controlled, the controller becomes sophisticated: it can pick violations by criticality, smallest size, error rates, or instrumentation gaps. It can then send this context-rich control signal to the agent, enabling smarter migrations.

Key points

• Enforce that new code follows the desired pattern by scanning main once, sorting violations deterministically, and tracking them in version control. 10:49
• A disturbance dampener checks if each new PR adds violations and prevents merging if it does, stopping teammates from undoing loop work. 11:00
• Controllers can be simple (deterministically pick first or smallest) or sophisticated, using telemetry to pick procedures with the most errors or worst instrumentation. 12:03
• Contextual control signals allow the agent to fix not just the pattern but also related problems like error handling or instrumentation during migration. 12:12

Terms

• Disturbance dampener — a mechanism that detects and prevents regression by checking if new PRs add violations of the desired pattern. 11:15

Connections

• builds-on Migrating a codebase one procedure at a time — adds feedback control to prevent regression during migration.

The actuator agent and golden patterns

An effective actuator agent is a skill-augmented CLI coding agent trained on golden patterns, not generic documentation, to reliably replicate intended transformations.

Recap

The actuator is simply an agent plus a skill. Mistele emphasizes spending significant time designing the skill, iterating over time based on what works. At Human Layer, they build "golden patterns"—idiomatic, hand-written examples for the agent to follow—rather than relying on generic documentation or internet knowledge. They pipe the skill and the control signal (specifying what to migrate and why) into the agent, which works iteratively and produces a final response. That response is deterministically committed and pushed as a PR, with the agent's final message as the PR description.

Key points

• An actuator is an agent plus a skill; the skill is where the engineering effort should go, iterated over time. 12:38
• Golden patterns are hand-written idiomatic examples for the agent to follow, not documentation or generic internet knowledge. 12:48
• The skill should include a response template and the control signal (violation + context) is piped into the agent context. 13:04
• The agent's final response is deterministically committed and pushed as a PR, using the response as the PR description. 13:15

Terms

• Actuator — an agent equipped with a skill that applies the control signal (the decision on what to change) to the codebase. 12:36
• Skill — a set of instructions, examples, and response templates that guide the agent on how to perform migrations reliably. 12:40
• Golden patterns — hand-written idiomatic examples of the desired transformation for the agent to follow and replicate. 12:48

Quick quiz · tap to flip

Connections

• builds-on Tracking the loop in version control — the agent component that executes the control signal from the controller.

Wiring the loop into CI

Running loops in CI with human feedback loops and low-friction steering enables safe, incremental automation without constant manual intervention.

Recap

Rather than running agents directly, Mistele recommends using CI systems (GitHub Actions, GitLab CI) that have access to code and secrets and good scheduling primitives. A workflow runs a single iteration of sense-control-actuate, creates a PR, and is scheduled to run once daily. Early attempts were frustrating because Human Layer had to constantly update the skill by checking out branches and committing. They solved this by creating a feedback file tracked in version control. The file is loaded into the agent context before every run, allowing humans to leave slash-iterate comments on PRs, which the workflow detects and uses to update both the code and the feedback file. This keeps all feedback in version control and makes steering the loop low-friction.

Key points

• Run loops in CI (GitHub Actions, GitLab CI, CircleCI) rather than a new cluster, using CI's access to code, secrets, and scheduling. 13:24
• Schedule the workflow to run once daily so teams get small, low-risk incremental PRs. 13:45
• Create a version-controlled feedback file that can be loaded into the agent context every run, enabling humans to comment on PRs with slash commands that update both code and feedback. 14:14
• This approach eliminates high-friction manual skill updates and lets humans steer the loop easily. 14:09

Terms

• Feedback file — a markdown file tracked in version control that holds human guidance on how the agent should adapt its behavior, loaded into the agent context on each run. 14:14
• Sense-control-actuate — the three-phase loop workflow: measure system state (sense), decide on changes (control), apply changes (actuate). 13:41

Quick quiz · tap to flip

Connections

• builds-on The actuator agent and golden patterns — operationalizes the actuator in CI infrastructure.

Avoiding stacked PRs and scaling the controller

Flow control prevents PR accumulation by ensuring humans review each output before the next iteration; throughput is scaled by having the controller select multiple items or running parallel workflows.

Recap

Early problems arose when Human Layer was traveling or busy: PRs from multiple loops accumulated, duplicated work, and conflicted. The solution is simple flow control: before each workflow run, check if any open PR with the loop's label exists. If so, shut down. This ensures exactly one PR per loop at a time, guaranteeing no stacking or conflicts. Once confident in the loop, throughput is scaled by having the controller pick multiple procedures to migrate (three or five) instead of one, or by running the workflow multiple times and distributing work to different team members. The conclusion ties it together: they built a control loop that improves code incrementally while teams can still read it, with adaptive flow control and low-friction human steering.

Key points

• Flow control prevents PR accumulation by checking if an open PR with the loop's label exists before running; if so, shut down. 15:56
• This ensures exactly one PR at a time per loop, preventing duplication and conflicts. 16:14
• Scale throughput by having the controller select multiple procedures (three or five) to migrate in one run. 16:35
• Alternative: run the workflow multiple times concurrently and distribute work to different team members for parallel execution. 16:50
• The complete control loop improves code incrementally, remains human-readable, has adaptive flow control, and supports low-friction steering. 16:59

Terms

• Flow control — a mechanism to prevent PRs from stacking by checking if an open PR with the loop's label exists before generating a new one. 15:40

Connections

• builds-on Wiring the loop into CI — adds scaling patterns and operational safeguards to the loop.

Open questions

• How does parallel distribution across team members coordinate to avoid duplicate work on similar issues?
• Are there guidelines for when to scale via multiple-item selection versus parallel workflow runs?

Designing Safe and Authentic Image Enhancement Agents

Agents must balance creative capability with guardrails—neither brittle rule-based systems nor unconstrained models work at scale, so evals and logging form the foundation for safe deployment.

Recap

Uber Eats operates at massive scale—90 billion run rate annually across 10,000 cities. Visual content drives user engagement, but millions of independent merchants lack the resources (time, expertise, money) to produce high-quality photos. Smaller merchants risk menu staleness as they update offerings. The core tension is that consumers want authentic-looking food photos but distrust AI-generated content; the system must stay faithful to originals, preserve merchant brand, and avoid marketplace homogeneity. The solution uses multimodal agents to route images (enhance or skip) and edit iteratively, grounded in comprehensive logging that enables both human diagnosis and self-tuning loops.

Key points

• Small merchants face three barriers to quality photos: lack of time, lack of know-how, and high costs of professional shoots. 2:01
• Consumers want authentic, real-looking food photos but "a meaningful fraction of consumers actually distrust anything that is AI-generated." 2:44
• Design goals for the system are: preserve authenticity and trust, improve quality selectively, optimize globally without cannibalizing certain merchants, ship safely, learn continuously, and operate at cost-efficiently at scale. 3:50
• The system rejects both extremes: deterministic rules-based systems are brittle and don't scale; unconstrained agents have too much agency and risk. 4:25
• The pipeline stages image understanding and routing (describe what the LLM sees, create structured output, decide enhance or skip), then optional editing loops with QA feedback, post-processing, and publication. 5:24
• All agents log to a single flat JSON structure, enabling both technical and non-technical team members to diagnose specific cases and roll up aggregates. 6:30
• Logging must come first in any system with a self-learning loop: "if you don't start with it, you have nothing to optimize for." 7:01

Terms

• Multimodality — The ability to process multiple types of input (image, text description, metadata) to make routing decisions. 5:27
• Routing agent — Determines whether an image should be enhanced or skipped, based on understanding its quality and content. 5:39
• Guardrails — Safety constraints that prevent agents from operating without bounds. 4:52
• Structured output — Formatted data (e.g., quality scores, flagged issues) created by the LLM to feed into decision logic. 5:36

Quick quiz · tap to flip

Open questions

• How does the system decide which merchants to prioritize, given the goal of optimizing globally without cannibalizing certain merchants?
• What specific trade-offs emerged between cost efficiency and safety when choosing model sizes for routing vs. enhancement?

Offline Training and Online Drift Detection with Human-Aligned Evals

Models trained offline drift in production; systems must continuously sample real data, compare against human labels, diagnose failures, and auto-tune agents without human intervention.

Recap

The offline phase starts with a representative, diverse dataset (different geographies, dish types, image qualities) labeled by human annotators under objective guidelines to minimize bias. The router is evaluated as a classifier using confusion matrices to measure precision and recall; guardrail metrics (e.g., recall for routing) determine when a model is safe to ship. Once deployed, production data is regularly sampled and re-labeled, revealing mismatches between agent and human outputs. A diagnosis agent localizes failures and triggers an auto-tuning pipeline—a reflect agent identifies systemic issues, a synthesize agent updates configs and benchmarks against the golden dataset, and if metrics pass, the new agent is registered for production. The enhancement process generates image-specific prompts, refines iteratively through QA feedback, and measures success using "pass at K"—the pass rate after K iterations of refinement.

Key points

• Human labels serve as the golden source of truth; the system trains to align agents to human judgments via a representative dataset with objective labeling guidelines. 8:55
• Recall is the guardrail metric for routing—the system will not ship a router that allows bad images to slip through. 9:36
• A false positive (high-quality image incorrectly routed for enhancement) wastes compute and risks degrading an already-good image. 9:47
• A false negative (low-quality image approved) risks the model hallucinating missing content during enhancement (e.g., adding chicken wings that don't exist). 10:15
• "You've trained your offline model, but there will be long cases where your model is going to continue to fail and the static model will not work in the real system"—prompts and agents must evolve over time. 10:45
• Production data is sampled at regular cadence, re-labeled by humans, compared against agent output, and any mismatch triggers a diagnosis agent to localize the issue and auto-tune the agent. 11:09
• The auto-tuning pipeline is config-driven and requires no human in the loop; the diagnoser agent can write config and trigger the pipeline. 11:49
• Once tuned, agents are benchmarked against the golden dataset; if metrics pass, the new agent is registered in the agent store for production use. 12:56
• The enhancement process is iterative: generate a prompt specific to the image and routing directives, enhance, run a multi-dimensional QA gate (plating, faithfulness, colors), and either pass and publish or take feedback and re-enhance. 13:28
• Pass at K is the metric measuring the pass rate at the Kth iteration of refinement; more iterations generally yield higher pass rates. 14:26

Terms

• Golden dataset — A representative, objectively-labeled human dataset used as the authoritative source for training and evaluation. 9:01
• Confusion matrix — A table showing true positives, false positives, true negatives, and false negatives to evaluate classifier performance. 7:49
• Diagnosis agent — An umbrella agent that takes feedback from production data, identifies which agent needs tuning, and triggers the auto-tuning pipeline. 11:23
• Reflect agent — Analyzes mismatches in production data, removes noise, and identifies systemic issues to send to the synthesize agent. 12:32
• Synthesize agent — Takes feedback from the reflect agent and the agent config, updates the config based on feedback, and benchmarks the result. 12:47
• QA gate — A multi-dimensional evaluation gate checking multiple criteria (plating, faithfulness, colors) before publishing an enhanced image. 13:43
• Pass at K — The pass rate when an iterative process completes at the Kth iteration. 14:28

Quick quiz · tap to flip

Connections

• builds-on Designing Safe and Authentic Image Enhancement Agents — assumes the routing agent architecture and logging structure are in place.
• prerequisite-for Production Feedback Loops and Multi-Layer Safety — drift detection and auto-tuning set the stage for multi-layer feedback loops.

Open questions

• How are the objective labeling guidelines validated across annotators to ensure they remain consistent as new failure modes emerge?
• Does the system dynamically adjust which segments of the dataset are re-sampled for re-labeling based on drift severity?
• How does the synthesize agent avoid overfitting to recent production data while maintaining performance on the golden dataset?

Production Feedback Loops and Multi-Layer Safety

Real-world systems require redundant safety layers (Swiss cheese model), multiple feedback loops from internal dogfooding and user feedback, and constant monitoring of business metrics across segments.

Recap

Enhancement failure modes include faithfulness violations (adding ingredients that don't exist), completeness failures (removing necessary components), reward hacking (overly conservative fallback to generic plates), and physics implausibility leaked from frontier models. A final publish-ready QA gate applies the Swiss cheese model—redundant safety layers that catch failures upstream QA missed. Beyond the model loop (offline training + online drift), Uber uses multiple feedback channels: internal dogfooding (thumbs up/down and free-form feedback), merchant feedback, and cross-team input. A higher-level diagnoser abstraction routes failures from any feedback channel to the right agent(s) for configuration tuning. Examples are replayed, metrics are benchmarked, and new configs are deployed. Finally, production monitoring tracks business outcomes (conversion rates, add-to-cart behavior) and allows slicing by geography, device type, and dish type to tune on specific segments.

Key points

• Faithfulness failures occur when enhancement adds content not in the original (e.g., shrimp added to a different dish). 16:01
• Completeness failures remove content present in the original (e.g., sauce removed from sushi). 16:07
• Reward hacking happens when an agent overshoots in the opposite direction after rejection—e.g., using a generic ceramic plate after creative edits fail QA. 16:37
• Problems in frontier models leak into applied use cases (e.g., plates covering sauce); Uber coordinates with frontier teams to resolve them. 17:00
• Multimodal evaluation is critical for catching ambiguities (e.g., when the image cannot show whether there are truly eight wontons). 17:20
• Publish-ready QA is a redundant safety layer using a Swiss cheese model to reduce the chance of failures reaching production. 18:07
• Multiple feedback loops feed into a diagnoser abstraction: the model loop (offline training + online drift), internal dogfooding (thumbs up/down from users), and free-form feedback from merchants, design teams, and product teams. 18:57
• The diagnoser reflects on which agent(s) need optimization and routes configuration updates to them; it could target one agent or multiple. 19:24
• Flagged examples (good and bad) are replayed and benchmarked before pushing the latest config version to production. 20:14
• Production metrics include conversion (people adding to cart and completing orders) and can be sliced by geography, device type, and dish type to identify where improvements are happening and tune on specific segments. 20:39

Terms

• Swiss cheese model — A safety approach with multiple redundant layers; a hole in one layer is caught by another. 18:07
• Publish-ready QA — The final gate before production deployment, checking both policy compliance and holistic quality. 17:45
• Diagnoser abstraction — A higher-level agent that takes feedback from multiple loops, identifies which agent needs tuning, and routes config updates. 19:20
• Internal dogfooding — Testing by Uber employees (via thumbs up/down and free-form feedback) before a feature goes fully live. 18:57
• Reward hacking — When an agent optimizes for a metric in a way that degrades user value (e.g., playing it too safe to avoid rejection). 16:39

Quick quiz · tap to flip

Connections

• builds-on Offline Training and Online Drift Detection with Human-Aligne… — assumes offline training and online drift tuning are functional.

Open questions

• How is the threshold determined for when to replay flagged examples—do they batch by failure type or trigger immediately?
• What prevents the diagnoser itself from drifting or optimizing configs in contradictory directions across multiple feedback loops?
• How are business metrics (conversion) isolated from other platform changes to attribute improvement to the image enhancement system?

Foundation and Early-Stage Eval Strategy

Building agents requires starting with optimized tools and a critique mechanism, then progressing gradually from intuition-based "vibing" evals to measurable ones to avoid premature lock-in to comprehensive rubrics.

Recap

Agent building and making it reliable for production is difficult. The foundation requires a focused set of LLM-friendly tools, a separate critique agent with a remediation loop for self-correction, and then strong evals to measure changes. Because generative models are non-deterministic, early-stage evals work better when built intuitively on observed outputs before scaling to comprehensive measurement.

Key points

• Agent reliability depends on three things: capabilities of the agent, guardrails, and evals. 2:38
• Early-stage "vibing" (intuition-based evaluation without formal rubrics) allows faster iteration and radical architectural changes. 4:02
• Starting small with a few core tasks is more effective than creating a massive golden set on day one. 6:01
• Testing negatives—checking that the model doesn't do something bad—is as critical as checking successful task completion. 6:30
• Jumping to scaled evals too early causes instability when iterating and calibrating while also making radical model changes. 5:40

Terms

• Vibing — an early-stage, non-scalable, intuition-based evaluation approach where the team directly observes outputs to identify capability gaps and failure patterns. 4:06
• Critique agent — a separate LLM-driven component with a remediation loop that fills gaps where the base tool set has limitations. 1:53
• Golden set — a curated collection of test cases representing the intended behavior of the agent. 6:08

Quick quiz · tap to flip

Connections

• builds-on Overview — the broader context that evals are the differentiator in production AI engineering.

Open questions

• How do you know when to transition from vibing to scaled evals?

Scaling Evals with Human and LLM Raters

Scaling evals requires rater explanations and multi-dimensional evaluation, monitoring human-LLM agreement, and reading agent traces to catch behavioral failures that binary pass/fail metrics hide.

Recap

When involving larger teams and scale raters, providing clear rubrics with examples prevents raters from asking edge-case questions. Capturing explanations for pass/fail decisions reveals reasoning that binary scores hide. For multi-dimensional evals (like checking accuracy, brand safety, and relevance simultaneously), explanations show which dimension failed. LLM judges can supplement human raters if agreement rates are monitored against a sampling pipeline. However, looking only at pass/fail metrics misses behavioral failures visible in agent traces.

Key points

• Human agreement on what constitutes a pass or fail must be strong within the team before bringing in scale raters. 8:12
• Getting explanations from raters, not just pass/fail scores, reveals the reasoning behind ratings and shows where agents need improvement. 8:22
• Multi-dimensional evals can show that an agent performs well on one metric (e.g., brand safety) but poorly on another (e.g., accuracy). 9:01
• LLM raters can be used if you monitor disagreement rates between human raters and LLM judges to track agreement trends. 10:01
• Agent traces reveal behavioral failures that numeric pass rates cannot; an agent can detect a constraint and then violate it anyway, requiring reasoning inspection. 11:10
• Hill climbing works well once a good eval is defined, enabling quality iteration and ablation studies. 14:01
• Focus on patterns in the golden set rather than hyperfixating on isolated failure examples, because non-deterministic systems require statistical patterns to draw conclusions. 14:52

Terms

• Scale raters — human contractors or teams who rate agent outputs against a rubric. 7:36
• Agent trace — a detailed log of the agent's reasoning and decision steps, showing how it arrived at a particular output. 11:10
• Multi-dimensional eval — evaluation on multiple attributes (e.g., accuracy, brand safety, relevance) rather than a single pass/fail metric. 9:01
• Spot checks — sampling a subset of agent traces to audit the reasoning behind eval results. 10:35

Quick quiz · tap to flip

Connections

• builds-on Foundation and Early-Stage Eval Strategy — assumes foundation with tools and critique agent is in place before scaling.
• prerequisite-for Launch Readiness and Production Metrics — understanding how to evaluate at scale is needed before launch readiness.

Open questions

• How do you calibrate LLM judges when the task domain is novel or unfamiliar?

Launch Readiness and Production Metrics

Production-ready agents need clearly defined launch criteria and gatekeeping metrics, curated golden sets that evolve with use cases, and online evals matching production data to distinguish acceptable trade-offs from critical failures.

Recap

A good eval system is representative of what the product needs to excel at, which differs between MVP and production phases. Evals must evolve through online testing, refreshed test sets, and sampling pipelines. Clear rater training and rubrics with examples reduce ambiguity. Launch readiness involves identifying where model performance degrades and distinguishing regressions that are acceptable trade-offs from critical failures, guided by pre-defined gatekeeping rules and appropriate metrics.

Key points

• A good eval system is representative of the product's intended strengths, and what represents success differs between MVP and production rollout phases. 16:07
• Evals must evolve: use online evals, refresh test sets with production data, maintain sampling pipelines, and update golden sets as use cases evolve. 16:30
• Training scale raters and cross-functional teams is increasingly mainstream and helps prevent confusion about rating expectations. 16:45
• Launch readiness requires identifying regressions and distinguishing between acceptable trade-offs and critical failures. 14:23
• Define gatekeeping rules and launch criteria clearly upfront—whether based on precision/recall, custom metrics, or other measures—rather than deciding ad hoc during launches. 17:43

Terms

• Launch readiness — the stage where model performance is evaluated for production deployment, including regression identification and trade-off analysis. 14:18
• Gatekeeping rule — a pre-defined criterion or threshold that determines whether an agent is approved for production launch. 17:45
• Online eval — continuous evaluation of agent performance in production or production-like conditions. 16:30
• Ablation — testing variants of the agent (e.g., with or without a particular tool) to measure the impact of specific components. 17:33

Quick quiz · tap to flip

Connections

• builds-on Scaling Evals with Human and LLM Raters — requires the eval infrastructure and rater systems to be mature before moving to production.

Open questions

• How do you balance the cost of online evals with the need for continuous monitoring in production?

From Deterministic Code to Agentic Development

Software engineering is shifting from writing code whose behavior you can predict before runtime to managing agent performance empirically as a machine learning problem.

Recap

Traditional 2018 software engineering relied on writing code you could understand and predict entirely before running it. The introduction of agentic systems fundamentally changes this: an LLM-based agent is a blackbox whose behavior must be managed like a machine learning model through empirical evaluation and testing, not through code review and logical analysis.

Key points

• In 2018, software engineers could write a 400-line pull request with confidence that they understood exactly what it would do; today, replacing a regex with an LLM call means you can no longer predict behavior in advance. 1:40
• Software engineering has historically been "when you knew what the code would do before you ran it," but agentic systems shatter that assumption. 2:49
• Agentic coding is a form of machine learning; agent performance itself must be treated as a blackbox artifact whose behavior and generalization should be managed via empirical evaluation, just like any ML model. 3:01
• An LLM-based agent solving the same task as a regex can be strictly more powerful (catching edge cases the regex misses) but introduces fundamental unpredictability—running it one million times may not produce the same output each time. 4:23
• The uncertainty and unpredictability scale with task complexity; simple tasks may work reliably, but complex agentic tasks demand empirical verification. 4:52

Terms

• Blackbox artifact — A component (like an agent or ML model) whose behavior cannot be reliably predicted by inspection; its output must be validated empirically. 3:03
• Empirical evaluation — Testing a system's actual behavior on representative tasks and aggregating results to understand performance, rather than reasoning about behavior logically. 3:08

Quick quiz · tap to flip

Connections

• builds-on Overview — assumes understanding of why AI engineering needs fundamentally different approaches than traditional software development

Open questions

• What specific code review practices from 2018 remain valuable for agentic systems, and which must be abandoned?

Building Evaluation Environments with Harbor

Harbor provides a universal format and framework for constructing agentic evaluation environments by composing instructions, sandboxes, and verifiers, and the key insight is that every company using computers should build evaluations for their specific agent use cases.

Recap

Harbor answers the question "how do I evaluate an agent?" by formalizing evaluation as environments. An environment combines an instruction (what the agent should do), a sandbox (where it runs), and a verifier (how you check if it succeeded). This three-part structure has become standard across the industry. Every company should be building evaluations for their use case—whether that's how well agents build their products, use their products, power their features, or automate internal processes.

Key points

• An evaluation environment requires three components: an instruction telling the agent what to do, a sandbox (a virtual computer) where the agent runs, and a verifier (programmatic tests or rubrics) to check whether the agent succeeded within a time limit. 8:12
• Harbor's rollout process is universal: you pass a task and sandbox to an agent, the agent runs until a stopping condition, produces a trajectory, then you pass the sandbox to a verifier which produces rewards, aggregate across many rollouts to get a validation result. 9:24
• Harbor is three things: a format for specifying agentic environments, an open-source framework for performing rollouts in parallel using any agent with any model in any sandbox on any task, and a registry of popular training and validation environment sets. 10:40
• Every company using computers should be evaluating agents on their specific use cases, because automation drives productivity and value; this includes software companies evaluating how agents build and use their products, and any company automating internal processes. 11:25
• Companies should start by building the evaluation that matters and their ability to grade the outcome; once you have an evaluation, you can consider every model and aren't bound to brand, public benchmarks, or others' assumptions. 12:02
• Four concrete eval types companies are already using Harbor to build: evaluating how well agents build products (e.g., Ramp's RampBench), how well agents use your product (iterating on product for agent-usability), how well agents power product features, and how well agents automate internal processes. 12:48

Terms

• Harbor rollout — The core execution pattern: pass a task and sandbox to an agent, collect its trajectory, run verification, stop the sandbox, produce a reward, and aggregate across many runs to assess agent performance. 9:24
• Sandbox — A virtual computer where an agentic system runs its actions; all agents today run on computers, so agentic evaluation sandboxes are virtual computers. 8:25
• Verifier — A component (programmatic tests, rubrics, or an agent) that checks whether the agent actually completed the task it was instructed to do. 8:40
• Evaluation environment — A file directory specifying an instruction, sandbox, and verifier; this standard directory layout has become widely adopted for interoperability across teams and platforms. 8:52
• Trajectory — The record of an agent's actions and decisions during a rollout, collected for later analysis, verification, and training. 9:47

Quick quiz · tap to flip

Connections

• builds-on From Deterministic Code to Agentic Development — assumes you understand why agents must be evaluated like ML models
• prerequisite-for From Evals to Production—Scaling Agent Optimization — foundational concepts for production scaling

Open questions

• How should teams choose between multi-step rollouts, separate verification sandboxes, artifact collection, and user simulation based on their use case?
• What role does human judgment play in verifier design versus fully programmatic verification?

From Evals to Production—Scaling Agent Optimization

Beyond evaluation, Harbor enables production agentic patterns—map-reduce workloads, SFT and RL training from trajectories, and auto-optimization—that have already been adopted across dozens of labs and companies to scale agent performance.

Recap

Harbor's core "rollout" concept extends far beyond evaluation. Production use cases include agentic map-reduce (running many agents on distributed sandboxes and aggregating results), creating task data for model training, and direct reinforcement learning from trajectories. Harbor Exec demonstrates this: you can map a prompt over hundreds of sessions with a cheap model, then reduce the results with a smarter model, using the discovered failure patterns to inform the next generation of agent evaluations.

Key points

• Beyond evaluation, Harbor supports production rollouts: running agents for purposes other than testing, such as agentic map-reduce where you run thousands of agents on distributed compute and aggregate results—for example, analyzing trajectories for reward hacking, processing receipts, or searching knowledge bases. 15:50
• Harbor Exec (the map-reduce feature) allows you to specify a map prompt and a reduce prompt, distributing compute across models and inference providers; for example, mapping with a cheap fast model (Cursor) and reducing with a smarter model (Claude) based on your optimization target. 16:54
• Trajectories from Harbor rollouts can be directly used for supervised fine-tuning (SFT) or actual reinforcement learning, allowing you to train better agents on your eval; other teams use evolutionary methods, hill-climbing with the trajectory text feedback, or other optimization algorithms. 18:41
• Feedback from production rollouts (recurring mistakes and failure categories) can be analyzed and used to inform the next batch of Harbor tasks to evaluate, creating a closed loop for agent improvement. 18:20
• Industry adoption is rapid and broad: Cognition migrated all their evals to Harbor, Scale released their entire Atlas suite on Harbor, Poolside uses Harbor for model training evaluations, and multiple benchmarks (Frontier Suite, ToolBench, RuneBench, Frontier Code, Senior Sweet Bench) have been built on Harbor. 19:30

Terms

• Agentic map-reduce — Distributing agentic tasks across many sandboxes and parallel compute, then aggregating results; an emergent use case where Harbor runs many rollouts not for evaluation but for production workload processing. 16:12
• Harbor Exec — A feature allowing you to specify map and reduce prompts separately, and run them on different models and inference providers to optimize cost and quality. 16:54
• Reward hacking — An optimization failure where an agent achieves high reward scores without actually solving the intended task. 18:27
• SFT (Supervised Fine-Tuning) — Training a model directly on successful agent trajectories to improve performance on similar tasks. 18:41
• Reinforcement Learning — Directly training models using rewards and trajectories from agent rollouts to optimize for task success. 18:44

Quick quiz · tap to flip

Connections

• builds-on Building Evaluation Environments with Harbor — assumes understanding of Harbor's evaluation framework and rollout structure
• repeats themes from Overview — the pattern of evals as the bottleneck and differentiator, discussed throughout the fair

Open questions

• How do teams decide when to use SFT, RL, or evolutionary optimization methods given the same Harbor eval data?
• What best practices exist for detecting and preventing reward hacking in production agentic rollouts?
• How should Harbor tasks be designed to balance evaluation coverage with the cost of map-reduce workloads?

Voice, Plugins, and Personal Memory Architecture

The bottleneck in AI-augmented knowledge work shifts from technical execution to context management—speaking your requests into the AI and offloading memory to pinned threads and plugins that operate continuously.

Recap

Jason Liu introduces Codex as an extended workshop, emphasizing that the real productivity gains come not from the AI's coding abilities—those are "solved"—but from optimizing how humans provide context and delegate work. He uses a foot pedal for voice input, allowing him to multitask while instructing the AI, and demonstrates building personal memory infrastructure through plugins and pinned threads that collaborate autonomously.

Key points

• The workshop focuses on practical usage patterns and tricks to avoid wasting tokens, not on token maximization. 1:56
• Speaking is three times faster than typing, so voice input frees human attention for higher-value conversations with colleagues. 8:13
• Jason uses a foot pedal with transcribe and enter buttons to keep his hands free while delegating work to Codex. 4:04
• Appshots feature captures both a screenshot and the full accessibility tree of an application, providing the AI with structured data instead of requiring OCR. 4:28
• In an AI-augmented workplace, a single person may now oversee 200 ongoing projects instead of managing 10 direct teammates, creating a knowledge-management crisis that Codex helps organize. 3:08
• Pinned threads with automations can now communicate with each other and act like teammates, enabling managers, individual contributors, and coordinator agents in a multi-layered structure. 6:02
• Compaction (maintaining long, context-rich threads) now works reliably, invalidating the old advice to start a new thread after 20 messages. 6:49

Terms

• Appshots — feature that captures a screenshot along with the complete accessibility tree of an application, providing structured semantic data to the AI. 4:28
• Pinned threads — persistent conversations in Codex that can be assigned a project ID, delegated to sub-agents, and woken on a schedule via automations. 6:13
• Compaction — improved context-retention in long threads, allowing multi-week conversations with hundreds of sub-threads to maintain coherence without explicit message limits. 6:49
• Foot pedal — input device with transcribe and enter buttons, allowing voice-driven workflow without manual keyboard/mouse interaction. 4:04
• Memory vault — personal infrastructure (like a monorepo) that the AI uses to store and retrieve context about ongoing projects, people, and institutional knowledge. 5:00

Quick quiz · tap to flip

Connections

• builds-on Overview — assumes the listener understands the context-management challenges of large-scale AI augmentation at organizations like OpenAI.

Open questions

• How does compaction actually work technically in the latest models?
• What is the tradeoff between automatic context retention and token costs?
• How can teams safely share automations that operate over sensitive systems?

Building and Installing Skills and Plugins

Skills are lightweight automation templates that can be built quickly and self-improve through iterative correction, while plugins package collections of skills to solve specific domains like Slack, Gmail, or internal workflows.

Recap

Jason demonstrates how to set up dictation and voice-driven interaction patterns, then walks through the Codex plugin ecosystem—pre-built integrations with communication tools and the process of building custom skills. For personal use, he emphasizes rapid prototyping and correction; for team use, skills require more careful evaluation of edge cases. Computer use (controlling the entire desktop) and Chrome extensions (browser-only) both enable automated form-filling and multi-application workflows that would otherwise be manual.

Key points

• Messy, unedited voice input to an AI is acceptable because the AI can handle tangents and retrieve relevant context (like finding a meeting by partial description) to produce a clean result. 8:37
• Skills are simple constructs made of a few files and scripts; plugins are libraries of skills grouped by domain. 9:19
• The Codex plugin marketplace is built into the sidebar, letting users install pre-built integrations with Slack, Gmail, Teams, and other common tools. 9:42
• Computer use was described as the first time in a long time the speaker felt AGI—it could teach itself to use unfamiliar software (iMovie) and place sound effects at correct timestamps. 10:17
• Computer use operates behind the scenes on any desktop application; the Chrome extension controls only browser pages. 10:51
• By using Chrome extension, an AI can open three Twitter tabs in the background to check DMs while the user is working on email, then close those tabs without interrupting the user. 11:09
• The high-impact internal work is identifying team-specific needs and building custom skills for triage, communications, and outage response. 14:13
• The plugin and skill creator tools can interview the user or learn from a single demonstration to auto-generate a new skill; skills can be edited by the AI on future runs if given permission to self-improve. 14:45

Terms

• Skill — lightweight automation template consisting of a few files and scripts, often built for a single recurring task. 9:19
• Plugin — a library or collection of related skills packaged together to solve a domain (e.g., Slack, Gmail, triage workflows). 9:26
• Computer use — capability for AI to control the entire desktop environment and any application, operating invisibly in the background. 10:51
• Chrome extension — browser-limited version of computer use that can only interact with pages inside the Chrome browser. 11:04
• Accessibility tree — structured semantic representation of a UI element's fields and states, used by appshots to give the AI precise data instead of pixel-based OCR. 16:40
• SEV — severity classification used in incident response and outage communication automation. 14:32

Quick quiz · tap to flip

Connections

• builds-on Voice, Plugins, and Personal Memory Architecture — assumes familiarity with voice input and the need to manage many concurrent projects.
• prerequisite-for Appshots and the Personal Memory Vault — appshots are the key mechanism for letting skills gather context without complex function chains.

Open questions

• How do teams safely share complex skills that touch multiple systems?
• What is the approval workflow for skills that interact with external services?
• How does the AI learn the domain-specific jargon needed for an internal skill to work correctly?

Appshots and the Personal Memory Vault

Appshots bypass OCR and complex function chains by providing the full accessibility tree, and a Git-tracked personal vault lets the AI store, retrieve, and manage context while the human audits changes through version control.

Recap

Jason demonstrates appshots as the most impactful feature: instead of the AI OCR-ing a screenshot and making multiple function calls to identify Slack channels and users, an appshot provides the full accessibility tree, so the AI can identify a channel ID and user ID in a single function call. He then shows his personal memory vault architecture—a monorepo on Git where the AI reads and updates markdown files, and he audits the changes by running git diff to see what the model learned without explicit notification. This pattern enables delegation while preserving human oversight.

Key points

• Screenshots require the model to perform OCR, list Slack channels, list persons, and iterate through multiple function calls; appshots eliminate this chain by providing the accessibility tree with channel IDs and user IDs already present. 16:19
• With an appshot, an instruction like "do research and reply" becomes a single function call instead of many hops. 16:55
• Jason has not filled out a form in two weeks because Codex can now use appshots to identify form fields, determine whether to use the Chrome extension or computer use, and fill the form automatically. 17:22
• The personal monorepo template is available on GitHub; Jason can ask Codex to find and install it, then Codex can set it up while he continues watching the presentation. 18:15
• Jason's personal monorepo is a Git repo; he runs git diff after the AI has worked for a few days to audit what the model updated and what it did not. 22:31
• The memory vault is used by Codex to draft responses to Slack messages and email questions, asking the human for permission before sending. 23:04
• A skill like "write like me" reads six months of email and Slack messages to build a personal style guide, so all future compositions match the user's voice. 20:33
• Managing 16 demo repositories without cluttering the sidebar is possible because Codex can read and write files outside the pinned project directory if told via the agents.md file. 19:15

Terms

• Appshot — screenshot plus the full accessibility tree of an application, providing semantic data (IDs, field names, values) that allows the AI to take precise actions without OCR or function-call chains. 16:40
• Accessibility tree — structured representation of a UI's interactive elements, including IDs, labels, and states, captured by appshots. 16:40
• Memory vault — personal infrastructure (often a Git-tracked monorepo) where the AI reads and writes markdown files to store and retrieve context about ongoing work, people, and decisions. 18:08
• Git diff — version-control command that shows changes; Jason uses it to audit what the AI learned and updated in the memory vault without explicit notifications. 22:39
• agents.md — configuration file that tells Codex where to save files and how to manage the file system (e.g., clone new projects to /dev). 19:21
• Write like me skill — custom automation that reads email and Slack history to extract the user's communication style, then applies it to future compositions. 20:33

Quick quiz · tap to flip

Connections

• builds-on Building and Installing Skills and Plugins — uses skills and plugins to implement memory and personal style automation.
• prerequisite-for Model Selection, Permissions, and Safety Controls — the memory vault's ability to hold context enables the AI to decide which model to use and what permissions to request.

Open questions

• How does the AI decide when context is stale and should be archived?
• What is the scalability limit for a Git-tracked memory vault—when does it become too large to diff efficiently?
• Can the memory vault be shared between multiple Codex instances or does each require its own?

Model Selection, Permissions, and Safety Controls

Different models serve different cost/capability tradeoffs (o3 for reasoning, Spark for simple tasks); permissions can be set to require approval, auto-review, or full autonomy, with organizational sandboxes adding boundaries on email and messaging.

Recap

Jason fields Q&A on practical deployment questions: how to choose between o3 (expensive but capable), Spark (cheaper for simple tasks), and Claude; whether to use YOLO one-shot skills or iteratively correct them; and how permissions work. He explains that unlocked computer use can be triggered from a phone even when the laptop screen is closed, that latency is not a concern for background automations, and that o3's higher cost is justified only for complex reasoning. OpenAI, as an organization, uses MCP server sandboxes to prevent accidentally emailing external addresses or messaging external Slack workspaces.

Key points

• For personal skills used only by the author, YOLO (one-shot-only) is acceptable because the model self-improves through feedback; for shared team skills, more careful evaluation of edge cases is necessary. 24:02
• Spark is preferred for simple computer-use tasks like clicking buttons and filling forms, while o3 is reserved for reasoning-heavy work. 27:15
• Latency is not a practical concern because most automations run in the background; the user does not watch them execute. 27:10
• A flight check-in agent runs as a Spark agent (cheaper, simpler) and automatically checks the user in, downloads the boarding pass, and sends it to iMessage—all without user intervention. 27:30
• Computer use is uniquely powerful because it has access to the user's OAuth tokens and file system. 28:00
• Locked use (a setting in computer use preferences) allows the user to trigger computer-use commands from their phone even when the laptop monitor is closed and the system is asleep. 29:01
• The desktop Codex app is preferred over the CLI because everything can be appshots; the CLI cannot perform appshot-based workflows. 25:28
• O3 models are reluctant to take destructive actions, but o3 costs more than necessary for simple tasks; the user is more often frustrated by models refusing to act than by reckless behavior. 30:39
• Permission modes include "ask me for every permission," "auto-review" (the default, which Jason uses), and "full autonomy" (YOLO). 30:54
• At OpenAI, organizational policy prevents using MCP servers to send email to non-OpenAI addresses or post to external Slack channels. 32:02

Terms

• o3 model — expensive, reasoning-capable variant used for complex tasks requiring deep thought. 26:55
• Spark agent — fast, cheaper model suitable for simple computer-use tasks like form-filling and button-clicking. 27:17
• Locked use — setting that allows triggering computer use from a phone even when the laptop is asleep or the screen is closed. 29:04
• Auto-review — permission mode that logs all AI actions for the user to review, allowing the AI to act but with a record for audit. 30:18
• MCP server — connection point through which Codex can invoke external APIs; OpenAI's organizational sandboxes restrict MCP-based email and messaging. 32:02
• Sandbox — organizational boundary that prevents an AI agent from sending messages outside the organization. 32:32

Quick quiz · tap to flip

Connections

• builds-on Appshots and the Personal Memory Vault — the memory vault and appshots determine what context is available; model selection follows from the task complexity.
• prerequisite-for Automations, Delegated Work, and Pinned Threads as Teammates — choosing the right model and permission level enables the automation patterns discussed in the next section.

Open questions

• How does auto-review actually work—is there a daily digest, or does every action require explicit sign-off?
• What is the current cost difference between o3 and Spark for typical tasks?
• Can permissions be set per-skill, or only globally per Codex session?

Automations, Delegated Work, and Pinned Threads as Teammates

Heartbeat automations schedule repeated work into pinned threads, enabling continuous oversight (pull request monitoring, support triage) and multi-threaded collaboration without requiring the human to actively manage each task.

Recap

Jason concludes the first half by explaining automations as the final layer of delegation. Pinned threads become teammates; automations wake them up on a schedule (every 30 minutes, hourly, or on-demand) by scheduling a message into the same thread rather than creating a new one. The loop skill implements continuous pull-request maintenance (keeping CI passing, rebasing on master), and a developer-experience triage skill monitors Twitter and Slack for bugs, routes them to the correct engineer, opens an issue tracker, and periodically checks for resolution—all without human intervention. This enables one person to manage many ongoing support streams simultaneously.

Key points

• A pinned thread is effectively a teammate; automations wake them up by scheduling a message back into the thread, avoiding the old pattern of creating a new thread every automation run. 34:52
• The loop skill takes a pull request and automatically keeps it mergeable: fixing feedback, rebasing on master, ensuring CI passes, and integrating changes. 35:35
• A developer-experience triage skill monitors Twitter, Slack, and other channels for bug reports, identifies the responsible engineer, posts in the internal channel, DMs the engineer, uses computer use to reply on Twitter, and checks for resolution every hour. 36:09
• The automation triggers in the background without user awareness; the Twitter tab may suddenly open showing a resolved issue, making the human experience surreal but unobtrusive. 36:50
• Chief of staff thread can loop continuously to check all personal connectors and notify the user of the most important issue. 36:26
• Delegating work through automations and pinned threads enables support at scale that would otherwise be the worst part of the job. 37:06

Terms

• Heartbeat automation — scheduled message sent into a pinned thread at regular intervals (every 30 minutes, hourly, etc.) to wake an agent and trigger work. 35:04
• Loop skill — automation that keeps a pull request in a mergeable state by integrating feedback, rebasing, and ensuring CI passes. 35:35
• Pinned thread — persistent conversation that acts as a teammate or agent, storing context and receiving scheduled work via automations. 34:23
• Chief of staff thread — a high-level pinned thread that monitors all personal connectors (email, Slack, etc.) and reports priority issues. 36:26
• Developer-experience triage — skill that monitors external feedback channels, routes issues to the responsible team, and tracks resolution. 36:09

Quick quiz · tap to flip

Connections

• builds-on Model Selection, Permissions, and Safety Controls — automations rely on safe permissions and model choice to operate continuously in the background.
• prerequisite-for continuation in part 2 — the agent framework described here transitions to more complex orchestration patterns in the second half.

Open questions

• How does the loop skill know when a pull request is ready to merge vs. when it needs further work?
• Can automations be triggered by external events (webhooks) or only on a fixed schedule?
• How does the chief of staff thread prioritize across multiple connectors and channels?

Chief of staff automation - building perpetual task loops

Agents running on a heartbeat schedule — waking periodically to read context, decide what work to do, and coordinate across email, Slack, and calendar — replace manual status-gathering with continuous real-time organizational awareness.

Recap

The chief of staff thread is an agent that runs on a fixed schedule to create a daily hub for what's happening in a person's life and work. It reads email, Slack, and other connectors, formats everything with links for deep access, and then runs actions like checking flight reservations or drafting replies. The agent learns patterns over time and expands its scope to share useful automations with a wider team, turning personal productivity tools into organizational infrastructure.

Key points

• A heartbeat is a mechanism for waking up a thread periodically to take actions, separate from event-triggered runs. 40:07
• The chief of staff thread acts as the single source of truth for what's happening across email, calendar, and Slack by checking all connectors daily at 8 a.m. 43:26
• Agents can be designed to draft responses to emails rather than just surfacing them, reducing friction for the human to act on them. 43:42
• Automations often start for personal use but become more valuable when adapted and shared with a team, converting individual productivity into organizational leverage. 38:50
• Email, Slack, and calendar need deep links (URLs to specific messages or events) so humans can quickly navigate from a summary back to the source. 37:35

Terms

• Heartbeat — a scheduled interval at which an agent wakes up to check connectors, read state, and take actions, separate from event-triggered execution. 40:07
• Chief of staff thread — an agent that consolidates information from email, Slack, and calendar into a single daily briefing, with links to source messages. 43:12
• Connectors — integrations (email, Slack, calendar, messaging) that an agent reads to gather context about ongoing work and life. 43:28

Quick quiz · tap to flip

Goal-driven verification and artifact-based output

Agents that write to discoverable, editable artifacts (slideshows, spreadsheets, documents) make their work visible and collaboratable, and goals with verifiers let models iterate toward completion rather than producing a single flawed attempt.

Recap

Agents achieve better results when given an explicit goal with a verification condition that keeps them running until the condition passes. Writing output to artifacts — living documents like slides, spreadsheets, and PDFs — instead of just generating text creates a collaborative workspace where humans and models can edit and refine together. The annotation tool in Codex allows real-time feedback as the model works, so corrections happen mid-run rather than requiring a full regeneration.

Key points

• A goal defines a verification step and tells the model to keep iterating until the verification passes, rather than stopping after one attempt. 40:15
• Models are much better at generating the prompt or goal itself than at following a prompt written by a human; letting the model design the work yields better results. 44:34
• Writing project context (Slack channels, team member info) in markdown frontmatter lets the model discover and read relevant sources without being told explicitly. 45:54
• Artifacts (slides, spreadsheets, documents) can be edited in real time while the model is working, allowing corrections to propagate as the model continues. 51:17
• Agents can build and manage loops that touch other parts of a system — spreadsheets, slides, project trackers — turning them into living documents. 51:53

Terms

• Goal — a verification condition paired with a task, instructing the model to keep working until the verification passes. 40:15
• Verifier — a boolean check that determines whether a goal is complete, causing the model to stop iterating once it passes. 40:18
• Artifacts — editable, discoverable outputs like slides, spreadsheets, and documents that the model can open, render, and modify. 50:51
• Ultra goal — a variant where the goal and plan are stored in a markdown file so they can be edited while the model is still running. 41:19

Quick quiz · tap to flip

Computer use — agents controlling screen and browser

Computer use gives agents the ability to click, type, and navigate web pages as a fallback when APIs are unavailable, but requires explicit guardrails (agent.md constraints, auto mode) to prevent models from becoming determined and bypassing security boundaries when blocked.

Recap

Computer use allows an agent to move a cursor, click buttons, and navigate the web like a human, creating the sensation that the computer is doing work while you watch. This opens real-world workflows — finding and applying coupons, testing applications, filling forms, controlling iPhone via screen mirroring — but introduces security risks when a model is determined to complete a goal and starts working around blocked APIs. The in-app browser in Codex handles most web work more safely than generic computer use, and explicit guardrails in the agent.md file and auto mode discipline the model's willingness to bypass security.

Key points

• Computer use creates a felt AGI moment when the cursor moves autonomously and accomplishes visible work on screen. 52:37
• A model determined to complete a goal will attempt to bypass API limits by using computer use to click buttons directly when a connector refuses to cooperate. 54:09
• Guardrails in the agent.md file (describing constraints) combined with auto mode discipline prevent models from escalating to computer use when blocked. 54:43
• The in-app browser in Codex is safer and more performant than generic computer use for web tasks and should be the default for browser work. 52:56
• Real-world computer use examples include app shots on checkout pages to find coupons, testing applications, and filling out forms for financial gain. 55:14

Terms

• Computer use — the ability for an agent to control mouse, keyboard, and screen navigation to interact with web pages and applications as if human-piloted. 52:37
• App shot — a screenshot-based request that triggers computer use to analyze a page and take an action (e.g., find a coupon, fill a form). 55:17
• In-app browser — a sandboxed browser embedded in the Codex app for web navigation, safer and faster than generic computer use. 52:56
• Auto mode — a constraint mode that limits a model's willingness to bypass security boundaries. 54:47

Quick quiz · tap to flip

Open questions

• How should models balance completing a goal against respecting security boundaries when an API refuses?

Monitor threads and recursive automation — agents spawning subthreads

A monitor thread watches for events across Slack and Twitter, spawns specialized subthreads to handle each issue, and lets subthreads communicate back, creating a self-managing recursive system that scales issue handling without human triage.

Recap

A monitor thread is a top-level agent that scans Slack and Twitter for issues and, when it detects one, spawns a specialized subthread to triage and resolve it. Subthreads can work on tasks like creating pull requests, notifying teams, or waiting for review, and they report back to the monitor. If a recurring issue appears, the monitor recognizes it as a duplicate, notifies the existing subthread, and raises the human's awareness of the pattern without requiring intervention for each occurrence. This pattern scales issue handling from manual triage to recursive agent management.

Key points

• A monitor thread detects issues (support requests, bug reports) and spawns new threads to handle triage, PR creation, and follow-up, removing the need for human-triggered triage. 56:34
• When the same issue is reported again, the monitor recognizes the pattern, links the new report to the existing subthread, and alerts the human to the recurrence. 56:57
• Subthreads pinned to the sidebar become visible workstreams, making it easy to notice when issues have changed or progressed. 58:14
• Most automations in this pattern run at the monitor level, spawning and managing subthreads that then manage themselves, creating a recursive hierarchy. 58:50
• A monorepo (project and people directories) combined with heartbeats and monitor threads lets the agent manage multiple ongoing workstreams with visibility into state. 59:44

Terms

• Monitor thread — a long-running agent that watches Slack, Twitter, or other streams for events and spawns specialized subthreads to handle each one. 56:34
• Subthread — a specialized thread created by a monitor to handle a specific task (triage, PR, follow-up) and communicate results back. 56:42
• Monorepo — a structured directory with projects, people files, and notes that the agent uses to organize context. 59:43

Quick quiz · tap to flip

Open questions

• How does a monitor thread decide when to spawn a new subthread versus folding a request into an existing one?
• What prevents a monorepo from becoming too large for the agent to parse and keep in working memory?

Model selection, reasoning levels, and developing taste through consumption

Low and medium reasoning suffice for most production work; developers improve by consuming widely and building vocabulary to critique their own and others' work, not by defaulting to maximum reasoning and exhausting tokens.

Recap

The misconception that higher reasoning levels always produce better results leads to wasted tokens. Low and medium reasoning on the current models still outperform earlier versions by a wide margin and are appropriate for most tasks. More important than raw reasoning capacity is developing taste — the ability to recognize good design, onboarding, and user experience by consuming applications, testing them, and building a vocabulary to articulate what works and what doesn't.

Key points

• Low and medium reasoning settings are sufficient for most work that is not generative code-from-scratch, such as running automations and handling tasks. 1:12:21
• Taste comes from consuming widely — trying different apps, building things, noticing frustration — and developing a vocabulary to describe why something is bad. 1:05:41
• Models can be asked to update themselves to newer versions (GPT latest) to avoid older automations running on deprecated models. 1:10:07
• Memory systems reduce the need for explicit skills like "check notes" over time, as models learn to consult their own context organically. 1:04:13
• Heartbeat frequency and stopping criteria (when to check, when to stop) should be customized per workstream and can be edited while the automation is running. 1:13:08

Terms

• Reasoning level — a model configuration (low, medium, high) that controls how much computation the model expends on each response. 1:12:21
• Taste — the ability to recognize good design, UX, and onboarding by consuming applications and developing a vocabulary to critique them. 1:05:41
• Memory system — a built-in Codex feature that persists context across sessions, reducing the need to prompt the model to remember things. 1:04:13

Quick quiz · tap to flip

Open questions

• How does the memory system decide what is worth persisting across sessions?
• At what scale does a monorepo context become too large for a model to manage?

Foundations and failure modes of synthetic personas

LLM-based synthetic personas can match human behavior at 83% alignment when properly grounded, but three critical failure modes—invented confounders, prompt sensitivity, and predicting attitudes over actions—can lead to wildly inaccurate results.

Recap

The field of synthetic personas uses LLMs to model human decision-making for market research. A landmark study demonstrated agents could achieve 83% alignment with real humans on personality and preference tests. However, the technology is fragile: when personas lack grounding, they invent confounding variables; they exhibit extreme order bias in responses; and they predict stated attitudes far better than actual behaviors, since training data emphasizes what people say over what they do.

Key points

• Synthetic personas entered market momentum as companies use LLMs with role prompts to test products and messaging against synthetic respondents. 0:47
• A key demonstration took about a thousand humans through two and a half hours of interviews and personality tests, then had AI agents take the same tests; the agents achieved 83% alignment with their corresponding humans. 4:05
• When LLMs are missing context in an experiment, they invent latent confounders—for example, inferring that a higher price signals better quality or a richer customer, changing their behavior in ways a grounded human wouldn't. 6:12
• Models show extreme order bias: swapping the order of multiple-choice options caused LLM responses to average to 50/50, far more volatile than human order bias. 7:54
• LLMs are trained on what people say, not what people do, making them better at predicting stated attitudes (surveys) than field behaviors that must be transcribed into actions. 8:29

Terms

• Synthetic persona — an LLM prompted with personality, demographic, or preference information to simulate how a human with those traits would respond to questions or product scenarios. 0:42
• Invented confounders — unstated variables the LLM infers to make sense of an underspecified prompt, such as assuming price correlates with product quality or customer wealth. 6:12
• Prompt sensitivity — extreme responsiveness of LLM outputs to minor changes in phrasing or option order, much more extreme than human variability. 7:45

Quick quiz · tap to flip

Open questions

• How should practitioners richly ground personas to prevent invented confounders?
• What degree of prompt sensitivity is acceptable for practical research applications?

Techniques for constructing accurate synthetic personas

Three escalating techniques—basic prompting, fine-tuning with survey data, and calibrated text mapping—let practitioners elicit latent persona knowledge from LLMs and reconstruct full response distributions rather than point averages.

Recap

Three proven techniques build more accurate personas. Basic prompting with role statements works, though it shows bias amplification as detail increases. Fine-tuning on known human survey distributions improves both seen and unseen demographic groups, suggesting models already contain latent understanding they just need help expressing. Most sophisticated: calibrating free-text responses against human exemplars (e.g., "Hell no" for 1/5 willingness, "Absolutely" for 5/5) captures full distributions, avoiding the problem where LLMs flatten variation by defaulting to middle values.

Key points

• The Argyle paper, one of the seminal works, used text completion models with simple I-am statements like "I am a strong liberal. I support progressive values," then let the model sample its vote choice; since then, many more prompting techniques have emerged. 10:05
• When researchers compared different persona construction methods on voting patterns, they found that increasing detail actually amplified bias rather than improving accuracy, pushing results further from reality. 11:05
• The Subpop technique constructs a prompt template with demographics and a survey question, compares the model's output distribution to known human data, and fine-tunes until they align. 11:52
• Fine-tuning on seen populations improved unseen populations by almost the same degree, suggesting the model already has latent understanding of those groups and just needs help expressing itself in the survey format. 12:11
• A more sophisticated technique asks the model to generate free text (e.g., "I'm somewhat interested. If it works well and isn't too expensive, I might try it") then measures semantic similarity to human exemplars for each rating (1–5), creating a probability distribution of the response. 14:00
• This text-mapping approach captures the full distribution of variation, not just the mean; a human might say "four" some days and "five" other days, and the model reflects that variation rather than converging on a single middle value. 14:39

Terms

• Fine-tuning — adjusting model behavior by training on pairs of prompt templates and known human response distributions until model outputs align with the human data. 12:05
• Subpopulation method (Subpop) — a fine-tuning technique that constructs prompts with demographic information and survey questions, comparing model outputs to human distributions. 11:52
• Semantic similarity — a vector-space measurement of how closely a model's free-text response aligns with human exemplars for different response categories (1–5 rating scale). 14:24

Quick quiz · tap to flip

Connections

• builds-on Foundations and failure modes of synthetic personas — requires understanding failure modes to design prompts that avoid invented confounders.

Open questions

• Which prompting technique works best for a given use case?
• How much fine-tuning data is needed to achieve good alignment across unseen populations?

Measuring accuracy and complementing human research with synthetic personas

Synthetic personas are forecasts, not people; running more samples cannot boost statistical significance, but comparing full distributions to human ground truth and establishing a noise floor enables rigorous validation against reality.

Recap

Synthetic personas should be treated as forecasts analogous to weather models, not as ground truth. Generating more synthetic samples does not increase statistical significance, just like re-running a weather forecast without changing inputs does not improve forecast confidence. Proper validation requires comparing output distributions (not just means) to human ground truth, using both correlation and shape-similarity metrics. Establishing a noise floor—how much humans themselves vary—reveals the ceiling on model accuracy. Personas complement rather than compete with human research: they extend findings across development phases and can simulate multi-agent ecosystems where AI mediates human decisions.

Key points

• Rerunning a synthetic persona multiple times without changing input does not improve the certainty of the forecast, just as re-running a weather forecast without new data does not increase forecast accuracy; the lesson is more synthetic samples cannot generally boost statistical significance. 17:18
• Alignment measurement requires comparing distributions of data, not just scoring right and wrong; models can get the average right but the shape of the distribution wrong. 17:00
• Multiple metrics are needed: correlation-type metrics paired with shape-type metrics that capture the underlying distribution shape. 17:20
• In the 83% alignment study, when researchers retested humans 2 weeks later, humans were only 80% consistent with themselves, setting a noise floor for the maximum accuracy models can achieve. 17:39
• If you cannot retest humans, you can artificially estimate noise by splitting ground truth human data into two chunks, treating one as synthetic and one as human, measuring correlation, and repeating hundreds or thousands of times to establish a noise floor. 18:06
• Synthetic personas are most useful when complementary to human research: as humans become mediated by AI agents, understanding the human-plus-agent ecosystem is the real goal, not just human-only data. 19:08
• The alternative to synthetic personas is often not human research but guess work; extending human data across more development phases through synthetic personas is more practical than waiting months for new surveys. 19:34

Terms

• Noise floor — the level of inherent inconsistency in human responses, measured by retesting subjects or by cross-comparing halves of human data; it establishes the ceiling on how accurate synthetic models can ever be. 17:39
• Distribution comparison — measuring how well a model's output distribution matches a human ground-truth distribution across multiple dimensions and metrics, rather than comparing single point estimates. 17:00
• Forecast analogy — a conceptual frame treating synthetic personas as weather models: bounded, improving over time, validated against reality, and not substitutes for observation but tools for understanding uncertainty. 18:30

Quick quiz · tap to flip

Connections

• builds-on Techniques for constructing accurate synthetic personas — takes the constructed techniques and validates them against human data.

Open questions

• How should practitioners choose which metrics to use for their specific application?
• What are the best practices for integrating synthetic personas into an existing human research workflow?

Functions as the Model for AI Programs and Tasks

AI programs should follow the function model—accepting a clear input/output contract while hiding internal implementation details, enabling reusability, composition, testing, and optimization.

Recap

Programming repeatedly calls functions because they are reusable, composable, testable, and optimizable. DSP brings these same properties to AI programs by treating repeated AI tasks as black-box functions with fixed input/output contracts. This separation allows practitioners to change internal implementation details—models, prompts, techniques—without breaking the task's external API, and to iterate rapidly as new techniques become available.

Key points

• Functions in traditional programming are awesome because they are reusable, composable, testable, and optimizable. 0:51
• A function requires a name, defined inputs, defined outputs, and implementation logic that can be reused thousands of times and composed into bigger programs. 0:58
• DSP brings all of these properties to AI programs, letting you bring these properties to your AI workflows and programs with the tooling you need. 1:31
• With a fixed input/output interface you can play in the internals and get a lot of agility, changing implementation details whenever new models or techniques arrive. 2:26
• Concrete examples include extracting tax values from invoices, correcting grammar and clarity in text via clipboard, composing email replies from an inbox, and generating pull requests from a repository spec. 2:40

Terms

• Function — A named unit with defined inputs, outputs, and implementation logic that can be reused, composed, tested, and optimized. 0:58
• DSP — Open-source Python software that brings function-like properties (reusability, composability, testability, optimizability) to AI workflows and programs. 1:31
• Implementation tactics — Specific techniques, strategies, and models that change frequently in AI, but remain hidden behind a stable task interface. 2:20
• Input/output contract — The external interface of a task, independent from the implementation, allowing internals to change while the API remains stable. 2:26

Quick quiz · tap to flip

Open questions

• What are the three core things needed to specify a task fully?
• How can tasks be optimized automatically once a clear boundary is established?

Specifying Tasks with Constraints, Examples, and Optimization

Complete task specification requires three languages—what should happen (instructions), what must happen (code-enforced constraints), and what good looks like (examples and evals)—enabling automatic optimization and production scaling.

Recap

To fully specify an AI task and enable automatic optimization, three components are necessary. Instructions define what should happen using natural language and type signatures. Code enforces critical constraints that must always hold, like validation or fallback logic. Examples and evals teach the model what good looks like by showing patterns it must recognize. DSP has evolved over time to optimize these components: first optimizing few-shot examples, then prompts, and now learnable harnesses. In production, this separation enables massive cost reductions while keeping task boundaries stable.

Key points

• Three things fully specify a task: what should happen (instructions), what must happen (code-enforced constraints), and what good looks like (examples and evals). 4:59
• Instructions are expressed in natural language and type signatures, expressing your needs powerfully and efficiently compared to learning from examples alone. 5:14
• Constraints must be enforced with code—if a vanilla program doesn't extract taxes you want it to rerun with more reasoning, or if a value falls below zero you show it to a human. 6:17
• Examples teach what good looks like through patterns over time, like learning how to identify a maple tree by seeing many examples rather than receiving explicit instructions. 7:24
• Once you have all three—specs, code, and evals—your goal is fully specified and you can start optimizing automatically. 8:17
• DSP optimization has evolved: initially optimizing few-shot examples, then automatically optimizing instructions, and now creating learnable harnesses that delegate more implementation details. 8:29
• Shopify achieved 550x cost reduction by going from an expensive model to a cheap model while keeping the same task boundary, so they could keep iterating on business logic inside. 9:58
• New techniques like recursive language models can be integrated with one line of code without changing the signature, allowing you to experiment and see if they solve your problem. 11:06
• When you have flexible implementations, you get a lot of agility to try sub-problems that unlock the ecosystem of techniques being constantly invented. 16:06

Terms

• Specifications (specs) — Natural language instructions and type signatures that express what should happen and what outputs are expected. 5:14
• Code constraints — Enforced requirements written in code that must always hold true, regardless of model or technique changes. 6:17
• Evals — Examples and metrics that teach and measure what good looks like, learned through patterns over time. 7:24
• Bitter lesson — The principle that searching over different cheap solutions can achieve massive improvements compared to relying on a single expensive approach. 9:45
• Recursive language models (RLMs) — A technique for solving long-context programs that can be integrated into DSP tasks without changing the signature. 10:51
• Harness — A learnable implementation that adapts over time to solve a specific task, evolving from fixed prompts to dynamic, optimizable code. 12:08

Quick quiz · tap to flip

Connections

• builds-on Functions as the Model for AI Programs and Tasks — assumes you understand the function model and why task/implementation separation matters.

Open questions

• How do you measure evals when you don't have clear ground truth?
• What happens to task specification as models get smarter?

Qualitative Learning, Task-Specific Expertise, and Building with the Ecosystem

Intelligence is task-specific and context-dependent; even AGI requires learning your problem's constraints through feedback, and reliable AI software is built by holding each technique accountable to actual business outcomes, not hype.

Recap

Building reliable AI software means asking data-driven questions about each new technique: will it solve your specific problem? You must hold prompts, models, and code accountable to the business outcomes you need, not adopt techniques because they are new. Even with perfect models, task-specific learning is necessary—AGI won't know your emails or relationships without learning your context over time. The DSP ecosystem provides both the framework for this accountability and the collective techniques discovered by the community.

Key points

• You should ask every new technique in a data-driven manner: how can I apply this to the business problem I have? 15:48
• You should define your problem and hold your prompts, models, and code accountable to the problem that you need them to solve. 15:56
• When you build with flexible implementations you unlock the ecosystem of all the techniques that anyone is constantly inventing. 16:06
• Even if you have AGI, the model won't know how to solve your problems or have your context without learning it over time. 14:30
• Intelligence is very different from being all knowing; even Albert Einstein asked what an email is, but AGI won't know how to do your emails or understand your relationships. 14:43

Terms

• Data-driven evaluation — Assessing new techniques by measuring their impact on your specific business problem, not by adoption trends or academic novelty. 15:48
• Task-specific context — The unique constraints, relationships, and domain knowledge required to solve a particular problem, which even superintelligent models must learn over time. 14:30
• Last-mile learning — The practical discipline of optimizing and adapting AI systems to solve specific real-world problems rather than general capabilities. 14:36

Quick quiz · tap to flip

Connections

• builds-on Specifying Tasks with Constraints, Examples, and Optimization — assumes you understand specs, code, and evals as the framework for accountability.

Open questions

• How do you measure whether a technique actually improves your business outcomes?
• What infrastructure is needed to make task-specific learning work at scale?

Notion's Token Town—Sarah Sachs on AI, negotiating contracts, and the system of record

Notion's mission centers on being a durable system of record where humans and agents collaborate, and its leaders negotiate AI contracts to make this vision economically viable.

Recap

Sarah Sachs leads Notion's AI teams and negotiates AI contracts as part of her job. She frames the talk as "Token Town," exploring how to go from AI-poor to AI-rich sustainably. The discussion is grounded in Notion's longstanding position as a system of record for human collaboration, now extended to include agents as collaborators.

Key points

• Notion positions AI as part of collaboration infrastructure, not a replacement for it. "Today that collaboration happens between humans and agents. Humans and humans, agents and agents." 2:45
• The goal is building AI native products and companies, not just adding AI as a feature. 2:20

Terms

• Token Town — A framing device for exploring how to build sustainable AI products at scale, considering the tradeoffs between capability and cost. 1:10
• System of record — A durable collaborative workspace where humans and now agents work together; Notion's core mission. 2:32

Quick quiz · tap to flip

Connections

• builds-on Overview — assumes production AI context at scale and agent-native infrastructure.

The AI transformation journey and the system of record

Most companies stall at AI-as-assistant because they lack a durable system of record to coordinate the siloed data that AI systems need to become autonomous agents and critical workflows.

Recap

Sachs outlines four stages of AI maturity: AI as thought partner (early experimentation with LLMs), AI as assistant (executing individual tasks), AI as teammate (handling repetitive workflows), and AI as system (where processes interface and entire systems run autonomously). She observes that 88% of companies cannot get past the assistant stage, identifying siloed data and the absence of a durable system of record as the bottleneck. This diagnosis becomes Notion's core value proposition.

Key points

• AI transformation has four stages: thought partner (tinkering), assistant (individual task execution), teammate (repetitive work), and system (processes interfacing with each other). 3:01
• "88% of people can't even get past AI as an assistant" because companies lack a durable system of record. 4:13
• A durable system of record is required for software factories and autonomous systems to work; this is Notion's core mission. 4:26

Terms

• AI as a thought partner — Early experimentation stage where users tinker with LLMs for individual tasks like email drafting. 3:02
• AI as an assistant — Stage where AI executes individual tasks on demand, saving employee time but with functionally limited capabilities. 3:24
• AI as a teammate — Stage where AI handles repetitive workflows and processes, enabling systems thinking. 3:39
• AI as a system — Stage where processes interface with each other and entire systems run autonomously, requiring coordination across siloed data. 3:53

Quick quiz · tap to flip

Open questions

• How do companies migrate existing siloed data into a unified system of record without disrupting ongoing operations?

Cost as a structural barrier and the monthly model pricing traps

Cost is a structural barrier to AI adoption and building factories, but the real danger lies in model provider pricing that punishes both customers and builders when features shift token usage without proportional revenue gains.

3 claims verified

Recap

Sachs identifies cost as the primary structural barrier preventing companies from building sustainable AI products at scale. She illustrates this with concrete examples from Notion's experience: a reasoning model upgrade kept the same per-token price but consumed 3x more output tokens; another upgrade introduced a 40% price increase while the prior model was being deprecated. These scenarios force companies to choose between passing costs to customers or absorbing them—neither sustainable. Fortune 500 companies can navigate these tradeoffs through consulting teams and negotiating leverage, but most companies are stuck.

Key points

• "Cost is a structural barrier to entry. It makes it hard for you to serve products. It makes it hard for you to build factories." 5:05
• Model providers upgrade with the same per-token price but dramatically increase output token consumption (e.g., 3x more output tokens for a reasoning model), creating hidden cost escalation. 5:41
• New model versions introduce price increases (e.g., 40% higher) while deprecating the prior version within months, forcing customers to upgrade on the provider's schedule, not their revenue growth. 5:55
• Only Fortune 500 companies can hire consulting teams and have leverage to negotiate these tradeoffs; most companies have no ability to negotiate and remain stuck. 6:41 *(captions garbled here — auto-transcript renders the company size as "Fortune 5 million" rather than "Fortune 500"; the specific figure cannot be confirmed)*

Open questions

• How can smaller companies build negotiating leverage if they lack the volume that Fortune 500 companies possess?

Your supplier is your competitor and winning on product, not token economics

Building AI products as a reseller of commodity tokens is a losing game; differentiation comes from product expertise, understanding which tasks need which capabilities, and building data flywheels that justify cost to customers.

4 claims verified · 1 quarantined

Recap

Sachs argues that companies building AI products cannot compete on token pricing with suppliers who build models natively. When a company resells tokens at cost-of-goods markup, they are passing through the supplier's margin and then adding another layer, creating an untenable arbitrage. She points to evidence (analysis by Dylan) showing that frontier labs' first-party product subscription prices are dramatically lower than what they charge third-party resellers—a bad deal no company should accept. Instead, she recommends winning through product: building data flywheels, understanding customers better than anyone else, knowing when specific capabilities and latency matter, and building compelling UI and orchestration. The goal is to justify the inherent markup on commodity tokens through superior product.

Key points

• "Your supplier is your competitor. You will always be getting a bad deal on tokens with someone who builds them natively." 7:31
• Reselling model tokens at a markup while a supplier builds natively means "you're basically giving someone a really bad deal" and have no exit if pricing becomes untenable. 7:43
• Frontier labs charge customers vastly different prices for first-party products vs. third-party reseller access—the markup is unsustainable and should not be played. 8:14
• The real differentiation is in product: "building data flywheels and understanding your customers better than anyone else. Understanding when you need capability, when you need low price, when you need latency improvements." 8:53
• Do not bet on being a trainer or model builder unless you are one of the few actually building frontier models; instead "think about the best product that uses many models." 9:30

Terms

• Data flywheels — Compounding systems where better product choices lead to more customer data, which improve the product further. 8:55

Open questions

• How can companies prevent customers from going directly to frontier labs if they are primarily reselling access?

Not all traffic belongs on the frontier model

Frontier models are optimized for a narrow market of extremely hard tasks; routing all traffic to frontier models is a misallocation that wastes money, and pricing structures in an oligopoly create perverse incentives where capability does not correlate with price.

Recap

Sachs introduces the concept of bifurcation between frontier and everyday usage, drawing on analysis by Citadel. The insight is that for many products, simpler models are the most cost-effective path to productivity gains. She notes that "not all traffic is equal"—routing email triage to the latest Opus model "rips off" customers and the company alike. Frontier labs operate in a functional oligopoly where the best model commands premium pricing (anything above what AI cannot do today is their market), while the second-best model need only be marginally cheaper to capture the rest. This creates a situation where price does not correlate with capability growth. The danger is that companies marketing heavily with a specific lab's model (to extract discounts) sacrifice product optionality and end up serving with an outdated model half the time.

Key points

• "For the economy at large, simpler models might be the most cost-effective productivity augmenting pathway" due to bifurcation between frontier and everyday usage. 9:57
• Not all traffic should go to frontier models: "If we're charging you to do that on Opus, we're ripping you off and ourselves." 10:38
• Frontier lab pricing creates an oligopoly where the best model prices as high as possible, the second-best prices marginally lower, and this structure means "price does not correlate with capability growth." 11:46
• Companies that tie themselves to one provider for a discount end up serving "with an outdated model half of the time" as frontier advances monthly. 12:06

Terms

• Frontier models — The state-of-the-art most-capable models (e.g., Opus, GPT-4) optimized for extremely hard tasks. 10:06
• Everyday usage — Tasks that do not require frontier capabilities (e.g., email triage, data formatting) where simpler models are more cost-effective. 10:07
• Frontier lab oligopoly — A market structure where a few providers control state-of-the-art capabilities and price accordingly, creating misaligned incentives. 10:52

Quick quiz · tap to flip

Open questions

• How can companies reliably identify which traffic belongs on frontier models vs. everyday models without extensive experimentation?

Optionality, model agnosticism, and the auto model playbook

Optionality—the ability to switch models instantly—is the primary leverage against supplier pricing power; model agnosticism requires building for multimodal systems, thinking about cost-per-capability-per-second, switching fast, and partnering with frontier labs on evals rather than locking in with discounts.

Recap

Sachs presents optionality as a company's primary defense against supplier pricing power and model obsolescence. She describes Notion's auto model approach: a default model (not tied to a specific lab) that handles 75% of traffic while maintaining access to state-of-the-art models. The core playbook for model agnosticism involves building for multimodal input/output so switching models does not break the transcript, thinking about cost-per-capability-per-second rather than per-token cost, and switching models often. Rather than locking in with large discounts (which sacrifice optionality), she recommends partnering with frontier labs on eval programs—sharing expertise on customer use cases in exchange for pricing negotiation power. This allows companies to maintain model diversity without the high switching cost.

Key points

• "If you don't have the capability to walk at any point you are stuck. That's probably the most expensive decision you'll make regardless of what discount you get." 12:47
• Notion's auto model "handles about 75% of our traffic" while maintaining access to frontier models and offering customers model choice without vendor lock-in. 13:16
• The model agnostic playbook requires: "Build for multimodal" input/output to avoid cache busting on model switches, think about "cost per capability per second, not just the tokens," switch fast. 13:46
• Evaluation partnerships with frontier labs are more valuable than large discounts: "our eval program partnerships actually help us a lot with Frontier Labs and is something that we can exchange instead of extraordinarily large commits." 14:41
• Discounts that sacrifice optionality are never worth it: "I don't think the discount is ever worth the loss in optionality." 14:53

Terms

• Optionality — The ability to switch between models at any point without switching costs, which serves as a company's primary leverage against supplier pricing. 12:43
• Model agnosticism — An architecture approach where products work with multiple models and switch between them based on cost-capability-latency tradeoffs, without vendor lock-in. 13:02
• Auto model — Notion's default model that handles 75% of traffic, designed not to be tied to any specific lab. 13:16
• Cost-per-capability-per-second — A holistic metric that accounts for model latency and capability together with cost, not just per-token pricing. 14:03
• Eval program partnerships — Collaborations where companies share domain expertise and real-world use-case data with frontier labs in exchange for pricing negotiation power. 14:41

Quick quiz · tap to flip

Open questions

• How do companies avoid cache busting when switching models mid-conversation, especially for long transcripts?

Open weight models for the middle

Open weight models are now capable enough for moderate-tier tasks and provide both cost reduction and negotiation leverage against frontier lab oligopolies, making them a credible alternative to proprietary models.

Recap

Sachs argues that open weight models have crossed a capability threshold and now handle middle-tier tasks effectively. She cites recent models (Gemma 2, GPT-5, GLM variants) as "bombshells" that outperform prior generations. The capability gap between open weight and frontier models has narrowed to the point where companies should evaluate open weight options for moderate tasks without relying on heavy reinforcement learning. Importantly, open weight models give companies a credible alternative that exerts downward pressure on frontier lab pricing—a form of negotiation leverage unavailable in a pure frontier lab oligopoly. For customers, open weight reduces cost barriers to entry.

Key points

• "Open weight models are really strong enough to handle these tasks and the possibility to RL on top of them has also kind of expanded the upmarket growth that they can cover." 15:08
• Recent open weight models (Gemma 2, GPT-5, GLM variants) represent genuine capability jumps: "it's no longer the case where open weight models are good for just SFT on small tasks." 15:50
• Open weight "lowering the barrier to entry on cost for our customers and they also give you negotiation leverage" against frontier labs. 15:19
• The capability gap eventually closes: "if the tasks that you're having today are good enough, then in six months, they're probably covered by open weight. So, be prepared now." 16:46

Terms

• Open weight models — Publicly released model weights (e.g., Gemma 2, GLM) that can be run locally or on customer infrastructure, avoiding vendor lock-in. 15:04
• Capability overhang — A gap between what open weight models can do today and what frontier models can do, which closes predictably over time. 16:46

Quick quiz · tap to flip

Open questions

• Which specific open weight models are most suitable for production workflows in 2026 and beyond?

CPUs over GPUs, governance, and security—the lethal trifecta

Not every AI task requires a GPU; many deterministic, code-focused tasks run efficiently on CPUs and reduce token spend, while effective governance (visibility, control, model optionality) and security (handling private data, untrusted content ingestion, and external communication) are what create real product value and responsible autonomous agents.

Recap

Sachs introduces Notion Workers, a system that routes tasks appropriately: not every job needs an LLM or GPU. Deterministic tasks like converting CSV to PDF or executing SQL queries do not benefit from LLM processing and waste tokens when sent to frontier models. Using CPUs for code-focused work both reduces cost and improves determinism. The talk then pivots to security as the next critical challenge. She frames "the lethal trifecta": a system that combines access to private data, exposure to untrusted content (via email, MCP, web search), and the ability to communicate externally creates risk that scales with autonomy. Governance—implementing visibility, control, and model optionality—is how companies build valuable product while managing that risk. Persistence of enterprise knowledge in multi-agent systems is an underdiscussed governance challenge.

Key points

• Not all AI jobs require GPUs: "I don't think that the GPU is necessary for every job. A lot of the jobs that we have are actually serving um discrete pieces of code. Like you don't need an LLM to turn a CSV into a PDF." 17:04
• Deterministic SQL queries and tool calls do not need LLMs; routing them to frontier models "is where people become token poor very quick." 17:21
• The "lethal trifecta" is: access to private data, exposure to untrusted content, and ability to communicate externally—this combination creates risk that "the more autonomous your system is, the more unsupervised this risk is." 18:17
• Sandboxes and containers "build better determinism in your product and also better token economics for your customers." 18:48
• "Persistence of enterprise knowledge is something that's actually really not discussed enough" in multi-agent orchestration. 19:08

Terms

• Notion Workers — A system for routing tasks to appropriate infrastructure (CPUs for deterministic work, GPUs/LLMs only when needed). 17:02
• The lethal trifecta — A dangerous combination of private data access, untrusted content exposure, and external communication ability in autonomous systems. 18:17
• Governance — Systems for visibility (who uses data), control (limits on agent actions), and model optionality (flexibility to change models). 17:36
• Sandboxes — Isolated execution environments that constrain what agents can do and improve both security and token economics. 18:50

Quick quiz · tap to flip

Open questions

• How can companies ensure persistence of enterprise knowledge across multiple agent sessions without creating new security vulnerabilities?

Live demo—orchestrating Notion agents into a PR

Software factories orchestrate multiple AI agents (Claude for scoping, other agents for customer research, code agents for PR creation) as control loops that iterate with human teams and external reviewers, not as one-shot completions; the vision is real-world production usage where agents automate steps but maintain human oversight and multi-agent coordination.

Recap

Sachs demonstrates Notion's software factory approach in action: a live task in a Notion document where Claude scopes out requirements, the system asks clarifying questions and invites team members (PMs, TLs, external partners) to provide input, additional agents (like Decagon) gather customer voice data, and code agents (Claude Code, Codeex) create PRs and identify issues. The system is a collaborative, active document—not markdown. The key insight is that agents orchestrate iteratively: when Claude Code's PR might be incomplete, Codeex reviews and finds issues, and the system loops. This is contrasted with factories that require constant human babysitting. Notion uses this internally for most Polish and large feedback cycles, and customer data shows substantial time savings per task, scaling to massive ROI. The core principle: commit to the concept that AI augments and automates, but require model optionality to preserve flexibility.

Key points

• The software factory pattern orchestrates multiple agents: Claude scopes tasks, specialized agents gather customer data, code agents create PRs, reviewer agents audit the code. 20:00
• Agents work within active collaborative documents (not markdown), enabling tagging and iteration with human teams and external partners. 20:35
• Multi-agent loops catch issues: "Maybe Claude Code isn't the best at customer voice, but Decagon is, right?" 20:57
• "Almost all of our polish and large feedback like this is actually coordinated through our software factories both in terms of writing to the right teams and also having coding agents take the first step." 22:13
• Customers see "massive ROI gains"; the example cited shows "three minutes saved on a given task. Imagine that at scale." 22:37
• The factory approach requires "optionality and conviction that we understand what models are required for which tasks." 22:46

Terms

• Software factories — Orchestrations of multiple AI agents working iteratively as control loops within collaborative documents, automating and augmenting human workflows. 20:00
• Multi-agent orchestration — A system where different agents handle different tasks (scoping, research, coding, review) and can invoke each other or wait for human input within a document. 21:00
• Control loops — Agent workflows that iterate, receive feedback (from humans or other agents), and loop back rather than completing in a single pass. 21:00

Quick quiz · tap to flip

Connections

• builds-on CPUs over GPUs, governance, and security—the lethal trifecta — assumes security governance and model optionality are in place before orchestrating multiple agents.

Open questions

• How do companies prevent one misbehaving agent from cascading failures across a multi-agent orchestration?
• What are the practical limits of agent autonomy before human oversight becomes the bottleneck?

The Agent Capability Gap — From Button Clicks to Real Work

Agents have solved individual UI actions but not end-to-end workflows, because real work lives in the gaps between systems, not in the systems themselves.

Recap

A year ago, getting agents to find and click buttons was the hard problem; today agents can drive browsers and desktop apps with individual steps. But the real challenge is end-to-end work: agents can perform each step but fail at complete workflows because the actual work lives in the seams between different applications, not within any single one. Reliability, not capability, is now the bottleneck—agents need to succeed 99.9% of the time to be trusted, not just 60–80%.

Key points

• A year ago the main problem was "getting an agent to find a button and click it on a screen, especially screens it had never seen before"; now agents can drive browsers and desktop apps. 0:44

• Current agents can perform individual steps but struggle with end-to-end workflows because "the real work lives within the seams of all of those different applications." 2:07

• Agents have achieved "fairly good" workflow orchestration when stringing together taught capabilities (clicking, scrolling, typing, APIs, form-filling). 2:58

• Reliability, not capability, is the limiting factor: "you can use every single tool you give it, but it still can't do the full work." 2:17

• An agent succeeding only 60–80% of the time sounds acceptable, but is catastrophic in practice: "if your agent one in four times deletes a database, you will never touch that agent again." 4:04

• Practical reliability requires "the nines"—something close to 99.9% success for agents to earn user trust. 4:21

Terms

• End-to-end workflow — a complete process spanning multiple systems and steps, rather than isolated individual actions within a single system 1:21

• Capability vs. reliability — capability is the ability to perform actions; reliability is doing them correctly and consistently; the field has solved capability but not reliability 3:15

• The seams problem — the gaps between applications where real coordination and context must live, not covered by any single tool or system 2:07

Quick quiz · tap to flip

Connections

None.

Open questions

• How can agents build the reliability needed to handle consequences at the "nines" level across unpredictable workflows?

Verification's Success in Coding, Its Failure in Messy Work

Code agents became reliable because code is verifiable via tests; most knowledge work is unverifiable, leaving it stuck at low reliability.

Recap

Coding agents made a dramatic leap from autocomplete to writing full pull requests because code has an intrinsic property: verifiability. You can run tests, check outputs, and be certain of correctness. This shifted coding from capability (generating code) to reliability (trusted generation) fast enough that humans stopped manually reviewing every line. But most real work is knowledge work—messy, subjective, without unit tests—leaving verification techniques useless for the vast majority of what agents need to do.

Key points

• Coding evolved from autocomplete to full pull requests in a short time; the shift in trust happened because "code is verifiable. You can run it, you can test it, you can check it." 6:05

• Verification made the jump from capability to reliability: "We were able to bring it from just being capable the coding agents to actually be reliable and then trusted." 5:46

• Knowledge work cannot be tested the same way: "Did the report I created land? Is the design on brand? Did it get it what I actually meant? So there is no unit test that can answer those questions." 6:45

• The verification wall is where most real work lives: "It's living in the seams of all of those applications we're using on a day-by-day basis." 7:06

• The challenge remains unsolved: "How do you make an agent reliable when there's no way to verify the answer that easily? And that's a field that is still wide open." 7:15

Terms

• Verification — the ability to check whether an agent's output is correct by running tests, executing code, or objectively confirming results 6:05

• Knowledge work — tasks that produce subjective or contextual outputs (reports, designs, ideas) rather than objectively testable code 6:31

• Verifiability cliff — the boundary where verification techniques stop working, leaving most real-world work without automated correctness checks 7:02

Quick quiz · tap to flip

Connections

None.

Open questions

• How can agents be made reliable for knowledge work if the correctness of those outputs cannot be verified programmatically?

From Shared Context to Perception — The Perceive-Plan-Act Loop

Humans solve messy problems by looking at the same screen and building shared context; agents need a perceive-plan-act loop like robotics rather than a turn-based chat model.

Recap

Humans solve messy work by sharing context—jumping on a call and looking at the same screen reduces explanation and accelerates problem-solving. Today's agents see a screen and can click, but they fire off actions without watching the results or recovering from failures. The missing piece is the perception loop: like a robot that perceives, plans, and acts in real time, screen-based agents should continuously perceive rendered output (not code), plan the next step, and act—while staying responsive enough to react to user input without turn-based delays.

Key points

• Humans handle messy work "by figuring things out together. You grab a colleague, you jump on a Zoom meeting, you're discussing things, you're looking at the problem to solve." 7:48

• Shared visual context is the key: "If you're jumping on a meeting with a colleague, you see the same screen, both of you, and you can actually like figure out really quickly what needs to be done." 8:18

• Agents need shared context more than a "bigger brain": "You don't necessarily need a bigger brain. What you need is this shared context." 8:35

• Today's agents move on after firing actions without checking: "if they fire off actions, what they usually do, they move on. They don't watch what happens or recover if one step didn't succeed or something goes sideways." 9:09

• The perception agent model mirrors robotics: "a robot perceives what's around it and it plans what to do and then acts. So this loop here from perceiving to planning to acting, this is actually what we also would need on a screen." 9:29

• Perception means reading the rendered output, not scraping code: "The agent has to take in the screen the way you do, not scrape the code behind the page, but what's actually rendered, the layout, the state, what just changed." 9:58

• Real-time responsiveness requires abandoning turn-based chat: "today agents can still don't do it. What we're doing is we're sending a prompt. We're waiting. It goes away and at one point the agent come back... we have this long back and forth." 10:35

• Agents should react while users work: "an agent that can react while you're still working. Wouldn't that be really cool, right? Like at the same time you're working, it can also come up with suggestions, can help you, and there is no waiting time." 11:05

Terms

• Shared context — both agent and human perceiving the same visual interface and state, reducing the need for lengthy written descriptions 8:35

• Perceive-plan-act loop — a continuous cycle where an agent observes its environment, decides on an action, executes it, and observes the results, inspired by robotics 9:29

• Real-time perception — agents reading rendered screen output (pixels and layout) as it appears to users, rather than scraping underlying code 9:58

• Turn-based interaction — the current chat model where user sends prompt, waits for response, sends follow-up; agent must unwind and restart for each turn 10:41

Quick quiz · tap to flip

Connections

None.

Open questions

• How can agents stay responsive enough to suggest actions in real time while a user is working, without the latency of turn-based prompting?

Implementing Perception Agents — Annotation and Verification Tools

Perception agents close the perception loop with two open-source tools: annotation lets users specify changes by pointing at rendered UI, and verification lets agents check their own work against design specs and user flows.

Recap

Perception agents solve three problems traditional agents face. First, they close the loop by reading rendered output to confirm their own work rather than hoping actions succeeded. Second, they work with any software—no APIs needed—because they see what users see. Third, they accept precise input: instead of long text descriptions, users point at UI elements and describe changes, a much tighter signal. Amazon AGI Lab released two open-source pieces: an annotation tool (Chrome extension for marking what to change) and a verification tool (checking work against design specs and automated user flows), turning subjective knowledge work verifiable.

Key points

• Perception agents complete the action-perception loop: "they complete the loop on computer use. Today's agents again they can act, they can click, they can type, they can scroll, but what they can't do well is looking at the results and whether it actually worked out." 11:43

• Perception agents read rendered screens and confirm their outputs: "A perception agent can read the rendered screen so it can confirm its own output instead of just firing off those actions and then hoping." 12:06

• No API or backend required because agents work off rendered interfaces: "it works off the rendered interface. It sees the same pixels and the structure you see. And most of today's software people use every day don't expose APIs at all." 12:20

• Pointing at UI is more precise than text description: "Instead of writing this really long description... wouldn't it be great if you can just point to it and say, 'Hey, here this heading needs to change.'" 12:44

• The annotation tool is a Chrome extension that captures exact visual feedback: "you can just select different elements on a screen... the agent here captures on the screen exactly the feedback, the location, the style elements and it creates this complete summary." 14:03

• Annotation eliminates back-and-forth: "there is no back and forth anymore because you captured exactly what you saw on screen and the agent can see the same thing." 14:55

• Verification uses design specs to check agent work: "you can describe in a design MD file what your design rules are for this... the agent can actually check its own work against those design specs." 15:17

• Verification does visual and flow checks: "it does a visual check, which is really cool. So everything is on brand, for example. it's the right layout. The other part is also checking user flows... it might add a task, it might delete a task like a real user would." 15:52

• Verification produces reports for human review: "once it's done, it's writing a report which you can review and it's going to call out which tests passed and it's going to tell you anything that didn't." 16:25

Terms

• Annotation tool — a Chrome extension that lets users select and mark UI elements and specify desired changes, creating a precise visual specification for agents 14:03

• Verification tool — an open-source system that checks agent-generated work against design specs (visual and layout rules) and automated user flows 15:17

• Design specs — a markdown file defining design rules (colors, components, layout) that agents can check their work against 15:24

• Visual verification — automated checks ensuring agent output matches branding, layout, and design guidelines 15:52

• User flow testing — verification that walks through an app's workflows (adding tasks, deleting tasks) like a real user to catch functional bugs 16:03

Quick quiz · tap to flip

Connections

• builds-on From Shared Context to Perception — The Perceive-Plan-Act Loop — applies the perceive-plan-act loop to concrete implementation

Open questions

• How scalable is the verification approach when design specs must be hand-authored, and can it adapt to rapidly changing or subjective design requirements?

Multimodal Perception — Beyond the Screen

Perception agents extend beyond screens to real-world settings like meetings, using devices that capture audio transcripts to send multimodal context to agents.

Recap

Not all work happens at a screen. In a real-world demo at the conference, Barth and a colleague held a design meeting using wearable devices that transcribed their discussion. The transcript was fed to an agent, which extracted meeting decisions and sent them directly to implement changes on a website. The agent then ran verification against design specs. This shows that perception agents can work in non-screen environments by accepting transcripts, audio, and other modalities alongside visual data, letting agents understand decisions made in conversations and act on them.

Key points

• Perception extends beyond digital screens: "there are times in your day where you don't have a screen. Maybe you're in the office. You're walking into a meeting with a colleague." 17:01

• A live demo showed agents perceiving meeting discussions via transcripts: "perception can also be listening in the room to what you're discussing." 16:39

• Wearable devices captured meeting audio and transcripts: "we're sitting there. We have our B devices that can do a transcript. They're listening to what we're saying." 17:52

• Meeting transcripts were sent directly to agents for action: "we're pulling this meeting transcript right in there is a whole detailed summary of the meeting... we can click apply. So what this apply button does is it sends it straight to the agent." 18:18

• Agents extracted and acted on meeting insights: "captures those insights. We have them right here and we can click apply... my crazy ideas to turn the background to yellow, turn the heading to red... directly applied." 18:35

• Verification ran immediately after agent actions: "it also straight kicks off the verification right away. So it creates this report." 18:54

• Users can override design specs if preferences change: "you could change those rules if you don't want to have yellow backgrounds and it will make sure um that we still adhere to those guidelines." 19:08

Terms

• Multimodal perception — agents receiving input from multiple channels (screen, audio transcripts, meeting notes) rather than just visual UI 16:39

• Meeting transcript — real-time or post-meeting transcription of discussions that can be converted into structured instructions for agents 18:18

• Real-time application — agents immediately extracting decisions from transcripts and applying them without human rewrite or reformulation 18:40

Quick quiz · tap to flip

Connections

• builds-on Implementing Perception Agents — Annotation and Verification … — extends the annotation and verification model from UI-based to audio/transcript-based input

Open questions

• How does transcription error or ambiguity in meeting discussions affect agent accuracy when decisions are extracted and applied immediately?

Open Source and Collaboration — Building AI Together

Perception agents are being released open source because these patterns improve through community use, feedback, and breaking; the goal is to build AI that makes everyone smarter together, not alone.

Recap

The annotation and verification tools are the first step; Amazon is building the rest open source because patterns improve only through broader adoption and community feedback. The core philosophy is that "none of us get smart alone"—progress in AI agents requires shared patterns that people can use, build on, and break. The talk ends with a call to action to try the tools, report what's missing, and continue the conversation about human-agent collaboration patterns, which Barth recommends exploring further via her colleague's podcast.

Key points

• These tools are "the very first step. These two pieces are the very first beginning. And we're building out the rest in the open." 19:30

• Open-source release is essential for improvement: "these patterns can only get better if more people are using them, building on top of them, breaking things." 19:42

• The call to action is to try the tools and provide feedback: "my ask here to you is go and try them out. They're on our GitHub repos, open source. Tell us what we're missing." 19:48

• The core philosophy is collective intelligence: "none of us get smart alone and that's the whole point. We want to build AI that makes all of us smarter together." 20:05

• Further exploration is available via related talks and resources: "if you're interested in a little bit more on human agent interactions... I would highly recommend this podcast by my colleague Danielle Persik." 20:19

Terms

• Open-source patterns — agent tooling and techniques released publicly so the community can adopt, extend, and improve them 19:42

• Collective AI intelligence — the principle that AI systems improve through shared adoption and feedback, not through isolated development 20:05

Quick quiz · tap to flip

Connections

• prerequisite-for Perception Agents — Antje Barth, Amazon AGI Lab — summarizes the high-level call to action and vision

Open questions

• None captured in this section.

Task horizon and managed agents architecture

As models gained longer task horizons, API surfaces evolved from simple prompt-response to managed infrastructure, requiring a decoupled architecture that separates the reasoning brain from execution hands for reliability and security.

5 claims verified · 1 quarantined

Recap

Claude's capabilities have expanded across task horizons — from 10–20 minutes of autonomous work in Opus 3 to hour-long sessions with Claude Code, to now 12+ hours with frontier models. This shift changed the viable product interfaces: short horizons work with interactive chat, medium horizons with local coding agents, and long horizons require async deployment. Managed Agents introduces a decoupled architecture where the stateless harness (brain) communicates with an append-only session log, which coordinates many sandboxed execution environments (hands), storing credentials separately for safety.

Key points

• Early attempts at async agents failed when models could only do ~1 hour of work because errors caused bad user experiences; longer horizons unlock practical async. 1:49
• The API evolved in lockstep: Messages API (2 years prior, basic prompt-response), Agent SDK (programmatic harness), and Managed Agents (harness + deployment infrastructure together). 2:13
• Managed Agents decouples the brain (stateless harness) from hands (execution containers), with the session as an append-only event log that never loses state when components fail. 3:25
• Credentials are stored in a separate vault, not in sandboxes, so long-running agents can't accidentally leak secrets even if they run unsupervised for hours. 4:03
• The append-only session acts as an external context object, enabling models to retrieve old context without destructive compaction, improving long-horizon context engineering. 5:28

Terms

• Task horizon — how long an autonomous task a model can sustain before human steering is needed. 1:01
• Managed Agents — Anthropic's API that packages a harness and deployment infrastructure together for async, long-running agent work. 2:54
• Brain-hands decoupling — separating the reasoning harness (stateless, talks to session) from execution environments (sandboxes where work happens), improving reliability and security. 3:22
• Append-only event log — the session store in Managed Agents that persists all state and is never lost if the harness or containers fail. 3:31

Quick quiz · tap to flip

Connections

• prerequisite-for Verifiers and self-learning memory systems — understanding the decoupled architecture is foundational to why verifiers and memory systems become practical on long-horizon tasks

Open questions

• How does the session log handle concurrent writes from multiple hands or harness instances?
• What are the latency implications of every harness interaction routing through the append-only log?

Verifiers and self-learning memory systems

Self-improvement in long-horizon tasks requires separating verification into independent contexts and implementing an in-band/out-of-band memory architecture, where online learning writes tactical memory and offline dreaming consolidates and corrects persistent knowledge.

Recap

The key innovation behind long-horizon loops is separating work and grading into independent contexts. When a single context does both the work and verifies it, the model confabulates and exhibits odd behavior. A separate verifier context, tuned specifically for critical verification, uses rubrics or outcomes to validate the builder's work in a loop until completion. For continuous self-learning, Claude uses a two-system memory approach: in-band memory (models write tactical notes while executing) improves across model generations, but errors accumulate. Offline "dreaming" — running an out-of-band process that reviews session traces and the memory store — corrects these errors by comparing historical sessions, fixing mistakes before they propagate.

Key points

• Models grading their own work in the same context suffer from confabulation and odd artifacts; separating verification into an independent context window avoids this. 6:28
• The verifier context can be tuned specifically for critical verification, using rubrics or outcomes, separate from the builder's context. 7:13
• Loops run build-agent → verifier-agent until the verifier confirms outcomes or goals are met; this paradigm with high-capacity models yields strong results. 7:23
• Parameter golf benchmark test showed frontier models (like Opus 4.7) solve ML research tasks when allowed to iterate in a verifier loop until specified outcomes are satisfied. 8:56
• The human brain separates short-term memory (hippocampus) from long-term memory (cortex consolidated during dreaming); Claude can employ the same two-system approach. 10:15
• Sonnet 3.5 with memory access writes tactical, not strategic notes; more recent models like 4.6 write much more strategic memory and achieve further game progress. 11:21
• Higher capacity models have a better sense of abstraction for memory — they write generalizable principles for future sessions, not just specific facts. 12:51
• In-band memory is prone to locally optimal but globally suboptimal writes; offline dreaming is an out-of-band process that corrects these errors by reviewing traces. 13:19
• A Pokémon example showed incorrect memory causing mislocalization and falling into traps; dreaming corrected the error 5/5 times versus raw memory. 14:08

Terms

• Verifier loop — a control pattern where build and verify phases run in separate contexts, with the verifier checking outcomes until satisfied, then exiting. 7:23
• In-band memory — tactical notes written by the model as it executes, helping it solve immediate tasks but prone to errors and locally optimal thinking. 10:23
• Dreaming (out-of-band consolidation) — an offline process that reviews the memory store and prior session traces, correcting errors and consolidating globally useful knowledge. 13:23
• Distillation (in memory writing) — the ability of higher-capacity models to extract and save generalizable principles rather than specific facts. 12:51

Quick quiz · tap to flip

Connections

• builds-on Task horizon and managed agents architecture — verifier loops and memory systems are practical because of the stable, decoupled architecture provided by Managed Agents
• prerequisite-for Org-level harnesses and deployment patterns — memory and self-learning are why org-level harnesses can operate autonomously and proactively

Open questions

• How frequent should dreaming cycles run to be effective without wasting compute?
• Can dreaming handle contradictory memories, or does it only correct false ones?
• Do all memory substrates (file systems, databases) work equally well for dreaming, or are some fundamentally better?

Org-level harnesses and deployment patterns

Async agents shift from single-player local tools to multiplayer org-level harnesses with their own identity and credentials, enabling proactive workflows and collective work while requiring memory systems, security, and architecture design as prerequisites that frontier labs have invested in to maintain capability gaps.

Recap

Claude Tag represents a paradigm shift: agents are moving from single-player (like Claude Code on your machine) to multiplayer org-level harnesses accessible to everyone in an organization. An org harness has its own identity, not tied to individual users, and access to organizational context. Benefits include checking others' work, deduplicating findings, performing internal research, and dramatically accelerating onboarding compared to each employee building their own harness. Async agents are increasingly proactive, not just reactive — they can alert you to things the org needs to know. Frontier models outperform others on long-horizon tasks because it's not just model capability; it's the combination of model capability, memory systems, security (resistance to prompt injection), and the decoupled architecture itself. Memory substrates work best when general (file system or database) and not prescriptively structured — models learn to manage their own memory better than humans can intuit upfront.

Key points

• Claude Tag is often dismissed as a Slack bot, but its value is in being an org-level harness with organizational identity and context, not user-specific tuning. 16:38
• Org-level harnesses allow deduplication of findings, internal research coordination, and give all employees access to a fully-configured harness on day one instead of weeks to ramp up. 16:51
• Async agents can be proactive, not just reactive — they can be configured to alert the org about important patterns in organizational context. 18:27
• Multiplayer harnesses steered by many people concurrently is a shift in agent UX that will become common. 19:03
• Frontier models perform better on long-horizon tasks not just because of raw capability, but because of investments in memory, security, architecture (brain-hands decoupling), and infrastructure. 20:42
• General memory substrates (file system or database) perform better than prescriptively structured memory schemas; models learn to manage their own memory much better than humans can design upfront. 22:44
• Models can reason about their own context and memory structure better than prescribed schemas — letting the model manage memory is a key lesson, not pre-populating memory types. 22:51
• Evals are necessary to confirm dreaming corrections are correct in your specific context; the Pokémon example is anecdotal, but drearming has been validated across multiple evals. 24:36

Terms

• Org-level harness — an agent tool with organizational identity (not user-specific), access to org context, and available to all employees simultaneously. 16:51
• Proactive agents — async agents configured to alert or initiate actions based on organizational context, not just respond to user direction. 18:27
• Memory substrate — the underlying system (file system, database, or other) where the model stores and manages persistent knowledge. 22:12
• Multiplayer harness — an agent tool that multiple users can steer concurrently, pooling their direction rather than isolated single-user agents. 19:03

Quick quiz · tap to flip

Connections

• builds-on Task horizon and managed agents architecture — org harnesses rely on the reliable decoupled architecture of Managed Agents
• builds-on Verifiers and self-learning memory systems — proactive workflows and collective work depend on memory and verifier systems working reliably

Open questions

• How are access permissions and credential boundaries managed when an org harness has access to sensitive organizational data?
• What safeguards prevent one user's misconfiguration of the org harness from affecting others?
• How do you design org context visibility levels when different teams need different access?

The Agent Auth Problem

Agents acting on behalf of users with full user credentials poses a security risk analogous to giving an employee unrestricted CEO access instead of a limited, revokable job role.

Recap

Paola introduces the security risk of giving AI agents direct access to user accounts (Gmail, calendars, personal data) with full user credentials. She analogizes agent authentication to hiring: just as you wouldn't give a new hire your CEO credentials, you shouldn't give agents unrestricted access to everything. The core insight is that agents need their own authority rather than masquerading as the user. This leads to three fundamental problems that authentication systems must solve: discovery (how agents learn what they can do), authorization (granting specific, scoped access), and traceability (knowing which agent did what on behalf of which user).

Key points

• Many developers connect AI agents to personal accounts (Gmail, calendars) by giving agents full user credentials, which is a significant security risk 1:47
• The hiring analogy shows the problem: you don't give a new hire your CEO credentials; instead you grant them specific authority for their role 2:55
• Discovery is the first problem: agents need an automatic way to find out what services and capabilities they can access, rather than manual configuration each time 5:36
• Authorization requires granting agents fine-grained access rather than blanket permissions; for example, read-only access to Gmail without send or delete capabilities 6:02
• Traceability and audit logging are essential: you must be able to see which agent performed which action on behalf of which user, enabling revocation if something goes wrong 7:00

Terms

• Agent — An AI system that acts on behalf of a user, performing tasks like sending emails or reading calendars 0:25
• Credentials — Authentication tokens or passwords that prove identity; giving an agent your full credentials means it acts with all your permissions 2:00
• Authority — Specific, limited permissions granted to an agent, separate from the user's full capabilities 3:37
• Scopes — Broad permission categories (like "read" or "write") that are too coarse for fine-grained control 9:31

Quick quiz · tap to flip

Connections

• prerequisite-for Capabilities, Scopes, and Service Discovery — This section establishes the three problems that the capabilities framework and discovery system solve

Open questions

• How do current deployed AI systems typically authenticate to user services today, and what are the most common breach scenarios?
• Beyond audit logging, what enforcement mechanisms prevent an agent from exceeding its granted authority?

Capabilities, Scopes, and Service Discovery

Agents need fine-grained capability discovery through standards like OpenAPI and a directory service to automatically learn what actions they can perform, replacing manual configuration.

Recap

Paola explains the difference between scopes (broad, coarse-grained permissions like "read") and capabilities (fine-grained, specific actions like "list emails from last week"). The solution involves two components: (1) a well-known configuration endpoint (analogous to OIDC in identity systems) where services publish what they can do, and (2) a directory that translates OpenAPI specifications into agent-readable capabilities. Until services natively support this protocol, a middleware directory serves as a "phone book" for agents, aggregating service capabilities so agents can automatically discover and map their intents to available tools without manual configuration.

Key points

• Scopes are too coarse-grained; a "read" scope gives access to everything readable, whereas capabilities are specific actions that can be individually granted or denied 9:13
• An agent's intent (like "get my emails from last week") must be mapped to specific capabilities or tools; discoverability solves how that mapping happens automatically 10:00
• A well-known configuration endpoint lets services publish what they offer, analogous to OIDC's well-known endpoint in identity systems 10:38
• Most common services expose OpenAPI specs; a directory translates these OpenAPI specifications into capabilities so agents can understand what a service can do 11:56
• The directory acts as a "phone book" for agents, allowing them to look up services and their capabilities, similar to how people once looked up phone numbers 15:18
• Capabilities can be manually declared in the directory when services don't natively support the protocol, allowing coverage of custom workflows and services without OpenAPI specs 16:37

Terms

• Capability — A fine-grained, specific action an agent can perform (e.g., "delete email") rather than a broad scope 9:28
• OpenAPI — A standard specification format that describes REST API endpoints and their operations, which can be translated into capabilities 11:47
• Well-known configuration endpoint — A standardized location (like .well-known/agent-protocol) where services publish their capabilities and configuration, inspired by OIDC 10:38
• Directory — A centralized service that aggregates and translates OpenAPI specs and custom capability declarations so agents can discover what they can do 11:36

Quick quiz · tap to flip

Connections

• builds-on The Agent Auth Problem — Solves the discovery problem identified in the first section
• prerequisite-for Agent Identity and Cryptographic Key-Based Authentication — Establishes the framework that enables per-agent identity and authorization

Open questions

• What happens when a service updates its OpenAPI spec or capabilities after an agent has cached the directory?
• How does the directory handle versioning of capabilities as services evolve?
• Are there security implications if a compromised directory lists false or malicious capabilities?

Agent Identity and Cryptographic Key-Based Authentication

Giving each agent a private key enables them to be cryptographic principals that sign their own tokens and can be individually revoked, shifting the security model from agents masquerading as users to agents acting as accountable, identifiable actors.

Recap

Paola explains how to give agents their own identity through private key infrastructure. Each agent receives a private key that allows it to sign its own tokens; this eliminates the need for agents to impersonate users. With agent identity established, logs can show not just that "a user accessed Gmail" but specifically that "agent X from host Y accessed Gmail on behalf of user Z." This shift from agents hiding behind user credentials to agents acting as identifiable principals enables fine-grained revocation: if an agent misbehaves, you can revoke just that agent's key, and also revoke the host or other agents from the same host. Agents are never detached from their users but become a new layer of accountable actors.

Key points

• Each agent gets its own private key, making the agent a cryptographic principal that can sign tokens 17:27
• With agent identity, logs shift from "user accessed service" to "agent accessed service on behalf of user," enabling fine-grained accountability 18:20
• The paradigm shifts from agents hiding behind user credentials to agents operating as principals; services can now distinguish an agent from its user 18:43
• Individual revocation is now possible: if an agent misbehaves, you can revoke only that agent without disconnecting the entire user's access 19:11
• A new "host" concept identifies where the agent was created from, allowing you to revoke all agents from a compromised host 20:06
• Agents always have a user they report to; they are never detached, maintaining the link between agent actions and human accountability 19:41

Terms

• Agent identity — A unique identifier and private key assigned to an agent, allowing it to act as an independent principal rather than masquerading as a user 17:27
• Private key — A cryptographic key held by an agent that allows it to sign tokens and prove its identity 17:27
• Principal — An actor (user, agent, or service) that can be authenticated and granted permissions in a security system 15:52
• Host — The context or platform where an agent was created (e.g., Cursor, Claude, or another IDE/tool), which can be revoked as a unit 20:08
• Token revocation — The ability to invalidate specific credentials; agent key-based auth enables revoking just one agent without affecting the user's other access 19:11

Quick quiz · tap to flip

Connections

• builds-on Capabilities, Scopes, and Service Discovery — Uses the capability framework to determine what each agent can do
• builds-on The Agent Auth Problem — Solves the traceability and revocation problems identified in the introduction

Open questions

• What key rotation or expiration policies should govern agent private keys?
• How does this interact with existing OAuth2 or other authentication flows that users are already familiar with?
• If an agent's private key is compromised, how is that breach detected and contained?
• How does the system prevent agents from sharing keys or a rogue agent impersonating another agent's key?

Three layers, one protocol — building Better Auth's architecture

Better Auth structures agent authentication in three layers—agent plugin on the server, SDK with MCP on the client, and a directory for capability discovery—unified by a single protocol that enables fine-grained capability control and identity tracking.

Recap

Better Auth addresses the challenge of securely giving agents access to user resources through a three-layer architecture. The server side features an agent plugin that can verify agents and issue capability grants. The client side includes an SDK shipped with an MCP that enables connection and testing. A directory acts as a capability matcher between agent intents and available actions. The demo showed how agents request specific capabilities (like reading emails), how device flow approval works, and how agents gain identity and logged activity for full traceability.

Key points

• Better Auth uses a three-layer architecture: an agent plugin for server verification and grants, an SDK with MCP integration on the client side, and a directory that matches agent intents with capabilities. 22:01
• The directory is described as "a place like a phone book" where "intent will be matching the capabilities," allowing agents to discover what actions they can perform. 22:49
• Device flow authentication treats agents as if they were another device, requiring explicit approval before agents can access resources. 25:19
• The system provides "logs and everything," giving users visibility into what agents are doing and when they are doing it. 26:18
• Default capabilities like email reading are considered safe and do not require approval each time, reducing friction while maintaining security. 26:58

Terms

• Directory — a capability matcher that serves like "a phone book" to connect agent intents with available actions. 22:49
• Device flow — an authentication method where agents are treated as connected devices requesting and receiving approval for specific operations. 25:19
• MCP integration — SDK feature that allows agents to connect and test capabilities through a standard Model Context Protocol interface. 22:37
• Agent identity — a tracked identifier for each agent that enables logging of all actions and provides full traceability of agent activity. 26:23

Quick quiz · tap to flip

Open questions

• How does the system scale when multiple agents request capabilities simultaneously?
• What happens when an agent's identity is spoofed or forged?

Capability revocation and policy-based access control

Better Auth implements capability-based security where agents can be revoked or approved per operation, and both user policies and host policies enforce constraints, balancing safety with usability.

Recap

Better Auth's capability model allows users to approve or deny specific operations without blocking all agent access. The demo showed client back channel authorization (CBCA), where approval can happen on the device rather than requiring a redirect. When an agent is revoked, it immediately loses access to all granted capabilities, even for default operations, making revocation an effective kill switch. The system supports constraints like maximum execution time. Better Auth addresses the UX challenge of security by using default capabilities for trusted actions (like email listing) while requiring approval for high-risk operations (like sending emails). The directory and MCP proxy clarification showed that the system is designed as a capability matcher, not a centralized proxy, to avoid scalability issues.

Key points

• Client back channel authorization (CBCA) allows agents to be approved without a redirect, enabling approval from the device itself. 28:37
• When an agent is revoked, it immediately cannot execute any operation, even those that would normally be default capabilities. 30:04
• Capability constraints can include specifications like "maximum time of executing" and other limits enforced per operation. 31:49
• Better Auth balances safety and usability by making email reading a default capability (safe) while requiring approval for email sending (potentially risky). 26:58
• User policies and host policies allow different teams and individuals to configure access differently, applying constraints either per user or per host. 32:21
• The server always verifies agent access; "all the time verifying" ensures that policies are enforced on every request. 33:08
• The directory is not a proxy but a capability matcher for scalability; "proxy uses data" and would not scale, while a directory only matches intent to capabilities. 35:59

Terms

• Client back channel authorization (CBCA) — an authorization method where the device or client approves requests directly rather than requiring a redirect to an approval page. 28:37
• Revocation — the action of withdrawing all granted capabilities from an agent, immediately preventing it from executing any operation. 30:04
• Default capabilities — operations considered safe enough to execute without explicit user approval each time (e.g., email listing). 26:58
• Host policies — rules that apply to all users or a group within a host organization for managing agent access. 32:21
• User policies — individual user-level rules and constraints for agent access and capability execution. 32:21

Quick quiz · tap to flip

Connections

• builds-on Three layers, one protocol — building Better Auth's architecture — extends the three-layer architecture with specific security mechanisms and policies.

Open questions

• How are constraints like execution time enforced at runtime?
• Can an agent re-request a revoked capability, or is revocation permanent until re-approved?

Authority over credentials — the principle of agent identity

Better Auth's core principle is giving agents authority within defined limits instead of sharing credentials; agents need their own identity to enable full traceability and controlled access rather than unrestricted impersonation.

Recap

The workshop wrapped up by articulating Better Auth's foundational principle: rather than giving agents full credentials or asking them to impersonate users, the system grants agents authority to act within specified limits. This shift from "pretend to be me" to "act for me within these limits" requires agents to have their own identity, enabling traceability and lifecycle management. Unlike some competing systems, Better Auth treats agents as first-class principals with identity, not as proxy identities or temporary delegates. The presenter invited the community to contribute to the open-source project through Discord and email.

Key points

• The most important shift Better Auth introduces is moving from giving agents credentials to giving them authority: "stop giving credentials to our agents we need to give them authority." 37:08
• The distinction is between "pretend to be me" and "act for me within these limits"—a fundamental reframing of how agents should interact with resources. 37:18
• Better Auth solves three core problems: "discovery, authorization and identity." 36:30
• Agents in Better Auth have "their own identity" unlike other systems, enabling "the whole life cycle and to be able to track down and hunt if you want an agent." 39:51
• The SDK on the client side handles key creation and assignment to agents, while the server verifies, authorizes, and grants capabilities approved by the user. 36:43
• Better Auth is an open-source project seeking community contributions and feedback, with the premise that "if we improve this for all it's going to be good for all of us." 37:47

Terms

• Authority over credentials — the principle of granting agents permission to act within defined limits rather than sharing full user credentials or credentials that allow unrestricted impersonation. 37:08
• Agent identity — a distinct identity assigned to each agent that enables traceability, lifecycle management, and the ability to audit agent actions. 39:51
• Discovery, authorization, and identity — the three core problems Better Auth addresses in its protocol and architecture. 36:30

Quick quiz · tap to flip

Connections

• builds-on Capability revocation and policy-based access control — applies the capability model to articulate the principle of authority and identity.
• builds-on Three layers, one protocol — building Better Auth's architecture — extends the three-layer architecture with a philosophical foundation.

Open questions

• How does agent identity persist across different MCP connections or endpoints?
• What happens to historical logs of a revoked agent?

From LLMs to Harnesses, then Always-On Clouds

The agent paradigm has evolved from one-shot LLM calls to durable, feature-rich harnesses that run in the cloud continuously, enabling parallel work and human steering.

Recap

An agent differs from a bare LLM by adding a loop, tool calls, memory, retry logic, and context engineering. Harnesses extend agents with durability and "doggedness"—the ability to run for hours or days, persisting state across failures. They add planning modes, parallel sub-agents, TUI affordances, dynamic skill creation, and background task support. The latest shift is from local harnesses to always-on cloud harnesses that run continuously in Slack or mobile apps, enable more parallelism via sandboxes, and accept work from multiple users.

Key points

• Agents differ from LLMs by adding an agent loop, tool calls, memory, ability to retry failed tasks, context engineering, and agent state. 2:37
• Harnesses introduce durability and "doggedness"—running not for minutes but for hours or days, persisting stream state to resume after connection loss. 3:16
• Harnesses can run in planning mode, spawn parallel sub-agents to fan out multiple tasks, and provide TUI slash commands and dynamic skill creation. 3:48
• Cloud harnesses run always-on in Slack with multiple users, may tunnel to local machines or run in cloud sandboxes for more parallelism, and accept work via mobile apps or direct API requests. 5:20
• Cloud harnesses shift code creation from local work trees to Git PRs pushed directly to GitHub, requiring a different architecture but enabling more resources and power. 6:25

Terms

• Agent — An LLM wrapped in a loop with tool calls, memory, retry logic, and the ability to track and manage state across multiple turns. 2:37
• Harness — A durable, feature-rich agent framework that can run for hours or days, handle parallel sub-agents, support user steering and interruption, and dynamically create skills on the fly. 3:16
• Cloud harness — An always-on harness running in the cloud (e.g., in Slack or via mobile app), capable of accepting work from multiple users and spawning many sandboxed sub-agents in parallel. 5:20

Quick quiz · tap to flip

Open questions

• How do harnesses determine when to spin up parallel sub-agents versus sequential execution?
• What are the failure modes when multiple users are steering the same cloud harness simultaneously?

Claws, Initiative Learning, and the Coming Shakeout

Harnesses will evolve into "claws"—proactive agents with initiative and continual learning—but only a few will survive in each category as the market consolidates around high-value or high-frequency use cases.

Recap

The next phase beyond harnesses is "claws"—agents with initiative that act without waiting for user input, listening to external services with a heartbeat, available across multiple channels (Slack, SMS, WhatsApp, Telegram), and capable of continual learning by modifying skills or code based on traces. Bhagwat predicts "Steinberger's law": every harness will expand until it becomes a claw. However, a market shakeout will follow, similar to the mobile app consolidation of the 2010s, where only one or two apps dominate each category. Users have limited mental space and will stick with apps that are either economically valuable or used frequently; others will be forgotten. The current excitement masks a future where only the most capable claws survive, forcing builders to ensure their agents have the features users need.

Key points

• Claws add initiative: they listen to external services via a heartbeat, are accessible over multiple channels (Slack, SMS, WhatsApp, Telegram), and persist memory in ways beyond simple file storage. 7:10
• Claws have a daemon or gateway to send and receive requests, can perform continual learning by auto-improving based on generated traces, and support automatic skill generation or code modification. 8:05
• Bhagwat's "Steinberger's law" asserts that every harness will expand until it becomes a claw, driven by technological, economic, and psychological factors. 9:50
• Harnesses expand because users want to text them, start overnight tasks, and get the "dopamine casino" of putting in tokens and getting out code and actions. 10:16
• A market shakeout is coming, analogous to mobile app consolidation: users have mental space for only one or two apps per category (e.g., Uber/Lyft for rides, Airbnb for accommodations), retaining only those that are economically valuable or used frequently. 11:15
• For builders, the advice is to ensure agents have all capabilities users need, because if they don't, competitors with more powerful offerings will attract users quickly; there will also be future waves of disruption. 14:03

Terms

• Claw — A proactive agent with initiative that monitors external services, is accessible via multiple channels, and performs continual learning to improve itself over time. 7:10
• Initiative — The property of an agent acting autonomously without waiting for user input, listening to feeds and waking on a defined heartbeat to take actions. 7:10
• Continual learning — The ability of an agent to autoimprove based on traces it generates, through automatic skill generation or modification of the code driving it. 8:05
• Steinberger's law — The principle that every harness will expand until it becomes a claw, driven by technological, economic, and psychological factors. 9:50

Quick quiz · tap to flip

Connections

• builds-on From LLMs to Harnesses, then Always-On Clouds — claws are the evolution of harnesses described in the previous section.

Open questions

• What are the concrete mechanisms by which claws perform continual learning, and which approaches (automatic skill generation vs. code modification) are proving most effective?
• Which categories of agent-driven work will survive the shakeout, and which will consolidate fastest?
• How do users' mental space limits translate quantitatively to market share in multi-claw categories?

Introduction and the case for HTML

Agents democratize building, but launching products still requires new infrastructure—specifically, the ability to generate video composition through HTML, which is the native language of LLMs.

Recap

Coding agents have made it easy to build anything, but HeyGen's James Russo argues that launching a product into the world is still difficult. To solve this, HeyGen focuses on video as a communication tool. Great videos need more than just an AI avatar—they require proper composition with B-roll, animations, captions, and music. Because HTML, CSS, and JavaScript are the native languages most LLMs trained on (since they underlie every webpage), they are the natural way to let agents generate all these video layers without forcing them to learn new, custom languages.

Key points

• The challenge is not building with agents—"agents have democratized building"—but rather launching products and reaching audiences. 1:07
• Great videos require layered composition: A-roll (the narrator), B-roll (images and media), animations, captions, and music—not just a single AI avatar. 1:35
• HTML, CSS, and JavaScript are "the native languages of LLMs" because most of their training data comes from webpages, which are fundamentally built on these technologies. 2:24
• Teaching LLMs a custom DSL or JSON structure is like "asking Shakespeare to write a poem in Japanese or Chinese"—they can do it with examples, but will not produce their best work. 2:43

Terms

• A-roll — The main narrator or character footage in a video, the primary subject shown on screen. 1:35
• B-roll — Supporting images, video, and media assets that add context and visual interest to the main footage. 1:49
• Native language (for LLMs) — A programming or markup language that LLMs can generate fluently because it dominates their training data. 2:24
• DSL (domain-specific language) — A custom language designed for a specific problem domain; learning one forces LLMs to "speak another language" instead of their native tongue. 2:37

Quick quiz · tap to flip

Connections

• prerequisite-for Comparing HTML to other frameworks — Establishes the motivation for why HTML is superior to other frameworks.

Comparing HTML to other frameworks

HTML's alignment with LLM native capabilities gives it a step-function advantage over custom video frameworks, which require teaching both language and creative principles.

Recap

HeyGen compared HTML to existing video creation frameworks: After Effects and Premiere Pro create excellent output but require constant human direction, Lottie and Rive use JSON or XML formats that are not LLM-native, and Remotion (React-based code) requires teaching both the framework and creative principles. Notably, with Gemini 3 and later models, there was a "step function improvement"—LLMs naturally gravitated toward HTML, CSS, and JavaScript without extensive prompting. This success came from letting models generate in their native language rather than fighting them.

Key points

• After Effects and Premiere Pro create high-quality output but are "not very agent-friendly"—they function as co-pilots for existing knowledge rather than enabling independent creative generation. 3:54
• Lottie and Rive use JSON or XML formats that, while yielding decent output, are not LLM-native languages and thus lack the "controllability layer" agents need. 4:13
• Remotion is agent-friendly but forces a trade-off: "we had to teach them the language and give them a bunch of examples," which "ultimately took away a lot of the creativity." 4:37
• In November 2023, with Gemini 3 and the latest models, there was a "step function improvement" when LLMs saw examples and "naturally gravitated toward HTML, CSS, and JavaScript." 5:00
• The insight: "let's not fight the model, but find a way where we can let them talk in their native tongue." 5:18

Terms

• Step function improvement — A discontinuous jump in capability, not incremental progress—the jump LLMs made when given HTML instead of custom frameworks. 5:05
• Agent-friendly — A framework that allows independent creative generation without requiring the agent to follow explicit steps or extensive examples. 3:51
• Controllability — The degree to which a format can be edited and modified to suit different outputs; a property JSON and XML formats lack compared to HTML. 4:31

Quick quiz · tap to flip

Connections

• builds-on Introduction and the case for HTML — Justifies why HTML (established in the previous section as LLMs' native language) outperforms alternatives.
• prerequisite-for Hyperframes: Browser-native video rendering — Sets up the need for a framework that leverages HTML at runtime.

Open questions

• Why did Gemini 3 specifically trigger the step-function improvement, rather than earlier models?
• What are the limitations of LLM-native output even when using HTML?

Hyperframes: Browser-native video rendering

Turning browser HTML into deterministic video requires freezing the browser's asynchronous rendering model and capturing frame-by-frame snapshots to ensure every output pixel is predictable and reproducible.

Recap

HeyGen's Hyperframes framework converts agent-generated HTML into reproducible MP4 videos. The core challenge: browsers are designed to load asynchronously (fonts, images, and videos arrive over time), while video requires every pixel to be finalized. The solution is to freeze the browser's clock, deterministically seek to each frame moment in time, wait for all assets to load, take a screenshot, then move to the next frame. This process repeats to capture all frames needed for encoding. The framework uses a minimal HTML wrapper with data attributes for metadata, and because everything rendered in a browser can be captured this way, Hyperframes supports any browser-native technology: Three.js, WebGL, WebGPU, shaders, SVGs, Lottie, and charts.

Key points

• Browsers are fundamentally asynchronous—fonts and images load over time—which is incompatible with video, where "we need everything on the page 100% of the time." 7:31
• The framework uses "the thinnest wrapper" around HTML: "essentially just HTML at the end of the day with a few data attributes as metadata." 5:53
• Rendering works by "freezing the clock in the browser" and then "seek[ing] deterministically to every single moment in time," waiting for assets, taking a screenshot, and repeating for all frames. 8:25
• Any browser-renderable technology is now renderable in Hyperframes: "Things like 3.js, charts, SVGs, shaders, WebGL, WebGPU, Lottie, all of these are renderable in the browser, and therefore all of them are renderable in hyperframes." 9:01
• Testing smaller models (Gemini Flash) proved the approach: "if the smaller models could author workable code in a framework, then the larger models and these coding agents could 100% do it as well." 5:28

Terms

• Deterministic rendering — Video rendering where the same input always produces identical output pixels, with no asynchronous surprises. 7:10
• Freezing the clock — Stopping the browser's normal passage of time to control exactly when and how assets are rendered. 8:25
• Frame-by-frame seeking — The process of stepping through each discrete moment in time, ensuring all assets are loaded, and capturing a screenshot for that moment. 8:31
• Asynchronous rendering (browser) — The browser's default behavior of loading assets (fonts, images, videos) over time as they arrive from the network. 7:15

Quick quiz · tap to flip

Connections

• builds-on Comparing HTML to other frameworks — Hyperframes is the working implementation of HTML as the LLM-native language.
• prerequisite-for Browser capabilities and agent craft — Establishes the rendering foundation before discussing what capabilities it enables.

Open questions

• What is the performance cost of freezing and seeking frame-by-frame across an entire video?
• How does the framework handle dynamically-generated or time-dependent content like animations with random elements?

Browser capabilities and agent craft

Skills couple video composition principles (taste, motion, design) to the framework, teaching agents what makes great video rather than just how to write code.

Recap

Because Hyperframes can render anything a browser can render, HeyGen pairs the framework with Skills—prompting guidance focused on video composition, not code syntax. Unlike other frameworks where skills teach implementation details, Hyperframes skills teach taste: motion principles, design best practices, and visual examples. This "raises the floor" of single-prompt outputs, making a basic request yield reasonable results. The Skills encode lessons learned by finding examples on the internet, tweaking them, and integrating them into prompts. This approach lets agents focus on what they already know (HTML, CSS, JavaScript) while elevating their creative judgment.

Key points

• The distinguishing move: Skills "focus on taste and video aspects because the LLMs and agents already know how to write HTML and CSS and JavaScript." 9:37
• Skills in other frameworks teach syntax; Hyperframes skills teach composition: "if you look at certain skills, it's really just like how do you write something in that framework?" versus Hyperframes where "we just teach them how to create good videos." 9:50
• The process: find examples on the internet, tweak them, encode them into Skills, so agents can "go ahead and get good output" from a single prompt. 10:14
• Skills are continuously improved through evaluation: "constantly evaling and using agents to improve them" so the "base output of a single shot prompt gets you pretty good results." 10:04

Terms

• Skills — Prompting guidance and examples that teach agents composition principles and video taste, not code mechanics. 9:35
• Raising the floor — Ensuring that even a simple, single-prompt request produces video of acceptable quality. 10:10
• Taste (in video) — The judgment about composition, motion, pacing, and design that distinguishes a good video from a mediocre one. 9:37

Quick quiz · tap to flip

Connections

• builds-on Hyperframes: Browser-native video rendering — Assumes Hyperframes' rendering foundation exists.
• prerequisite-for Building video at scale — Sets up the need for human-in-the-loop craft once basic skill-aided output is established.

Open questions

• How much quality improvement can be achieved through Skills alone versus requiring human iteration?
• Are Skills specific to Hyperframes or reusable across other HTML-based video frameworks?

Building video at scale

Great video output requires iterative, human-led craft—not single prompts—with tooling (like keyframes) that mirrors professional video editing workflows.

Recap

While single prompts can produce decent results, great video demands craft—the same iterative, human-in-the-loop approach as software engineering before AI coding. The workflow mirrors traditional filmmaking: articulate narrative and vision, storyboard frame-by-frame, add motion using HTML/CSS/JavaScript, then use the Hyperframes Studio for final editing. Recently, HeyGen released Keyframes, a feature that lets users coordinate motion frame-by-frame or keyframe-by-keyframe in the studio, providing professional motion designer capabilities within the open-source framework. This human-in-the-loop model has scaled impressively: over 1.3 million videos rendered in 90 days, 267,000 creators trying it, 15,000 videos per day, and 32,000 GitHub stars—proving it's not a demo but production infrastructure.

Key points

• Getting great output requires craft, not just a single prompt: "Similar to AI coding, you can get decent output by just giving a single prompt and having something that works for your needs, but getting great output from agents requires craft, taste." 10:58
• The workflow mirrors pre-AI professional video: "We think about the narrative and the vision and the mission of this video. We storyboard it frame by frame and think about what each frame needs to do." 11:31
• Humans stay in the loop: agents author motion with HTML/CSS/JavaScript, then "utilizing our studio...that last mile editing...humans are always in the loop and have access to do anything that they would do in their normal video editor." 11:48
• Keyframes, released alongside the talk, "allows you to basically coordinate all of this different motion...frame by frame or keyframe by keyframe um in our studio and make sure that you can do anything that a professional motion designer might be able to do in After Effects." 12:11
• Production scale proves viability: "Over 1.3 million videos have been rendered by open-source users of Hyperframes in the last 90 days. 267,000 creators have tried it. We have about 15,000 videos every single day being rendered...and 32,000 GitHub stars." 12:42

Terms

• Craft — The iterative, human-led process of breaking a problem into pieces and working through them systematically to achieve high-quality output. 10:08
• Keyframes — Control points in animation that specify motion values at specific moments in time; Hyperframes' Keyframes feature lets users set and coordinate these within the studio. 12:11
• Storyboarding — Planning a video frame-by-frame in advance, deciding what each frame needs to accomplish before generation begins. 11:35
• Human-in-the-loop — A workflow where humans make iterative decisions and edits rather than ceding all control to automation. 11:53

Quick quiz · tap to flip

Connections

• builds-on Browser capabilities and agent craft — Assumes basic agent-generated output from Skills, then adds human iteration.
• prerequisite-for Benchmarking and the path forward — Establishes the current state of production deployment before discussing limitations and future work.

Open questions

• What fraction of those 1.3 million videos represent production use versus experimentation?
• How does human iteration time scale as video complexity increases?

Benchmarking and the path forward

Current LLMs still struggle with creative work; industry-wide benchmarking and collaboration are needed to raise the floor of agent-generated video.

Recap

Despite Hyperframes' production scale and tooling improvements, HeyGen is honest: "the models still aren't good at creative work." While Skills and evals help, a systemic challenge remains. To address this, HeyGen is collaborating with LLM labs and video creators on a "code to video benchmark," aiming to standardize evaluation and raise the floor of video quality industry-wide. The talk also notes HeyGen's collaboration with the event organizers on an "AI Engineer Warfare showcase video" demonstrating Hyperframes' motion graphics capabilities. The core message: agents have made building easy, but launching still remains hard—and HTML is the tool agents need to bridge that gap.

Key points

• Acknowledging the limitation: "the models still aren't good at creative work. We spend a lot of time evaling and trying to improve this in our skills and push it even further." 13:28
• Moving beyond isolated improvements, HeyGen is "work[ing] on a code to video benchmark where we are trying to work with the LLM labs, any creators who are working on video agents to ensure that we can raise the floor of videos for everyone." 13:44
• The value of industry collaboration: "If anyone is interested in this space or working on this, we'd be happy to be collaborators, talk more about this." 13:57
• The core insight of the talk reframed: "agents are made building incredibly easy. Launching is still quite hard. We think HTML is all your agents need in order to make great videos and launch your product into the world." 14:32

Terms

• Code-to-video benchmark — A standardized evaluation framework for measuring and comparing how well LLMs and agents can generate video from code, with the goal of raising the floor industry-wide. 13:44
• Raising the floor — Improving the baseline quality across all users and models, not just the best-case scenarios. 13:52

Quick quiz · tap to flip

Connections

• builds-on Building video at scale — Follows production deployment by addressing creative quality limitations.
• builds-on Introduction and the case for HTML — Revisits the original tension between building and launching.

Open questions

• What criteria should define a "good" video for benchmarking purposes?
• How will success on a code-to-video benchmark translate to improvements in real-world LLM video generation?
• Why do current models struggle specifically with creative tasks compared to technical tasks?

Introduction and Survey Context

An annual survey of AI engineers provides a ground-truth snapshot of what practitioners actually do, cutting through the noise of model release announcements.

Recap

The presenter, an investment partner at Amplify, has run an annual survey on the state of AI engineering for several years to cut through headline noise and understand what engineers are actually building. This year's survey drew 1,048 respondents and was conducted in partnership with Notion and Verscell.

Key points

• The survey has 1,048 respondents, partnered with Notion and Verscell for the first time. 2:23
• The field changes so rapidly (frontier releases, compute sales announcements) that the survey needs to run annually to capture current ground truth. 0:57

Terms

• AI engineering survey — annual assessment of industry practices conducted across 1,000+ practitioners to track what engineers are actually doing beyond announcements. 0:49

AI Engineering Workforce and Adoption Curves

AI engineering as a discipline spans roles and experience levels, with rapidly accelerating adoption in new modalities like audio and image generation.

Recap

AI engineering is not a single job title but a discipline spanning founders, CTOs, engineers, product managers, and people across company sizes. The cohort skews toward senior software engineers newly entering AI work, though newer engineers today are entering with substantial AI experience already. Text dominates current work, but audio adoption intent has accelerated to 56% among non-users, while image generation usage doubled year-over-year as model quality improved.

Key points

• AI engineering is a discipline touching multiple roles, not a job title: founders, CTOs, engineers, product people across company sizes. 2:33
• The cohort skews toward senior software engineers new to AI: over half with 10+ years software experience have 3 years or less AI experience. 2:48
• Text dominates as the current modality, but audio has the strongest intent to adopt: 56% of non-audio-builders plan to adopt it, accelerating from 37% last year. 4:12
• Image generation usage doubled year-over-year, from 18% to 36%, as models like DALL-E and others improved, showing what happens when a modality crosses quality thresholds. 5:00

Terms

• Intent to adopt ratio — among engineers not currently building with a modality, what percentage plan to use it, a leading indicator of technology trajectory. 4:00
• Modality — a type of AI application (text, image, audio, video), tracked separately for current use and adoption plans. 3:38

Quick quiz · tap to flip

Model Strategy: Multi-Model Adoption and Platform Standardization

Teams adopt multiple models chosen by capability and cost, standardizing on platforms and tools rather than on specific models.

Recap

94% of respondents use closed models and 45% use open-weight models, but open-weight models are augmenting rather than replacing closed ones—over 90% using open-weight also use closed. When choosing models, quality dominates the decision, followed by agentic capabilities like tool calling and cost. The open vs. closed debate gets outsized attention but drives only 5% of model choices. 87% of teams use multiple models with strategies like routing by task type, comparison testing, or cost-based selection. Over half of organizations are standardizing on fewer tools rather than fewer models.

Key points

• 94% use closed models, 45% use open-weight models, with 90%+ of open-weight users also using closed models—open-weight augments rather than replaces. 6:02
• Quality dominates model choice, followed by agentic capabilities (tool calling) and cost; open vs. closed is only a top-three consideration for 5% of respondents. 6:45
• 87% of teams use more than one model, routing by task type, output comparison, or cost. 7:34
• Over half of organizations are standardizing on fewer tools while staying flexible on models, marking an early standardization of platforms rather than individual models. 7:58

Terms

• Agentic capabilities — model features like tool calling and function selection that enable agents to interact with external systems. 6:49
• Multi-model strategy — using different models for different tasks or comparison rather than standardizing on a single model. 7:44

Quick quiz · tap to flip

Cost Constraints and Write-Enabled Agent Proliferation

Cost has become a first-class engineering constraint, and agents are escaping demo world with write permissions and primitive control mechanisms.

Recap

Cost is now a first-class engineering constraint, with 40% of teams adjusting AI usage regularly based on cost and another 36% doing so sometimes—meaning about three-quarters modify behavior due to cost. Token usage and cost are monitored as core SLAs, tracked right after quality. Agent adoption has nearly doubled to 95% of respondents, and critically, agents with write access to systems have jumped from 52% to 89%, tripling the share of all respondents using write-enabled agents. Control mechanisms remain primitive: human-in-the-loop approval and permission gating lead, but teams are experimenting with task decomposition, retrieval, memory, and sandboxing with no clear consensus. Hallucination and context loss mid-task frustrate approximately two-thirds of teams.

Key points

• Cost is a first-class engineering constraint: 40% of teams say it regularly shapes AI ambition, 36% sometimes; total 76% adjust usage based on cost. 8:41
• Cost and token usage are monitored as SLAs, tracked right under quality. 9:22
• 95% of respondents report using agents, roughly double from last year, with 89% having write access (up from 52%), tripling the share across all respondents. 10:12
• Control layers remain primitive: human approval and permission gating lead, followed by scattered approaches (task decomposition, retrieval, memory, sandboxing) with no settled consensus. 11:09
• Two-thirds report frustration with hallucination or losing context mid-task, the core thinking problem rather than plumbing. 11:50

Terms

• First-class engineering constraint — cost is now tracked alongside quality and performance as a core system metric. 9:22
• Write-enabled agents — agents with permissions to modify data in systems they interact with, not just read or summarize. 10:30
• Control layer — the set of mechanisms used to manage and contain agent behavior (approval, gating, memory, sandboxing). 11:34

Quick quiz · tap to flip

Infrastructure Stack Challenges and Build vs. Buy Patterns

Evals remain the top stack challenge and teams build product-adjacent logic in-house while outsourcing commodity infrastructure layers.

Recap

Evals (evaluation methods) have led as the #1 stack challenge for multiple years, though the margin is narrow—96% of respondents have a stack problem but simply disagree on which layer to prioritize. Vibe review remains the most-used evaluation method and hasn't changed year-over-year. Across eight infrastructure layers, respondents show wide variation in build vs. buy decisions. Inference and model serving is the most-bought layer, while prompt management is the most-built (61% build it). Product-adjacent layers like prompt management, RAG, and eval tend to stay in-house, while fine-tuning remains underpenetrated—most teams don't have it, and those who bought are locked in while those who built are not exploring buying.

Key points

• Evals lead as the #1 stack challenge every year, though by a narrow margin, with vibe review remaining the top evaluation method. 12:12
• 96% of respondents have a stack problem but disagree on which layer, meaning infrastructure needs scatter across the full stack. 12:22
• Inference and model serving is the most-bought layer; prompt management is the most-built at 61%. 13:12
• Product logic layers (prompts, RAG, eval) tend to stay in-house on a relative basis, while fine-tuning is mostly unadopted, with those who bought locked in and those who built not exploring alternatives. 13:27

Terms

• Vibe review — subjective manual evaluation of AI outputs, the most common eval method in practice. 12:44
• Build vs. buy trade-off — the decision for each infrastructure layer to either build in-house or outsource to a third-party provider. 12:55
• Product logic layers — parts of the stack directly adjacent to product decisions (prompts, RAG, evaluation), typically kept in-house. 13:31

Quick quiz · tap to flip

Impact on Engineering Culture and Organizational Structure

AI dramatically accelerates experimentation and democratizes feature shipping, but erodes deep technical specialization and blurs role boundaries.

Recap

97% of teams report a net positive effect of AI on their organizations, primarily through cheaper failure rates, more experimentation, more prototypes, and lower-friction bet-placing. However, the same tool that enables cheap code generation increases review burden. Nine in ten respondents see negative downstream effects, most commonly the erosion of deep technical skills and codebase understanding. 81% report AI blurring lines between engineering, product design, and marketing. One-third of teams now have non-developers shipping features, with 17% saying non-developers regularly ship customer-facing features. Shipping software is no longer gated on being an engineer.

Key points

• 97% report net positive organizational effect; the primary benefit is cheaper failure enabling more experimentation and bets, not just speed. 14:21
• The same tool that enables experimentation increases review burden, with nine in ten seeing negative downstream effects like erosion of technical depth. 14:50
• 81% report AI blurring boundaries between engineering, product design, and marketing roles. 15:31
• One-third of teams have non-developers shipping features; 17% say non-developers regularly ship customer-facing features across the stack. 15:54

Terms

• Cheaper failure — the ability to rapidly prototype and discard failed experiments at low cost, enabling higher-risk bets. 14:30
• Review burden — the increase in work required to verify and validate code as more features are generated and need assessment. 14:50
• Erosion of deep technical skills — loss of specialized expertise and system knowledge as code generation automates tasks previously requiring mastery. 15:12

Quick quiz · tap to flip

Future Bets and Predictions

Engineers are satisfied with current AI capabilities but skeptical about long-term code liability and uncertain about future architectural paradigms.

Recap

76% of respondents say AI has boosted their job satisfaction, but 59% fear that today's AI-generated code creates long-term liabilities. Only one-third consider software engineering a solved problem. Looking five years ahead, 67% expect a leading lab to declare AGI (though the survey framed this as a press release, not an achievement), and only 9% bet on Transformers remaining state-of-the-art. Most are unsure about architectural change. The survey's meta-observation is that image generation doubled adoption as models crossed quality thresholds, audio shows the highest intent to adopt, cost has become a first-class constraint, open weights augment rather than replace closed models, agents have expanded write access but with primitive controls, and product logic tends to stay in-house while infrastructure gets bought.

Key points

• 76% report AI boosted job satisfaction, but 59% fear today's AI code creates long-term liabilities. 16:39 16:58
• Only one-third call software engineering a solved problem; the definition itself varies among respondents. 17:02
• 67% expect a leading lab to declare AGI in five years (press release, not achievement); only 9% bet on Transformers staying state-of-the-art. 17:28
• Image generation doubled adoption by reaching quality thresholds; audio shows strong adoption intent; open weights augment rather than replace closed models. 18:11
• Agents gained write access but guardrails stayed primitive; inference is bought while product logic stays in-house. 18:44

Terms

• AGI declaration — a leading lab's public claim of achieving Artificial General Intelligence, as distinct from actual achievement. 17:34
• Long-term code liabilities — technical debt and maintenance costs incurred by accepting AI-generated code without full understanding or long-term design. 16:58

Quick quiz · tap to flip

Open questions

• What architectural changes might displace Transformers, and on what timescale?
• How will long-term maintenance and refactoring of AI-generated code affect software quality and team velocity?