No PriorsNo Priors Ep. 41 | With Imbue Co-Founders Kanjun Qiu and Josh Albrecht
CHAPTERS
- 0:05 – 2:25
Imbue’s origin story: from shared house to building agentic systems
Sarah opens by introducing Imbue and its focus on reasoning-and-coding agents. Kanjun and Josh explain how they met, their early interests (human agency + AI), and how those threads converged into starting Imbue.
- •Kanjun and Josh’s early collaboration and shared living/working environment
- •Long-standing motivation: increasing human agency via software
- •Sourceress as an early “agent-like” product experience
- •Seeing scaling laws (GPT-3 era) as an inflection point
- •Imbue’s founding thesis: self-supervised representations may unlock broader capabilities
- 2:25 – 4:57
Why agents (not chatbots): moving from answers to actions
The conversation frames agents as systems that do real work rather than merely producing text. They emphasize today’s burden of verification on the user and argue that the real promise is goal-directed action on a user’s behalf.
- •Agents as systems that accomplish goals, not just respond
- •Chatbots shift verification/implementation work back to the user
- •Computers today require constant micromanagement
- •A future where you give intent and the computer executes autonomously
- •Analogy: early computers as room-sized calculators vs modern general computing
- 4:57 – 6:28
Agent task spectrum: specific→general and copilot→autonomous
Kanjun lays out two key dimensions for agent capability: how specialized vs general the agent is, and how assistant-like vs autonomous it is. Rather than a single missing breakthrough, they predict incremental progress as reliability and interaction improve.
- •Agents already exist in narrow, hardcoded enterprise workflows
- •Two axes: specialization vs generalization; copilot vs autonomy
- •Generalization requires better reasoning and better computer interaction
- •Progress is gradual, not binary—capabilities eat more workflows over time
- •Current production blockers show up most clearly as reliability issues
- 6:28 – 7:40
The reliability bottleneck: reasoning, uncertainty, and error correction loops
They describe the present era as “lossy” and unreliable, making agents hard to productionize. Improving agent reliability involves better reasoning about plans, recognizing uncertainty, and adding structured error-correction methods.
- •Core blocker: systems don’t behave reliably step-by-step
- •Reasoning includes planning, deciding when to ask for help, and uncertainty awareness
- •Comparing and selecting among multiple action plans
- •Error correction as a central technique (e.g., chain/tree-of-thought as examples)
- •Framing progress as incremental reliability gains (60%→70%→80%)
- 7:40 – 10:35
Cost vs generalization: when to specialize models and workflows
Elad asks about the common pattern of prototyping with the best model then optimizing costs with smaller or fine-tuned models. Josh and Kanjun describe a pragmatic mix: general systems can bootstrap specialized code and smaller “minimum viable” models for specific capabilities.
- •Real-world builder pattern: GPT-4 prototype → cheaper models for scale
- •General capability can be used to generate specialized implementations (often as code)
- •Agent workflows can mix specialized and general models across substeps
- •“Minimal viable models” per capability rather than one giant model everywhere
- •Analogy to PCs vs supercomputers: many markets favor pragmatic, smaller systems
- 10:35 – 12:33
Why agents need more than next-token prediction: outer loops and planning
Sarah probes why agent reasoning needs different approaches beyond standard LLMs. Josh argues that executing algorithms and multi-step tasks requires an outer control loop to choose actions, gather information, and manage certainty—beyond what fits into simple prompt/context behavior.
- •LLMs excel at next-token prediction but face structural limits for algorithm execution
- •Need an outer loop: decide the next step, when to fetch info, and how to verify
- •Reasoning as a system-level process, not purely “inside the model”
- •Shared understanding across major labs: wrappers/agent systems are necessary
- •Language is a useful medium; code is another important medium
- 12:33 – 14:07
Code + language as a spectrum: hardcoded logic, LLM decisions, and fusion
They explain why Imbue focuses early on coding agents: code offers repeatability, robustness, and an interface for action. Effective agents blend language-model flexibility with code-based structure, moving pieces toward code as tasks become repeatable and well-understood.
- •Today’s ‘reasoning agents’ are often hardcoded decision trees in production
- •Not binary: there’s a spectrum between code and language-driven reasoning
- •Fusion approach: use LLMs for flexible decisions and code for robustness
- •As tasks repeat, convert nebulous behaviors into codified procedures
- •Agent loops decompose into chunks that can be “turned into code”
- 14:07 – 15:16
“Serious use” as research strategy: build agents you’d rely on daily
Kanjun describes Imbue’s approach of dogfooding: building agents they personally want to use every day. Real usage exposes reliability gaps and drives incremental technique development rather than betting on a single giant-model breakthrough.
- •“Serious use”: prioritize agents that are genuinely useful day-to-day
- •Reliability is the biggest blocker to everyday adoption
- •Work spans coding agents and operational business processes
- •Incremental iteration is what forces new techniques to emerge
- •Rejects the idea that ‘train a giant model and it magically works’
- 15:16 – 17:11
Choosing tasks and composing sub-agents: from PR linters to general to-do agents
They outline how they select tasks based on usefulness, feasibility, generality, and technique-leverage. Examples range from highly specific PR/type-error fixers to broad “to-do” agents, and they describe an architecture where agents can call specialized sub-agents to improve success rates.
- •Task selection criteria: frequency, usefulness, feasibility, general applicability
- •Two example endpoints: broad codebase to-do agent vs narrow PR/type-error fixer
- •Capabilities can ‘meet in the middle’ as each endpoint expands
- •Sub-agent orchestration: general agent calls specialized tools when appropriate
- •System-level generality can come from composing specialized components
- 17:11 – 19:20
Evaluation as the core work: decomposing success into measurable attributes
Josh explains that evaluation design is one of the most important and time-consuming parts of building agents. They break down outcomes into measurable dimensions (tests, minimal diffs, style, naming, trustworthiness) and use that decomposition to build scalable evaluation loops beyond just pass/fail.
- •Defining ‘good’ output requires decomposing multiple competing objectives
- •Measure concrete attributes: correctness, test pass rate, minimal changes, style
- •Include qualitative dimensions like trust and readiness-to-run
- •Code is attractive because many metrics can be made objective
- •Breaking evaluation into sub-questions preserves information beyond binary correctness
- 19:20 – 22:04
Product vs research: building the agent stack so agents aren’t “assembly programming”
Sarah asks about sequencing productization vs research. Kanjun argues Imbue is a product company, but the tech needs better systems/frameworks to build reliable agents quickly—today feels like writing agents in assembly, limiting what can be built and who can build it.
- •Imbue identifies as a product company with timing constraints of the tech curve
- •‘Reasoning’ as a bucket term for many practical reliability enablers
- •Goal: tools/frameworks to build reliable agents fast and easily
- •Today’s agent development is too low-level and brittle (assembly-like)
- •Work across stack: underlying models plus other tooling layers
- 22:04 – 24:31
A 1-year vs 5-year view: from basic workflow bots to personalized natural-language programming
They forecast near-term adoption in workflow automation (email triage, scheduling) as reliability improves. Longer term, they envision highly personalized agents that users can specify in natural language—effectively making everyone capable of “programming” their computers with intent.
- •Near-term: workflows that ‘should already exist’ start working reliably
- •Long-term: more general, robust, individualized agents per user needs
- •Framing: dev tooling for a world where everyone can ‘program’ via language
- •Agents as a natural-language programming layer atop computers
- •Goal: flexible, user-specified interaction patterns and workflows
- 24:31 – 26:15
Capital allocation and compute: small teams leveraged by heavy GPU investment
Elad asks about the $200M raise and how Imbue will deploy capital. Josh emphasizes a preference for a small, cohesive team and using compute to create leverage—citing internal agentic tooling like hyperparameter optimization that saves researcher time while consuming significant compute.
- •A significant portion of funding directed to compute
- •Strategic choice: remain small rather than scale headcount massively
- •Compute-as-leverage: internal agents automate research and ops processes
- •Example: hyperparameter optimization agent runs overnight to tune experiments
- •High compute per person enables training and iteration with a small staff
- 26:15 – 28:06
Do you need 5,000+ GPUs? Efficiency via data, training stability, and tooling
Sarah raises the belief that competing on state-of-the-art reasoning requires huge GPU clusters. They respond that Imbue has substantial compute, but argue that efficiency gains—better data, stable training runs, and improved tooling—may matter more than just scaling runs ever larger.
- •Imbue claims sufficient compute to train models at the high end of today’s scale
- •Questioning whether the biggest possible training run is the best use of resources
- •Efficiency drivers: better data utilization and improved training stability
- •Tooling/monitoring reduces reruns and wasted compute from divergence
- •Data quality/selection seen as large and underexplored leverage
- 28:06 – 32:48
Why coding remains the wedge: action interfaces, compounding leverage, and better software
They return to coding as a focus area: easier evaluation, direct connection to reasoning, and a pathway to agents that take action via integrations. As coding agents improve, they foresee compounding productivity, improved code quality (tests, security, refactors), and more customized software and interfaces for everyone.
- •Reasons for code focus: evaluation, reasoning, and accelerating their own development
- •Incremental compounding improvements (1% daily) rather than overnight ‘FOOM’
- •Turning compute into robust code changes company bottlenecks and scale dynamics
- •Agents improving software quality: tests, security audits, refactoring, linting
- •Future: abundant custom interfaces and personalized tooling built on-demand
