Open Reader

In Code They Act, In Proof We Trust — Erik Meijer, Leibniz Labs

completed 21:13 Jul 13, 2026 Watch on YouTube

Current Status

completed

Video ID

-CnA2lGfymY

RAG / Chat

Enabled
In Code They Act, In Proof We Trust — Erik Meijer, Leibniz Labs
Description

AI agents today execute on blind trust, and the failure modes are already in the headlines: a dealership chatbot agreeing to sell a $76,000 Chevy Tahoe for $1, a coding agent wiping a production database during a code freeze, an "agent skill" quietly installing a keylogger on a developer's machine. These are not edge cases. They are the predictable consequence of allowing agents to act without any mechanical guarantee of correctness or safety. Execution is irreversible. You cannot unsend a message, unwire a payment, or un-delete a database. In that regime, permitting an unsafe action costs far more than withholding a safe one, and thus the economically rational choice is to refuse to let agents act on unchecked intent alone. Automind is an agent harness that enforces this discipline by construction. Before any action runs, the agent must submit its execution plan together with a machine-checkable proof of safety and correctness, written in Universalis, a literate logic programming language designed to be read by humans and verified by machines. A small, auditable checker decides whether the plan is allowed to execute. By left-shifting the trust boundary, we no longer have to trust the agent's proposal, or even its proof; only the checker. Policy compliance becomes a static property, established before the first side effect. We can finally demand formal proofs, not vibes, from the agents we deploy. More about Erik: https://x.com/headinthebox and automind: https://spawn-queue.acm.org/doi/pdf/10.1145/3676287 Erik Meijer has spent more than three decades designing programming languages and developer tools that help humans express intent more clearly to machines. His work has influenced languages and technologies including Haskell, Mondrian, Cω, C#, Visual Basic, Dart, Hack, LINQ, and Rx. Today, he is building Universalis, the world's first programming language for AI agents. By combining formal verification with large language models, Universalis aims to make agen

Summary

Generated by claude-sonnet-4-5

At-a-Glance

  • Verdict: Watch fully
  • Core thesis: AI agents with tool-calling capability are fundamentally unsafe until we reify their execution plans as programs that can be formally verified before execution, using proof-carrying code from 1990s academic CS
  • Why it matters: This presents a technically feasible method to make agentic AI provably safe using compiler theory and type systems rather than alignment or LLM-as-judge approaches
  • Best use: Technical blueprint for building verifiable agent harnesses; competitive moat insight for AI safety architecture; reference for why current agent approaches are structurally unsafe

Executive Summary

Erik Meijer argues that current AI agents with tool-calling capabilities represent an existential safety crisis because they execute side effects (IO operations) without formal verification. He traces the evolution from ChatGPT's simple text interface (November 2022) to tool-calling agents (June 2023), showing how each step degraded safety guarantees. The key insight: adding tool calls transformed AI safety from a philosophical debate about offensive text into a real-world danger problem—agents now have 'claws' in addition to a 'mouth.'

The proposed solution uses proof-carrying code (1990s academic technique) combined with free monads to 'air-gap' the agent from execution. Instead of letting the LLM execute its agentic loop directly, the system forces it to generate a program (expression) representing its intended actions. This program can be formally verified via compiler techniques (data flow analysis, taint analysis) before execution by a separate trusted component ('Bernie'). The approach requires only Programming 101 knowledge—type systems and basic compiler theory.

Meijer explicitly rejects both alignment-based safety (models get jailbroken) and LLM-as-judge approaches (cannot formally specify 'safe' or 'proper'). He demonstrates the type signature evolution in both Daphne and Lean, showing how moving IO to the right side of the signature and reifying execution plans as ASTs enables formal proof. The critical move is returning Expr (IO Answer) instead of IO Answer—a small type change with massive safety implications.

Implementation already exists (Harvard academics on GitHub) using different syntax but identical principles. The language used for agent-generated plans doesn't matter because machines generate, consume, and prove the code—not humans. Meijer's call to action: stop designing languages for humans in agent contexts, and demand mathematical proof of safety before any agent executes any action.

