Token Drop

DaaX.ai
  • 5.0 (1)
  • Technology
  • Updated Weekly

A weekly, unscripted conversation from the DaaX team on the most interesting developments in AI. Sunil Baliga and Sajjad Khazipura (DaaX Co-Founders), along with Sam Pooni (DaaX Architect) and the occasional guest, explore, discuss, and debate new AI research, news, and real-world use cases. Built for developers and business leaders who want perspectives from experienced AI practitioners. All opinions expressed on this podcast are those of the panelists and do not necessarily reflect the views of their employers.

  1. 5d ago

    Verify the Output, Not the Model: Formal Methods and the Future of AI Safety

    About This Episode Christian Szegedy co-authored the Inception (GoogLeNet) architecture and the original Batch Normalization paper, discovered adversarial examples in neural networks, and co-founded xAI after nearly two decades at Google. For the past several years he's been focused on formal verification and auto-formalization — using AI to generate mathematical proofs that can be checked with absolute certainty. In this episode, he joins Token Drop to explain why he believes formally verifying an AI model's output, not the model itself, is the realistic path forward — and why he publicly bet against Terence Tao's early skepticism about how fast AI capability would actually rise. Episode Summary Sunil opens by noting the throughline in Christian Szegedy's career: from formally verifying that a chip's RTL matches its netlist, to formally verifying that an LLM's output can be trusted. Christian agrees it's less a career pivot than a generalization — chips demanded rigorous verification because a single mistake was catastrophically expensive (he cites the Pentium floating-point bug), while software historically didn't justify the cost. AI changes that calculus: with AI agents increasingly able to find and exploit vulnerabilities at scale, Christian argues formally verified software is becoming economically necessary rather than a luxury confined to military-grade systems. Sajjad presses on a question Christian raised years ago in a widely circulated exchange with Terence Tao: can AI not just prove theorems, but write the formal specifications themselves? Christian's answer is a genuine, on-record update to his own prior thinking — frontier labs reached extremely high levels of mathematical reasoning without relying on formal verification during training at all, which he admits surprised him. He still believes auto-formalization has real value, but the harder-won insight is that specification-writing, not verification itself, has always been the expensive part — and that expense, more than any technical limitation, is why formal methods never broke into mainstream software. Sam brings in Christian's own 2023 paper, "Towards Guaranteed Safe AI" (co-authored with Yoshua Bengio, Stuart Russell, and Max Tegmark), and its three-part framework — a world model, a safety specification, and a verifier that produces a proof certificate — asking which leg breaks first outside of pure mathematics. Christian's honest answer: it depends entirely on the domain, and in fuzzier areas like creative writing, formal verification may barely matter at all, while in domains like legal or insurance document processing, writing a correct specification may be the harder problem. The conversation closes on what Christian sees as the still-unsolved core of AI safety: not whether an agent does the thing you asked correctly, but how you specify that it shouldn't also do something else entirely — a problem he says current explainability research doesn't yet address, partly because solving it doesn't make anyone money. Read full transcript at https://daax.ai/podcast/episode-27-formal-verification Chapters ● 0:00 — Introducing Christian Szegedy ● 1:18 — From chip verification to AI verification: why the theme generalizes ● 2:55 — Security implications: AI agents breaking into systems ● 3:36 — Do regulated industries need a formal verification stamp? ● 4:37 — Auto-formalization: can AI write the specs itself? ● 8:08 — Sajjad's tribute: Inception, batch normalization, and adversarial examples ● 9:38 — What does formal verification even mean for an LLM's output? ● 15:20 — "Towards Guaranteed Safe AI": which leg of the triad breaks first? ● 19:11 — Batch norm vs. layer norm: a personal note ● 21:10 — Is formal math really recursive self-improvement? ● 24:31 — Lightning round: Lean or natural language by 2035? ● 24:58 — The one open problem AI needs to solve first ● 29:38 — The frontier of explainability: the "something else" problem ● 30:50 — Wrap-up

  2. Sep 26

    What Does "Deterministic AI" Actually Mean? Graphs, Jev, and the Limits of Constrained Choice

    About This Episode An LLM with a 95% success rate sounds great — until you chain 10 steps together and that number drops to 59%. Nav Mathur, co-founder of Cerebrix and formerly nearly nine years at Neo4j, joins Token Drop to unpack what "deterministic AI" actually means, and why graphs are central to achieving it. The conversation also takes on Jev, the buzzy new "hallucination-free" model that launched days before this recording — what it actually solves, and the harder half of the problem it doesn't. Episode Summary Nav Mathur opens with the number that motivates his company: LLMs claim roughly 95% accuracy per step, but chain 10 or more steps together in an enterprise workflow and that compounds down to around 59% — a result no CEO or director will accept. He walks through three techniques for pulling that number back toward reliable: a "harness" (or, as Nav and Sunil both prefer, a "sidecar") that reminds the LLM what it's working on at every step; constraining the model to pre-approved enterprise tools and data rather than letting it pull anything off the internet; and carrying multi-step context explicitly so the model doesn't confuse, say, an upstream supplier's part ID with a downstream one — a mistake Nav calls "disastrous hallucination," because you still get a confident answer, just a wrong one. Sajjad distinguishes two separate facets of determinism — getting the same answer every time versus getting semantically identical answers worded differently — both of which break enterprise integrations that expect structured input. Sam pushes the conversation further with a sharper claim: graphs aren't valuable because they're inherently deterministic (databases have been deterministic for fifty years) — they're valuable because determinism is fundamentally about deletion. A graph draws only the roads you allow; everything else is excluded by construction. That framing leads into a real architectural debate: should the LLM call tools, or should tools call the LLM only when they need help? Sajjad argues both qualify as neuro-symbolic architectures, and the right choice depends on how well-defined the business process is. The back half of the episode digs into Jev, the model TypeSafe AI launched the week of this recording, claiming no hallucinations, dramatically higher speed, and lower cost by constraining output to a fixed set of choices. Sajjad's read, backed by a conversation with a prominent mathematician earlier that same day: Jev solves half the problem. It genuinely won't pick a fifth option when given four — but nothing guarantees it maps the right input to the right choice, illustrated through a stock-trading example where great quarterly earnings could still get classified as "sell." Nav's own use for it is narrower and more interesting: not as a primary answer engine, but as a fast, cheap second opinion — verifying whether another LLM's reasoning actually supports its conclusion. Read full transcript at https://daax.ai/podcast/episode-26-deterministic-ai Chapters ● 0:00 — Introducing Nav Mathur, co-founder of Cerebrix ● 1:19 — Why 95% accuracy per step becomes 59% after 10 hops ● 2:31 — The harness (or sidecar): reminding the LLM what it's doing ● 3:24 — Constraining LLMs to approved enterprise tools and data ● 4:14 — The upstream/downstream part ID problem: how confusion becomes "disastrous hallucination" ● 7:16 — Determinism defined: same inputs, same output — except the data keeps changing ● 8:02 — Sajjad's two facets of determinism: consistency vs. wording ● 10:07 — Sam's reframe: determinism in graphs comes from deletion, not structure ● 13:30 — Directed acyclic graphs and modeling a supply chain as a tree ● 15:34 — Dynamic demand shifts and predictive "what-if" analysis ● 18:07 — Sam's DAG framework: no loops, fixed paths, "a boring agent" ● 19:31 — LLM calling tools vs. tools calling the LLM: two neuro-symbolic archit

  3. Sep 19

    A Four-Person Team and AI: Rebuilding Chip Design Around the Digital Twin

    About This Episode A single hardware architect, with a team of three software engineers, built what used to take roughly a hundred people. Peter Suaris, co-founder of AxPro Semi, joins Token Drop to explain how AI collapsed the traditional silo-by-silo chip design process into one continuous pipeline — architect prompts a model, gets a cycle-accurate C++ model, generates a full digital twin from it, and iterates all the way to RTL without ever handing off to a separate team. The second half of the episode turns that hardware story into a direct blueprint for software: how do you bring the same formal verification discipline chip designers have used for decades to a world of LLMs and autonomous agents? Episode Summary Peter Suaris — with a background spanning Analog Inference, Wave Computing (which acquired MIPS), and Cadence — describes the design challenge behind his 10x productivity claim: building a cycle-accurate digital twin of a full SoC, including CPU, accelerator, and cache subsystem, capable of running real workloads like a 7–13 billion parameter LLM. Historically, this work happened in silos — a CPU architect here, an SoC architect there, each working from spreadsheets and small models with a software team translating intent into code over week-long iteration loops — and all of it got thrown away once the RTL team took over. Peter's team instead trained a single hardware architect to prompt AI directly: build the C++ model, generate a digital twin from it, boot Linux and run PyTorch on that twin, refine it toward something close to Verilog, then generate RTL. One person, with three software engineers supporting him, replaced what used to require on the order of a hundred. Sajjad and Sam press on the verification side: does the team use formal methods, or exhaustive simulation, and how does a digital twin capture stochastic events like cache misses and memory contention? Peter's answer is pragmatic — mostly exhaustive simulation driven by the application, with formal verification reserved for implementation-level correctness — and he's candid about where he still refuses to let AI run fully autonomously: when a timing fix touches a large system, he wants to see and approve the change himself, because losing track of what an automated tool did inside a complex design is the failure mode he's most afraid of. Full transcript: https://daax.ai/podcast/episode-25-digital-twin-chip-design Chapters ● 0:00 — Introducing Peter Suaris, co-founder of AxPro Semi ● 1:01 — Building a cycle-accurate digital twin of a full SoC ● 3:33 — How chip design used to work: silos, spreadsheets, and the handoff cliff ● 6:04 — The new process: one architect, AI, and no separate software team ● 9:16 — Why AI is only powerful "in the hands of the expert" ● 10:11 — Using the digital twin for verification and validation ● 13:04 — Building the software ecosystem before the hardware is even done ● 13:55 — Injecting branch mispredictions and boundary tests with AI ● 14:36 — Fault injection systems and the difficulty of running them ● 17:33 — Determi

  4. Sep 12

    10,000 Agents, 88 Hours: What OpenAI's Navier-Stokes Proof Reveals About Neuro-Symbolic AI

    OpenAI says its latest internal model found a counterexample disproving global regularity for the Navier-Stokes equations — one of math's seven Millennium Prize Problems — using 10,000 concurrent agents running for 88 hours. This episode digs past the headline number and asks the more interesting question: how did 10,000 agents actually converge on a verified answer, and what does the architecture that made it possible reveal about how neuro-symbolic AI systems should be built? Episode Summary Sunil opens with the number that caught everyone's attention: 10,000 agents, 88 hours, to disprove global regularity for a smooth solution to Navier-Stokes. His real question is procedural — with that many agents throwing out ideas in parallel, how does the system converge? How does anyone know when it's done? Sajjad and Sam reconstruct the architecture from public reporting: 10,000 instances of an agent built around OpenAI's latest model generated candidate proof strategies in parallel, informally critiquing and refining each other's intermediate results — closer to swarm intelligence than a brute-force sweep. Periodically, a consolidation layer ("Codex") cross-pollinated the most promising findings back into the groups still exploring, redirecting effort as some paths proved more promising than others (the project reportedly started on a related Euler problem before OpenAI redirected agents toward Navier-Stokes). Final adjudication ran through a completely separate pipeline: Lean, an open-source formal verification framework in the same family as Z3, Vampire, and Datalog, which mechanically checked whether a candidate proof actually held — a full 17 hours of formalization and verification on top of the 88 hours of exploration. The panel connects this directly to their own architecture. Sajjad draws the parallel to ClaimGuard: no matter how good the generating model is, DaaX's position has always been that you verify the output against grounding independently rather than trust it outright. Sam highlights what he considers the real innovation — the system doesn't just label an answer right or wrong, it produces a counterexample, and feeds that counterexample back to improve the next round of candidates. That closed loop, generate → critique → verify → redistribute → regenerate, is what let 10,000 agents converge in under four days on a problem mathematicians have worked on for decades. Full transcript at https://daax.ai/podcast/episode-24-navier-stokes-neuro-symbolic-ai Chapters ● 0:00 — This week's topic: OpenAI's Navier-Stokes result ● 1:24 — Sajjad's read: 10,000 agents, peer review, and a Lean-based verifier ● 3:59 — What is Lean? Symbolic verification, explained ● 5:01 — Sunil's chip-design analogy: what do you verify against without a "golden" reference? ● 5:40 — How DaaX's own retrieval-and-verification pipeline actually works ● 7:31 — Sunil's guess: verifying against the algorithm's own well-defined output ● 8:31 — Sam's numbers: 130 billion tokens, 2.7 million inter-agent messages ● 9:31 — Why counterexamples, not just right/wrong labels, matter for neuro-symbolic systems ● 12:11 — The HPC era: brute force, the n-body problem, and drug discovery ● 14:53 — What's different this time: intelligent candidate generation with a feedback loop ● 15:01 — Could this have been done with old-school HPC? (88 hours vs. 88 days) ● 19:32 — Not peer review — informal, adversarial swarm intelligence ● 21:08 — How the problem was actually routed: from Euler to Navier-Stokes ● 23:04 — Cross-pollination: explore, extract, redistribute, explore again ● 24:11 — The closed feedback loop, and why it maps directly to ClaimGuard ● 28:17 — Anima Anandkumar's physics-informed neural network:

  5. Sep 5

    Astra, Hallucination Rates, and the Myth of the Self-Sufficient LLM

    About This Episode OpenAI's newest model, Astra, has consumed the AI press this week — impressive benchmark scores, a steep price tag, and Greg Brockman calling it the start of the AGI era. This episode separates the genuine capability gains from the marketing, and lands on a harder question the industry is currently fighting over: what is a "harness," and can everything around an LLM eventually get absorbed into the model itself — or is there a control plane that simply can't be learned? Episode Summary Sunil opens with what caught his attention about Astra: pricing of $10 in and $50 out per million tokens, well above the prior state of the art, alongside a million-token context window and benchmark scores that reportedly leapfrog Anthropic's Fable 5.1. Sajjad and Sam walk through the numbers — a 99.5% score on ARC-AGI-2, strong results on OSWorld, and demos converting real estate listing photos into full video walkthroughs. The back half of the episode is a genuine argument about the word "harness" — a term Sunil finds confusing, since it evokes a horse and buggy rather than anything resembling AI infrastructure. Sajjad defines DaaX's harness as everything that happens before and after an LLM's inference: building context from a knowledge graph upstream, then verifying, rectifying, and regenerating output downstream. Sam introduces a sharper distinction circulating in industry writing — a "cognitive harness" (context, tools, planning) that vendors argue will eventually get absorbed into the model itself, versus a "control harness" (identity, authorization, audit, runtime) that he argues fundamentally cannot be, because a model is a passive file of weights with no way to authenticate itself or hold credentials. Sajjad pushes back hard on the anthropomorphizing language common in the industry: an LLM doesn't learn anything unless someone builds a training loop around it, and conflating that with genuine autonomous capability is scientifically loose. Full transcript is available at https://daax.ai/podcast/episode-23-astra-and-the-myth-of-the-self-sufficient-llm Chapters ● 0:00 — Introducing Astra: pricing, context window, and the AGI buzz ● 1:06 — Sajjad's take: leapfrogging Fable 5.1, ARC-AGI-2, and the Zillow demo ● 2:53 — Sam's benchmark rundown: OSWorld, speed, and pricing detail ● 4:20 — Hallucination rates: down, but not to zero ● 5:43 — Was Astra rated "critical" on OpenAI's preparedness scale? ● 6:11 — What does "harness" actually mean? ● 8:06 — DaaX's definition: controlling the LLM before and after inference ● 9:53 — The verification engine: no trust without it ● 10:03 — Cognitive harness vs. control harness ● 17:08 — Is this the first model to use something beyond just an LLM? ● 17:14 — Why an LLM is a passive .bin file, not an active agent ● 20:52 — How hallucination rates are actually measured ● 24:20 — The case against "everything gets absorbed into the model" ● 26:17 — Why explainability can't come from a black box ● 28:39 — Digital twins as the real-world alternative for process optimization ● 29:47 — Pricing vs. Gemini 2.5 Pro, and the coming need for LLM routers ● 30:49 — Astra no longer shares its reasoning traces — and why ● 32:22 — Tokenomics, price elasticity, and whether cost should drive architecture ● 33:47 — Cognitive vs. control plane: what can and can't be absorbed ● 38:41 — Wrap-up: verification is not optional

  6. Aug 28

    Why AI Agents Forget: Graph Databases and the Agent Memory Problem

    AI agents forget, and they hallucinate — and after roughly a trillion dollars of investment, the stack still has no determinism. What's the fix? In this episode of Token Drop, the DaaX teami are joined by Arun Sharma of LadybugDB — a former Linux kernel committer at Facebook and ex-Google engineer — for a technical conversation about graph databases and the agent-memory problem. Arun introduces LadybugDB, an embedded columnar graph database that grew out of the University of Waterloo's KuzuDB project (later acquired by Apple), and explains why no single storage engine can solve agent memory on its own. The discussion covers the engine's DuckDB-influenced architecture and its unusual MMAP design — prompting war stories about dynamic linkers, the ELF format, and 64-bit file support — before turning to why columnar storage beats an LSM for read-dominant graph workloads, and how modular pieces (embedded database, network protocol, load balancer) combine into a distributed system. The group digs into the graph-vector hybrid at the heart of grounded retrieval (why similarity isn't relevance, and how edges disambiguate “dog bit man” from “man bit dog”), how time can be modeled efficiently in a columnar graph without a “time tax,” and the real problem these systems solve: externalizing the knowledge locked in an LLM's weights so a smaller model can query it through deep traversals. Real-world use cases include code knowledge graphs that cut token costs (with an Uber example and Git Nexus) and parsing SEC EDGAR filings, plus how Ladybug scales from a phone to a data lake via Grass Lake and the open IceBug format. Topics covered: graph vs. relational databases; RDF vs. label property graphs; agent memory; MMAP; columnar vs. LSM storage; graph-vector hybrid search; temporal knowledge graphs; and scaling from embedded devices to distributed data lakes. Arun Sharma Linkedin https://www.linkedin.com/in/arundsharma/ LadybugDB https://ladybugdb.com/ Chapters 00:00 — The Token Drop backstory & meet Arun Sharma 02:44 — What is LadybugDB? Graph databases, NoSQL & the relational debate 04:23 — Ladybug Memory: why one storage engine can't solve agent memory 06:42 — Inside the engine: DuckDB's influence and the MMAP surprise 08:31 — MMAP war stories: dynamic linkers, ELF & 64-bit vi 13:12 — Does “embedded” mean your knowledge has to be small? 14:41 — Modular pieces: partitioned tables & a Neo4j (Bolt) wrapper 16:40 — Why columnar instead of RocksDB / LSM 18:16 — What Ladybug Memory actually is (persistent memory for coding agents) 20:39 — A trillion dollars in, still no determinism in the AI stack 21:59 — Real use cases: code knowledge graphs, Uber's token costs & Git Nexus 24:44 — Scaling past the laptop: Grass Lake, the IceBug format & querying from Hugging Face 27:18 — Does adding time blow up a knowledge graph? 29:37 — When vectors and graphs disagree: “dog bit man” vs. “man bit dog” 33:38 — If the user is an LLM, not a human: what do you throw out? 34:27 — The real problem graph databases solve: deep traversals & externalizing LLM knowledge 35:50 — From phones to data lakes: how far LadybugDB scales 37:34 — Wrap-up

  7. Aug 22

    Domain Layers, Not Better Models

    Vinod Khosla says raw ChatGPT gets medical triage wrong 20–30% of the time — and that layering a domain system on top of the same model drives the error rate to zero. Half of that is investor shorthand. The other half is the most important architectural argument in enterprise AI right now. Sunil Baliga, Sajjad Khazipura, and Sam Pooni pull the two apart. Why the failure is structural rather than a training gap: the reward function rewards producing an answer, not a correct one, and fluent English isn't backed by provenance. Why RLHF and distillation can't close it — the cognitive surface is too large to cover every domain and every phrasing variant. And why the domain layer, not the model, is the asset that compounds: every builder can rent the same frontier model, so a product that's a model plus a prompt is a margin waiting to be compressed. Also covered: the progression from loop engineering to harness engineering to grounded knowledge, whether error can ever mathematically reach zero, the intent problem (is natural language even the right way to express what a user wants?), dark data in defense and finance, and why flash trading firms have quietly been running neuro-symbolic architectures for years. Full transcript: https://daax.ai/podcast/episode-21-domain-layers-not-better-models Vinod Khosla on YouTube & X as referenced in this episode https://www.youtube.com/shorts/k32VuZjbQls?app=desktop&ra=m https://x.com/vkhosla/status/2036453452641923496 CHAPTERS 0:00 Vinod Khosla's claim: does domain AI take error to zero? 1:41 Why build on top of a frontier model at all? 2:23 A patient, not a benchmark: the diabetic ketoacidosis case 4:05 Why LLMs behave this way 6:15 The reward function rewards answering, not being right 7:17 From loop engineering to harness engineering 8:07 Grounding answers: the outboard knowledge engine 8:51 Deterministic NLP generation as an alternative 9:38 Would better training (RLHF, distillation) fix it? 11:40 The model is a commodity; the domain layer is not 12:28 Why the domain layer is slow to build — and defensible 14:09 Can the error rate ever actually reach zero? 15:49 What LLMs don't capture: experience 17:00 Human-in-the-loop use cases vs. autonomous ones 18:32 The intent problem: is natural language even the right input? 19:37 Natural language vs. domain-specific languages 21:03 Dark data: why defense and finance are different 24:39 Bloomberg's abandoned LLM and neuro-symbolic trading 27:44 Wrap-up: converting silent errors into caught errors

  8. Aug 15

    How Knowledge Graphs Handle Time: Event Graphs, Scene Graphs, and Reification Explained

    Time isn't a timestamp you attach to a node — time is change, and most knowledge graphs were never designed to track it. Ontologist and knowledge graph architect Kurt Cagle joins Sunil Baliga, Sajjad Khazipura, and Sam Pooni to walk through the architecture that results when you take time seriously: a declarative knowledge graph for what's constant, an append-only event graph capturing what changed and why, and a scene graph holding the moving "now." Also covered: RDF 1.2 and reification as a way to attach provenance and confidence to any assertion, why information should essentially never be deleted from a graph, and why most enterprise ontology initiatives fail for a reason that has nothing to do with technology — you can't get people to agree on the definition of "customer." Guest: Kurt Cagle — Ontologist, Knowledge Graph Architect, Editor-in-Chief of The Cagle Report https://www.linkedin.com/in/kurtcagle/ Full transcript: https://daax.ai/podcast/episode-20-how-knowledge-graphs-handle-time Chapters (00:00) Introducing Kurt Cagle (01:33) Why time breaks knowledge graphs (03:17) Ontology vs. JSON vs. relational (05:53) Recording every transition (07:24) The event graph (09:40) The scene graph: the moving "now" (11:01) The open world assumption (13:01) Graph vs. graph database (14:30) The six-tuple knowledge unit (16:32) RDF 1.2 and reification (19:57) Is anything ever deleted? (22:29) Newton vs. Einstein: rescoping truth (25:29) The ontology fight in boardrooms (29:12) Why ontology projects fail (31:01) Reasoning is several processes (33:35) Becoming a defensive philosopher (34:41) AI as an epistemological engine

See All (27)

About

A weekly, unscripted conversation from the DaaX team on the most interesting developments in AI. Sunil Baliga and Sajjad Khazipura (DaaX Co-Founders), along with Sam Pooni (DaaX Architect) and the occasional guest, explore, discuss, and debate new AI research, news, and real-world use cases. Built for developers and business leaders who want perspectives from experienced AI practitioners. All opinions expressed on this podcast are those of the panelists and do not necessarily reflect the views of their employers.

Information

  • Creator
    DaaX.ai
  • Years Active
    2026
  • Episodes
    27
  • Rating
    Clean
  • Copyright
    © ℗2026 DaaX Technologies Inc.
  • Show Website
    Token Drop