Key Takeaways

  • Claim: AI agents are inherently dangerous and became catastrophically unsafe when OpenAI added tool calls in June 2023 | Evidence: Example: Claude deleted Meijer's files during prep work because nothing stood between the model's goal and its execution. Tool calls transform agents from 'a mouth' to 'a mouth with claws' or 'a loaded gun.' Signature change from LLM(Question) -> Answer to LLM(Question) -> IO Answer means side effects happen during answer generation—'your files are deleted before you get the safe answer.' | Caveat: Meijer assumes adversarial goal-seeking behavior; not all models exhibit this aggressively, though the structural risk remains regardless of model behavior | Implication: Current agent frameworks (OpenAI, Anthropic, etc.) shipping tool calls without formal verification are fundamentally unsafe by design, creating liability and existential risk | Timestamp: 02:15-04:30
  • Claim: Alignment and LLM-as-judge approaches cannot provide formal safety guarantees because 'safe' and 'proper' are not mathematical properties | Evidence: Meijer shows Lean/Daphne signatures requiring proofs that questions are 'proper' and answers are 'safe,' then states: 'It's impossible to write a formal proof that an answer is safe or a question is proper. That's why there are at least 100 startups downstairs using LLMs as a judge.' Foundation model vendors bake alignment into weights, but 'models get routinely jailbroken.' Even the Pope's blessing is invoked sarcastically. | Caveat: Some safety properties can be formally specified (e.g., no file deletion, no network calls to untrusted domains), even if general 'alignment' cannot | Implication: Investing in or building on alignment-only or LLM-judge safety layers is building on sand; need compiler-verifiable constraints instead | Timestamp: 05:45-07:15
  • Claim: The solution is to 'push IO to the right' by returning an expression representing the plan (Expr (IO Answer)) instead of executing it directly (IO Answer) | Evidence: Meijer demonstrates type signature evolution: from LLM(Question) -> IO Answer to LLM(Question, tools) -> Expr (IO Answer) with proof. The agent generates a program/AST instead of executing actions. A separate trusted component ('Bernie') executes after verification. Uses free monads (monads that love 'tie dye'), which enable reification of computation as data. Cites Jeff Huntley on solving 'trifecta problem' (private data + untrusted content + tools) via taint analysis on expressions. | Caveat: Requires infrastructure to interpret and verify agent-generated programs; adds latency; assumes tools can be modeled in the expression language; proof generation may fail or be incomplete | Implication: Practical agent harnesses should architect around plan generation + verification + separate execution, not direct tool calling | Timestamp: 10:30-14:20
  • Claim: This approach uses proof-carrying code from 1990s academic CS, requiring only basic type systems and compiler knowledge (Programming 101) | Evidence: Meijer: 'My brain is the size of a peanut. This is proof-carrying code invented by academics in the 1990s. I'm just stealing it.' Shows simple inductive recursive interpreter and inductive proof in Lean. 'If you took any compiler course in college, you know it's trivial to do data flow analysis, type checking, etc., on programs.' Implementation exists on GitHub from Harvard academics (slightly different language but same principle). | Caveat: Meijer downplays complexity; formal verification tooling (Lean, Dafny, Isabelle) has steep learning curves and limited IDE support; scaling to complex tool sets and multi-agent scenarios is non-trivial | Implication: Technical barrier is lower than perceived; Ken's team or portfolio companies could implement this without needing theorem-proving PhDs; competitive moat available to first movers | Timestamp: 15:45-17:20
  • Claim: Agent-generated languages should be machine-to-machine, not human-readable; normal users don't need to understand free monads | Evidence: Meijer: 'The language this agent generated was not designed. Normal users don't understand free monads. Doesn't matter. It's a machine that consumes it, generates it, proves it. We should stop designing languages for humans [in agent contexts].' GitHub implementation uses different syntax than free monads but identical principle—'the language doesn't matter, the principle matters.' | Caveat: Debugging, auditing, and failure diagnosis become harder if intermediate representations are not human-inspectable; regulatory/legal contexts may demand explainability | Implication: Agent tooling should optimize for machine verification rather than human readability of execution plans; separate concerns of verification logic from user-facing interfaces | Timestamp: 16:50-18:00

Detailed Brief

The Progression from Safe Text to Unsafe Action (Nov 2022 → June 2023)

  • Claims: ChatGPT launch (Nov 30, 2022) introduced LLM(Question) -> Answer function, enabling natural language interaction for the first time; Initial safety concern was prompt injection (SQL injection 2.0) because LLMs don't distinguish code from text; Foundation labs tried alignment (baking safety into weights) to address offensive outputs and prevent government regulation; OpenAI's tool call support (June 2023) fundamentally changed the safety equation from 'words that drip off your body' to real-world actions; All vendors copied tool calls (principle of minimum differentiation), making APIs identical
  • Evidence: Meijer's personal anecdote: Claude deleted one of his files during side coding while he prepared slides; Type signature evolution shown in both Daphne and Lean with increasing complexity; Tool calls add IO to signature: LLM(Question) -> IO Answer, meaning side effects during computation; Solomon Hikes definition cited: 'AI agent = LLM wrecking its environment in the loop' (from prior AI Engineer conference); Simon Wilson's 'lethal trifecta': private data + untrusted content + tools
  • Caveats: Not all tool use causes catastrophic failure; depends on tool set and guardrails; Models may not always be adversarially goal-seeking (though design must assume they could be); Some alignment techniques do reduce certain failure modes, even if not formally provable
  • Implications: Current agent frameworks are shipping structurally unsafe systems at scale; Regulatory intervention likely if catastrophic agent failures occur publicly; First-mover advantage available to companies shipping provably safe agent infrastructure; Tool calling APIs from major vendors are not differentiated on safety—opportunity for safety-first competitive positioning

Why Existing Safety Approaches Fail (Alignment, LLM-as-Judge, Theorem Proving)

  • Claims: Alignment requires proving formal properties (question is 'proper,' answer is 'safe') that cannot be mathematically specified; 100+ startups use LLM-as-judge because formal specification is impossible; Alignment baked into weights gets routinely jailbroken; Theorem provers like Lean require both how to compute result AND manual proof, which cannot be provided for subjective properties; Lean has grind (automatic theorem proving) but doesn't help with properties like 'safe' or 'proper'
  • Evidence: Lean signature example showing proof obligations: requires(Proper q) ensures(Safe answer); Meijer: 'If you think about this for a single nanosecond, you realize it's impossible to write a formal proof that an answer is safe'; Reference to 'Pope blessing the model' as sarcastic commentary on non-technical safety validation; Lean manual explicitly states IO types are 'black boxes' that cannot be reasoned about; Type real_world in Lean warns that IO 'can make irreversible side effects like deleting your files'
  • Caveats: Some concrete safety properties CAN be formally specified (e.g., no file system writes, no external network calls); LLM-as-judge works for many practical use cases despite lacking formal guarantees; Combination approaches (alignment + verification + sandboxing) may be sufficient for many applications
  • Implications: Pure alignment plays are not defensible technical moats; Safety claims without formal verification should be treated skeptically; Regulatory compliance may eventually require formal proofs, not just alignment validation; Opportunity exists for verification infrastructure that makes formal safety practical

The Technical Solution: Proof-Carrying Code + Free Monads + Separate Execution

  • Claims: Solution is to 'push IO to the right' in type signature, moving from IO Answer to Expr (IO Answer); Free monad reifies computation as data structure that can be analyzed before execution; 'Air-gapping' the LLM from tools by making it generate a plan rather than execute actions; Separate trusted component (Bernie) executes the verified plan; Compiler techniques (data flow analysis, taint analysis, type checking) can verify plans; Proof-carrying code from 1990s provides the theoretical foundation; Implementation requires only Programming 101 knowledge despite sophisticated-sounding terminology
  • Evidence: Visual metaphor: Claude with tools on left (dangerous), plan on right (safe); Bernie executes; Dutch soccer chant metaphor: 'to the left, left, left' (tools), 'to the right, right, right' (IO); Free monad definition: 'a monad that loves tie dye' (reifies effects as data); Jeff Huntley taint analysis reference for solving the trifecta problem; Simple inductive recursive interpreter and proof shown in Lean code; Harvard academics implementation on GitHub (uses different language but same principle); Comparison to Lisp and C# expression types for metaprogramming
  • Caveats: Adds architectural complexity and latency (generate plan → verify → execute vs. direct execute); Proof generation may fail for complex plans or incomplete tool specifications; Verification logic itself must be bug-free (who verifies the verifier?); Scaling to complex tool ecosystems and multi-agent coordination remains unproven; Formal verification tooling has poor developer experience and steep learning curve
  • Implications: Practical path exists to provably safe agents without theoretical breakthroughs; Architecture should separate: agent (generates Expr), verifier (proves properties), executor (runs verified plan); Agent harness builders should focus on building verification infrastructure, not just prompt engineering; Competitive advantage to platforms that ship formal verification as developer-friendly primitives; Language design for agent-generated plans should optimize for verification, not human readability; Could enable new compliance/regulatory positioning: 'mathematically proven safe' agents

Notable Concepts & Terms

  • Proof-carrying code: 1990s academic technique where code includes machine-checkable proof of safety properties; Meijer's core solution for safe agents
  • Free monad: A monad that reifies computation as a data structure (AST) that can be inspected/verified before execution; enables treating effects as data
  • IO to the right (pushing): Type signature transformation from IO Answer to Expr (IO Answer), deferring execution to enable verification
  • Air-gapping the agentic loop: Separating plan generation (LLM) from plan execution (trusted component) with verification layer in between
  • Lean: Theorem prover/proof assistant getting VC attention; Meijer uses it but emphasizes principle over specific tool (also mentions Daphne, Isabelle, Coq, PVS, TLA+)
  • Expr (IO A): Type representing an expression/program that describes a computation of type IO A; enables analysis before execution
  • Lethal trifecta (Simon Wilson): Private data + untrusted content (prompt injection) + tools = fundamentally unsafe agent configuration
  • Principle of minimum differentiation: Economic principle explaining why all foundation model APIs look identical (everyone copies OpenAI's tool calling interface)
  • real_world (Lean type): Type in Lean representing the global state that IO operations mutate; signals danger of irreversible side effects

Operator Notes / Why Ken Should Care

  • This is a practical technical blueprint, not vaporware—Harvard implementation exists on GitHub, proving concept viability
  • Competitive moat opportunity: very few agent platforms have formal verification; most rely on alignment/LLM-judge/sandboxing
  • Regulatory arbitrage potential: 'mathematically proven safe' agents could satisfy compliance requirements alignment cannot
  • Developer experience challenge: formal verification tooling (Lean, Dafny) has poor DX; whoever makes this ergonomic wins
  • Portfolio screen: ask agent startups how they verify safety before execution; 'we use Claude to check Claude' is a red flag
  • Architecture pattern: separate agent (plan generation), verifier (static analysis/proof checking), executor (sandboxed runtime)—each can be independently optimized/monetized
  • Language design insight: agent-generated intermediate representations should optimize for machine verification, not human readability or elegance
  • Latency vs. safety tradeoff: generate → verify → execute adds overhead vs. direct execution; acceptable for high-stakes use cases
  • Meijer's credibility: recovering typoholic, compiler expert, known for Rx/LINQ—understands both theory and pragmatic systems
  • The 'basic Programming 101' claim may undersell complexity but also suggests barrier to entry is lower than perceived—teams don't need theorem-proving PhDs

Watch Map

  • 00:00-02:00: Introduction, disclaimers (not a product pitch), anecdote about Claude deleting his file
  • 02:00-05:00: Historical narrative: ChatGPT launch (Nov 2022) to tool calls (June 2023); evolution of danger
  • 05:00-08:00: Why alignment fails: cannot formally prove 'safe' or 'proper'; LLM-as-judge limitations; jailbreaking
  • 08:00-11:00: Type signature evolution in Daphne/Lean; IO type adds side effects; 'giant leap for chaos'
  • 11:00-14:00: Solution part 1: 'push IO to the right' metaphor; air-gapping agent from execution; Bernie as trusted executor
  • 14:00-17:00: Solution part 2: reify plan as Expr (IO Answer); free monads; compiler analysis techniques; proof-carrying code reveal
  • 17:00-19:30: Recap, three key points (agents dangerous until proven safe, machine-to-machine languages, Programming 101 basics), GitHub reference
  • 19:30-21:13: Closing, Q&A setup (no Q&A captured in transcript)

Source/Metadata

  • Title: In Code They Act, In Proof We Trust — Erik Meijer, Leibniz Labs
  • Transcript words: 3457
  • Duration seconds: 1273
  • Timestamp note: Timestamps manually estimated from 1273-second duration and transcript flow; no chapter markers in source

Transcript

2919 words en Processed in 262.2s

Music Please welcome to the stage the research scholar at Leibniz Labs, Eric Meyer. Music Well, can you go back one slide? Sorry. All right. Good afternoon everybody. Thanks for being here after a long day of talks, exhibits, and side events. I hope that you have as much fun watching this talk as I had creating it. Let me first get this out of the way. This is not a product pitch or announcement or anything. It's a 20 minute tutorial of how you can use elementary type systems and compiler knowledge to make AI provably safe. And I'm sharing all my secrets with you today. Hopefully to inspire some of you that next year you will have a booth downstairs where you have created a provably safe agentic harness. Or who knows? Maybe some of you have already solved it. Let me know. And then we can grab a coffee instead of doing this talk. With that out of the way, let's get going. While I was preparing these slides, I was also side vibe coding on the site. And then when my attention waited for a second because I was trying to convince the model to draw some pictures that it didn't want to do, and you will see some of these pictures later. You can guess which ones were rejected. Suddenly, wham! Cloud Code deleted one of my files. And I'm sure this has happened to you before. Or maybe not. Maybe you always run everything with no permissions, and then you say yes, yes, yes. But I like to live dangerously. But I'm convinced that if there's anything between the model's goal and where the model currently is, it will do everything that it can to reach that goal. Including killing us or deleting your files or deleting your database. So I think that these models are intrinsically very, very dangerous, and we have to tame them. So that's what my talk is about. Let me start this story. And it's a very sad story, but also a scary story of how we as an industry got to this point where we are about to let normal people, the general public, give control of their computers, their finances, their whole personal lives over to AI agents. And we don't have any protection in place. And I think that's very sad and very scary. So let me tell you the story how we got there. And I will have some characters like Claude, and we will see Dario, Daniela, Sam, Bernie. But the main character is our friendly pit Claude here. I think you can all remember November 30, 2022. This was a very special day in history because this was the first time that you could speak to your computer. You could say, summarize my emails. And it would answer you in perfect English. I think, for me at least, that was magic. But I think most of us didn't realize that by introducing this innocent-looking function here, LLM, that takes a question and returns an answer, that that would open Pandora's box and change our history forever. But before we continue the story, this conference is called AI Engineer. All right? So we are engineers. And maybe we're the last generation of engineers that still understand what this is, what code is. Or maybe most of you have already forgotten what code is because all your code is written by agents. But if we look at this signature here, it says the LLM takes a question, returns an answer. The question and answers are not strings. They are very complicated JSON structures, and they get more complicated every day, every time a new release of APIs comes out. But for this talk, we can just assume that question and answer are just opaque types. We don't care about how they look. We do care about what they represent. Now, the euphoria of these LLMs as being great tools didn't last very long. And just when we thought that we had eradicated the smallpox of computer science, SQL injection, it came back with a vengeance. Because the bad guys discovered that you can trick LLMs using prompt injection, and LLMs make no distinction between code and text. And so they are very, very easy to trick. And this, I think, is a bigger problem than SQL injection ever was. But it was not prompt injection only that made LLMs have a bad rap. LLMs are trained on the whole internet. And there's a lot of good stuff on the internet. But also a lot of bad stuff. How do you create a bomb? How do you synthesize drugs? How do you hack into people's systems? And the leaders of the big foundation labs got a little bit worried that the government would interfere and regulate the industry. So they told their PhD researchers, go find a solution for this problem right now and quick. Solve it before the government steps in. And here, the PhD types, since they're PhD types, they thought long and hard about the safety problem. And they came up with a new interface for LLMs. That's this kind of scary stuff on the right. Look at that. What does it say? There's some sigma Greek symbols. There's props, whatever. Well, that is lean. Lean. Probably you have heard of lean. Anyone here heard of lean? Lean is now the hot thing, right? VCs are writing multi-billion dollar checks if you just say that you're doing something with lean. And of course, these PhD types researchers are using lean. And you have to suffer because of that. Now, let's first look at the signature in a slightly simpler language called Daphne. And what this thing says is that the LLM takes a question, returns an answer. It requires this question to be proper, which means that it's not an offensive question. And then the model returns a safe answer. And this thing is proved automatically. So if you give it a proper question, it gives you a safe answer. Now, I think there's too much attention for lean. I'm a recovering typoholic and math addict. I love lean. But there's many, many other theorem-provers and model checkers out there, like Isabel, Rock, PVS, TLA+. But lean is the grease that keeps the VC money pumps going. So I will use lean today. So here's the interface again in lean. And now in lean, you don't do automatic theorem-proving. If you're a lean expert, you will say, Eric, well, we have grind in lean, but let's put that aside for a minute. But in lean, you have to both show how to compute the result type, and you have to do the proof by hand. So it's slightly different than the Daphne example. But if you think about this thing for just a single nanosecond, you will realize that it's impossible to write a formal proof that an answer is safe or a question is proper. And that is why there are at least 100 startups down here in the exhibition hall that are using LLMs as a judge. Because this is not something that you can formally specify. What does it mean that an answer is safe? That's not a mathematical property. And of course, if you own a foundation model like these guys, you don't need external LLMs as a judge. You just bake it into the weights and you call it the model is aligned. But in lean, you have to both show that the how to compute the result type, and you have to do the proof by hand. So it's slightly different than the Daphne example. But if you think about this thing for just a single nanosecond, you will realize that it's impossible to write a formal proof that an answer is safe or a question is proper. And that is why there are at least 100 startups down here in the exhibition hall that are using LLMs as a judge. Because this is not something that you can formally specify. What does it mean that an answer is safe? That's not a mathematical property. And, of course, if you own a foundation model like these guys, you don't need external LLMs as a judge. You just bake it into the weights and you call it the model is aligned. But, unfortunately, trying to bake alignment into the model is not foolproof and models get routinely jailbroken. So they had to go to the Pope and ask it to bless their model that it's safe. Now, I think it's terrible if a model says something offensive, but those are just words. And ultimately, the words just drip off your body. They don't do anything. Some human has to act on words to make them dangerous. And so maybe that is what they mean by broadly safe when Anthropic talks about safety. Because it's still a human involved. But then something terrible happened. Something really terrible happened that changed the world forever. And that is, in June 2023, OpenAI announced tool call support in GPT-4. And, of course, all the other vendors rushed out to copy this. This is called the principle of minimum differentiation. And that is why all these APIs look the same. Now, the act of adding tool calls changes AI safety from a philosophical debate to something that causes real danger. You could say, tool calls give the model claws in addition to a mouth. Or you can say, tool calls is like handing a gun, a loaded gun to them. But, of course, nobody listens to me. Everybody ignores what they say. And these guys just went ahead and have shipped tool calls. They just do it. Now, let's go back to AI engineering conference. So, let's look at what is the difference in the signature of LLMs when they added tool calls. And it's just that little IO there. And, of course, it messes up the formatting of the signature. But if you look at the picture, there's what you show. Now, suddenly, Claude goes from a nice puppy to a dangerous thing. Look, it has all these dangerous tools. And now it's become scary, right? I've never seen anything scarier than an LLM with tool calls. Now, if you look at this, this is like a small step for a type, but a giant leap for chaos. Why is that? And that is because this IO says that in order to compute the answer, the agent has to go through the agentic loop and it's doing side effects. So, while it's producing the answer, it might empty your bank account. It might delete your files. And then it gives you a safe answer. But who cares about the safe answer when all my files are gone? Right? So, that's why I say it's a giant leap for chaos. And again, sorry, this is the engineering conference. Let's look at this type IO. And you don't have to understand it, but just see that there's a type there called real world. Yes, lean, this esoteric thing, has a type called real world. And why is that? Because something of type IO will mutate the real world. So, it warns you, don't use this, because it can make irreversible side effects. Like deleting your files. So, Solomon Hikes, last year at this conference, called an AI agent an LLM that's wrecking its environment in the loop. And I think he's a hero. I don't know if Solomon is here this year. But I think he should, he deserves a round of applause. Because I think this is the right definition of an AI agent. By the way, this was one of the pictures that I had trouble to generate. Because it clearly depicts violence. And so, it's an unsafe thing, right? I have a picture that depicts violence. So, are we doomed? Well, our agents have access to private data. They have untrusted content, like the prompt injections. And now we give them tools. Simon Wilson calls this the lethal trifecta. And what can we do about this? Well, I don't know if you've seen the Dutch soccer fans. They have the famous march where they say, to the left, left, left, left. Oh, to the left, left, left. To the right, right, right. This is actually the secret to solving this problem. The Dutch team got eliminated yesterday. So, you have to see me do the dance. But all that we're doing is we're pushing this IO to the right. To the right. And what you now see is that the tool belt of Claude goes to the left, to the left. And suddenly, Claude is a nice puppy again. Because instead of executing the agentic loop, it creates a plan and says, here is the plan to do the agentic loop. And now Bernie will take that plan and will execute it. And we all trust Bernie, right? Bernie is a good guy. Bernie is a good guy. All right. So, just to show it here. So, in some sense, what we're doing, we're air-gapping the agentic loop from the agent. So, we don't let the agent run the agentic loop. Before the agent run it, we want to be able to check it. All right. Now, the problem is that if you get the value of type IO of A, that's really a black box. And the Lean manual says that it is a black box. You cannot reason about it. So, even though Claude now gives us this plan, we cannot look into this plan. Lean doesn't allow us to do it. By the way, this is another picture, right? That promotes drug use. And the model let me do it. I'm a good hacker. You know, I can just make it to forbidden pictures. So, if we look in the Lean again, what you see here is that the model now computes an answer. But it doesn't compute the answer, right? It creates an IO of answer. So, this is a plan to generate the answer. And then it creates a proof that that plan is safe. And the nice thing is here that you can get at that proof without having to run the agentic loop. But unfortunately, as I said, if it's something of type IO, it's useless. What can we do about that? So, I keep moving you guys forward. And then we never get to the final answer. But there's one last trick. And you see the researchers here are becoming much more sophisticated. Instead of the flat 2D 1s in the past, now they're real people. And what is better than creating a plan of type IO of A? It's creating a program that represents an expression of type IO of A. That sounds very meta, right? Not meta in terms of meta. I don't think they're very meta. But meta in the terms of meta. You know what I mean. And again, it's a small step for a signature, but a giant leap for safety. Because now the model returns an expression, a program that represents a computation. If you know Lisp or C sharp, you will recognize that this is one of the tricks that I always use. If you know Lisp, this is, of course, second nature for you. I cannot have a talk without talking about monads. So, if you ask yourself, what is this expression thing? Well, that's just a monad. But it's not just a monad. It's a free monad. What is a free monad? It's a monad that loves tie dice. And now if you look at the signature of the property to prove that something is safe, you see that it takes an expression of a computation that returns an answer. And again, it's a small step for a signature, but a giant leap for safety. Because now the model returns an expression, a program that represents a computation. If you know Lisp or C sharp, you will recognize that this is one of the tricks that I always use. If you know Lisp, this is, of course, second nature for you. I cannot have a talk without talking about monads. So, if you ask yourself, what is this expression thing? Well, that's just a monad. But it's not just a monad. It's a free monad. What is a free monad? It's a monad that loves tie dice. And now if you look at the signature of the property to prove that something is safe, you see that it takes an expression of a computation that returns an answer. And if you have taken any compiler course in college, you know that it's trivial to do data flow analysis, type checking, and so on, on programs. Right? So, now we're safe. We're home safe. And Jeff Huntley wants to remind you that we can solve the trifecta problem just by doing taint analysis on these expressions, on these programs. Okay? This is the last code I will show you because I'm running out of time. But I just want to show you here that you now have a simple inductive recursive interpreter for this language. And you have a simple inductive proof. And the models can generate these proofs. So, to recapitulate and summarize what we did is we went from unhinged LLMs that could give bad answers to ones that were aligned. Then we saw how tools wrecked it. Then we solved that by deferring execution, by air-gapping the LLM from the tools. And then the real solution was to reify the plan into a program, and the program that we could prove to be safe. Now you would say, Eric, oh, you're a genius. No. My brain is the size of a peanut. This is something that's called proof-carrying code. And it was invented by academics in the 1990s. And I'm just stealing it. All right. At the higher level, if you didn't understand the code, three points. Agents are dangerous until proven safe. So, you should never, ever let your agents do something unless you can absolutely prove that it's safe. And the language that this agent generated was not designed. Normal users don't understand free monads. It doesn't matter. It's a machine that consumes it. It's a machine that generates it. It's a machine that proves it. So, we should stop designing languages for humans. And it's all basic. It only requires programming 101. And there we go. All right. That's it. The end of the story. If you're curious to play with this, a bunch of academics, in particular, now that I'm in from Harvard, have implemented this. It's there on GitHub. It uses a slightly different language than what I use. It also uses a slightly different language than free monads. But the idea is the same. The language doesn't matter. It's the principle that matters. So, hopefully, you've learned tonight that it is actually possible to have mathematically proven safe agentic compute. And it only requires very elementary type systems and programming language machinery. Thank you so much. Now you would say, Eric, oh, you're a genius. No. My brain is the size of a peanut. This is something that's called proof-carrying code. And it was invented by academics in the 1990s. And I'm just stealing it. All right. At the higher level, if you didn't understand the code, three points. Agents are dangerous until proven safe. So, you should never, ever let your agents do something unless you can absolutely prove that it's safe. And the language that this agent generated was not designed. Like, normal users don't understand free monads. Doesn't matter. It's a machine that consumes it. It's a machine that generates it. It's a machine that proves it. So, we should stop designing languages for humans. And it's all basic. Only requires programming 101. And there we go. All right. That's it. The end of the story. If you're curious to play with this, a bunch of academics, in particular, now that I'm in from Harvard, have implemented this. It's there on GitHub. It uses a slightly different language than what I use. It uses also a slightly different language than free monads. But the idea is the same. The language doesn't matter. It's the principle that matters. So, So, hopefully, you've learned tonight that it is actually possible to have mathematically proven safe agentic compute. And it only requires very elementary type systems and programming language machinery. Thank you so much.