# cloudflare is a neolab — Michelle Chen — session 2026-11-11T17:50:00.000Z → 2026-11-11T18:10:00.000Z

_62 transcript lines · 40 slides_

## Transcript

Our own version of JEV. So JEV launched on September 15. On September 18, just three days later, we started experimenting and we launched our version of JEV, our first experiment of it. And then it took us a week of deliberation to decide, do we actually want to be going into this NeoLab territory? It's completely new to us. We don't know what we need to know. It... You know, are we gonna set the expectation that we wanna be a NeoLab? And are we gonna live up to those expectations? But But we decided to do it. I remember on a Friday evening, we were like Let's just go for it, and we did it. And we ended up training the model over forty eight hours over the weekend, and then we launched it the following week. And so we ended up with a model called Clef. Clef gave power back to the agents to be able to make decisions on their own, so agents LLM reason through for minutes on if it should make this decision or not. You also didn't need to put a human in the loop and be interrupted by, like, a human's sleep schedule when you want your agents to be running twenty four seven. So you can now Dramatically encode, decide, make decisions for your agent to take action on. So these decision models countered LLM models because they were a lot faster, and they were also a lot cheaper as well. And so it actually, as an inference provider, takes a lot of pressure off the LLMs as well, because the LLMs were reserved to work, for meaningful work, whereas the clef and, decision models could be used for fast, intuitive thinking in work. Right? And so we also went Back and thought to ourselves, you know, what else do agents and people use for LLMs for that are overkill? So we came up with decisions and, there must be other workloads out there that are unsuitable for an LLM, both because they are either too expensive or take too long, or maybe that it just would get the answer wrong because the autoregressive nature of an LLM means that it would hallucinate. So we also launched a model three weeks later called Cleric. We actually ended up launching four models in the span of three So I think we did a pretty good job as a new lab. But Cleric is a new model paradigm. So it's completely new, we're calling it an extraction model. But it's a system one model in the sense that it is just as fast and just as cheap, but it is also doing like one forward pass through the user. And the purpose of Cleric is when you're interacting with the world, you're not interacting in perfectly typed JSON objects. Right? Sometimes you're getting an email, a tweet, a Slack message, but those people are not filling out perfect forms for you to extract inputs in out of. So what Claire Does is it can take unstructured input and it can extract, compute, estimate, and forecast values from those inputs. And it gives you back a perfectly typed JSON objects, which means the agents are able to do things with it. So we're kind of giving agents the ability to read read here and take action with Clef as well. And so in code again, you're giving Cleric, you know, typed values from unstructured data. You can pass it in whatever kind of unstructured data, it can also take image input as well. And so you Just tell it to read basically what's in text here, pass it to Clef, decide what to do with this text, and then pass it to an LLM to decide what to do with the agent. And so Cloudflare had to become a NeoLab here. This was our missing bit. We had the infrastructure, we had the compute primitives, we had the data primitives, we had the large models powering the agents, but in order to take advantage of all of that and our infrastructure that we were built on, we had to be a NeoLab and ship these system one models that fit perfectly with our infrastructure. I think one of the more important things is that we're not limited to this. Being a new lab means that we can create what we are missing. Right? It means that we're not, if we're missing a system one model because we're, at risk of it things being closed sourced or regulatory risks or things like that, we can actually create and invent things. So I think being a NeoLab has actually opened a lot of doors for Cloudflare to do more in the AI world. So we went through backwards, we went through a little bit of a history lesson. I wanna go forwards as well. You guys what you guys can be doing with Clef and Clariq. And I'm cognizant that I am at AI Engineer Code Summit. So in a in a room full of developers and engineers, how can you guys leverage Clef and Clariq and system one models in order to better use your workflows? So we'll do a quick demo here. It is in... Let's think you have an agent, you're triaging like a CI build that went wrong, right? Let's say you have 40 tool call... Tools that are available to this agent, you have your PR that went wrong, and then you have your agent Maybe it's running Py durable on a durable object since all of this is built on Cloudflare. So this is the setup here. Tech... Typically what you would do is you would take an LLM, and in the LLM would take a tool... Make a tool call, the tool call would go back to the LLM, the LLM would make another tool call, etcetera, etcetera, until the issue is resolved. So this is like five back and forths with GLM 5.3. You're sending 40 tools every single time, and maybe you're blowing up the context, right? Because you're sending the same kind of inputs back and forth to the LLM. And so What if we augment this with system one models? With system one models, this could look a lot different. And so let's say we want speed, so we pick cleft flash. Cleft flash can actually help you prune your tool list. Maybe it only needs 10 out of the 40 tools that are available. So you only need to pick 10 of those. Then let's say you take Clerik, and you use it to extract the values from the input. So it can get the PR number without reasoning and thinking about it too long. And then let's say you just orchestrate some code here to These API calls, and, you can actually just, you know, get those answers back. Then you ask Cleric again, to pull the data from the logs. So normally when you're using with... Working with an LLM, you probably just paste in all of logs, right? Like all 300, 600 lines of logs. But Cleric can actually just go through and read those and say, here's the exact error, here's the error message, here are the lines of code it's affecting. And you're basically shrinking your context a lot. And then finally, you use an LLM to actually do take action and, make Decisions and take action and extract values altogether, this same agent can run with system one. Let's do a little bit of a live demo. Let's see how it goes. We're gonna have to click run both here. And this is a live demo, and, I will say that Cloudflare, our workers' AI, has a very diurnal usage pattern. So we're in the middle of the work day, so we'll see how this goes. But it'll give you some illustrative example here of how it goes. And we're also dealing with conference wifi, so Bear with me here. Alright, the system one model side finished already. And the all LLM one is going. So I think even illustratively you can see that the, system one set of models is a lot faster. Even by just this simple waterfall chart, you can see that the system one part takes so much less time than the, actual generation, which is the purple bars here. And I think they both ended up getting to the answer at the end, so the quality was not affected. But it took a lot less time, it was a lot Cheaper, six LLM calls versus one, 40,000 LLM tokens versus 1,800. And so you can see how you can use these kind of system one and system two models, even in like developer workflows in order to get you to your answer faster. So the same answer, but it took a fraction of the LLM time and cost, right? I ran this when we were not doing conference wifi, but we had about nine point two seconds, and seventeen point two seconds on the LLM. It was almost two times Faster. It was 72% less expensive. We shrunk our LLM calls from five down to one, and it was about 94% less tokens. And so this is an illustrative example of completely replace your LLM usage, but it can augment it and make it better by making... Allowing you to free up time and compute for your other and more important tasks here. And you can now do You know, higher concurrency tasks because these models are able able and capable to do so much more. And so that was one illustrative example. I just wanted to flash on the screen really quickly as well, what else are people building with Clef and Cleric, right? There's a lot of, routers that you can build in in making decisions there. There's fraud that we've been seeing a lot, like spam or phishing, it can make decisions on there. With Cleric, you can use it to extract data from like web pages or support tickets and things like that. I'm excited to see, we actually have New launch coming out for Clariq. We released an early preview, but it's coming out. So I think these use cases will grow as, people are trying it out more and more. But the idea is that there's so much in the world, we're not limited to just LLMs. Now these new paradigms have been introduced, and I think we should all take advantage of that and try building with it. And so we went backwards, we went forwards, but I think the most important thing here is that we go onwards, right? We have to be very reactive in this industry, love it or hate it. In this industry, love it or hate it. Things just change on a whim. You know, if we as Cloudflare, back in the day said our hypothesis was wrong, we have to go and actually pivot and start serving these giant LLMs in order to take advantage of the fact that we wanna be an agent cloud cloud, and that it makes sense for our story. When an east wing wind comes and we need to, have decision models because it fit perfectly with our infrastructure story, we had to pivot and be a NeoLab as well. So it's not... It's one thing to sit here and Look back, but the more important thing is that we took what we had in stride and moved forwards. So I'll leave you with one last quote here, which is a story from Tolstoy. Remember then, there's only one time that is important, now. It is the most important time because it's the only time when we have any power. And so I'll leave you with this quote and a question of what are you going to build today? Hundreds of pull requests a day and nobody reads them all. So how does code quality keep improving? To share how the GrokBot team Turn slop into gold. Please welcome Lauren Tan, principal engineer at SpaceX Superintelligence. Hello, everyone. Don't know if you can see my slides, but, my name is Potato, also known as Lauren, and I'm very excited to chat with all of you today. Maybe you can get a big round of applause for our tech team helping me with my laptop. Okay. I don't see it. Yes, I have it. There you go. All right. So again, I'm... My name is Potato. I work on GraphBot at Space XSI. And can I just give a quick show of hands? How many of you have ever looked at code? That somebody else wrote, and you thought, that's all slop. Well, I have too. But today, I'm gonna convince you that you can turn that slop into gold. And so I did something crazy last month, and I shipped 3,000 ploycrests to production. Now before agents, we never really cared about volume, except for the outliers. And at my previous company We call these people coding machines, people like Brett Taylor, who famously rewrote all of Google Maps, in a weekend, just an insanely productive engineer. And well, with agents, anyone can now be a coding machine. And my thesis is that the job of the software engineer, the meta of being a software engineer, is figuring out how to maintain or even improve the quality of your code while massively increasing your productivity. To get there, some people like to call this a software. Factory. But I like to keep it simple, and I think of it as all about trust. Not blind trust, but investing in your agent's environment so you can trust that your agents are gonna do the right thing. Now it takes quite a lot of effort to get there. And it took me six months to get to a point where I could ship thousands of pull requests, a lot of them in my sleep. But it's certainly possible, and it will take you much less time than I did. So let's start by talking about how we move from a low trust environment to a high trust one. So this inverse pyramid is how I think about where to spend time on your agent's environment. The first two layers are deterministic, so using your code itself. So things like good API design, architecture, refactoring, or using lint rules, type systems, compilers, or, you know, different kinds of testing. And you can use both of these layers. This together to constrain what agents can do and force them to do the right thing by default. Verification, both runtime and formal, are great tools to layer on to find bugs and check properties and the invariance in in your system that you want to hold true, and also help you check whether or not the agent understood your goals and your intent. And then finally, you want to layer with a little bit of pros. So things like rules, skills, agents. Md, things that Require judgment. But let's start with your codebase. Agents generate their outputs based on their inputs. And so the the quality of the input really matters. And it just so happens that your codebase is one of the largest inputs. So whenever you're correcting your agent, think about how you can make that a deterministic check instead of adding another line to your rules or your agents. Md, because it's far more reproducible when it's in code and it lets you trust it more. And the analogy that I like to use is that your code base is kinda like a garden. You know, code used to arrive a few pull requests at a time. And, I remember going into work in 2024 and reviewing pull requests that my colleagues wrote... Colleagues wrote. And today, that number is more like 300. So, you know, every engineer is now a team of hundreds or even thousands of agents, and code is arriving so rapidly. It almost feels like a continuous stream, and it almost feels organic, like a living thing. And in this analogy, your code base, the constraints that you impose, the guardrails that you put up are the concrete foundations that the new code that your agents write grow around, just like, the building in this picture. And so in many ways, the job of being a software engineer is kind of becoming like gardening. Because code is the biggest Input for agents, it means that any workarounds, anti patterns, deprecated code, tech dep, it's now likely to be just copied by the next agent since it looks like the established pattern in your code base. And, it's like you have some weeds or pests growing in your garden and then they spread everywhere before you know it. So you want to make your code base as pristine as possible so that agents are always Being the good stuff. All right, let's look at some real examples. So Dune is a client framework that we created for GroBot to implement this idea for organic architecture. It's not really that interesting technically. You can kind of think of Dune as, kind of like Next. Js for electron apps. But the interesting part of Dune is that it has a lot of constraints and lit rules that we've encoded, a lot of the lessons that we've learned building desktop applications. And one such lesson is that anything that requires nuance to use well often leads to SLOP. You know, your classic example is, you know, useEffect in React, right? It has its use cases, but it's often misused. You know, some people joke that you need a PhD to use useEffect. And in in other words, it really requires a lot of nuance to use Balm, and agents are not good at using it. So our solution has been to just ban it. In product code, and it's really only allowed in some places inside of Dune APIs. And effectively, this problem has now been categorically eliminated, and we never need to catch that during code review again. Another interesting pattern that we use is context through directory structure. So one anti pattern that we saw with Cursor, which is an electron app, is that agents would often import main thread code into the render thread, which would cause long tasks. And jank. So in, Groppbot and in Duneapps, we've made this very, very conventional. We have these two top level directories, literally called electron renderer and electron main, and imports between them are forbidden or banned by our dependency graph analyzer and some LIT rules. And again, you know, these are simple LIT rules to set up, but it means one less thing that we need to review and think about, you know, during code review. And then one more surprising thing that I've seen is agents using markdown. So things like documentation, code comments, rules or skills, and they use this as a place to write down their justifications for not doing the right thing. Or I don't know if you've ever seen this, but they'll over rotate on some small correction that you made, and they treat it like a hard rule that can never be broken ever again. And here's another example from Cursor. So agents We loved using imperative timers, so things like setTimeout, requestAnimationFrame, requestIdleCallback. And they were using these as quick fixes because they were really patching over an architecture clash between, Versus Code's imperative style and React's declarative style. So our choice of architecture actually made both the client and the agent performance much worse. And if you've ever done any performance work in JavaScript, you'll know that when you have tons of timers being Rapidly created and destroyed causes a lot of, major garbage collection, which causes a lot of lag and jam. But the worst part is that agents wrote a lot of code comments, like you can see in red here, here, explaining why this quick fix was justified. And before you know it, we had timers spreading everywhere and the, you know, the performance of the app really suffered. Now in GrokBot, we learned our lesson there, and we decided to just ban 99% of comments.

## Slides

### 00:00:08

2026
# Cloudflare was **not wrong**, just **early**
With small, fast models, the network is the latency again.

- centralized GPU
- GPU near

### 00:00:36

## 2026

# So Cloudflare built its own version of Jev in about two weeks

- Sep 15: Jev ships
- Sep 18: first Cloud

### 00:01:08

2026
# Clef: decisions over an API call

```javascript
const res = await env.AI.run("@cf/cloudflare/clef", {
  model: "

### 00:01:40

# Same decision. Clef vs an LLM

- clef: 0.29s
- glm-5.3: 6.06s

**20x

### 00:02:08

2026

# So: what else do agents send to an LLM that is **overkill**?

### decisions -> Clef ✓
- Is it urgent?
- Which

### 00:02:40

2026

# Clairic: for answers you can't list up front

-   **extract**
    -   invoice id
    -   "INV-2041

### 00:03:08

# Clairic: for answers you can't list up front

## 2026

- **extract**
  - invoice id
  - `"INV-204

### 00:03:39

# Clairic: typed values from unstructured data

```javascript
const res = await env.AI.run("@cf/cloudflare/clairic", {
  model: "clairic",

### 00:04:08

# 2026
# Cloudflare became a **neolab**. Now the agent cloud is complete

## the agent cloud

### infrastructure
- network + GPUs

### compute

### 00:04:39

# Forwards.
What can we build with it?

cloudflare is a neolab
Michelle Chen / Group Product Manager

[Cloudflare logo]
[QR code]

### 00:05:08

# The usual agent: the big LLM drives every step

- LLM -> get_pr -> LLM -> failed jobs -> LLM -> two CI logs -> LLM -> test history ->

### 00:05:42

# The same agent, with **System One**

- **clef-flash**: prunes 40 -> 10 tools
- **clairic**: fills tool args
-

### 00:06:08

# The same agent, with **System One**

- `clef-flash`: prunes 40 -> 10 tools
- `clairic`: fills tool args
- `your code`: calls the picked tools with Clairic's args
- `clairic`: reads each log
- `answer`

- **1** round trip to `glm-5.3`
- **10** tool schemas, picked by Clef
- **6** typed log fields, no raw log

cloudflare is a neolab
Michelle Chen / Group Product Manager

[Flowchart illustrating a process with steps: clef-flash, clairic, your code, clairic, and answer]
[QR code]

### 00:06:40

# CI triage agent · a Durable Object running Pi

CI is red on PR #4182. Why did it fail, and should I rerun it or fix the code?

### all-

### 00:07:08

# CI triage agent · a Durable Object running Pi

CI is red on PR #4182. Why did it fail, and should I rerun it or fix the code?

## all

### 00:07:40

# CI triage agent · a Durable Object running Pi

## CI is red on PR #4182. Why did it fail, and should I rerun it or fix the code?

### 00:08:12

## Same answer. A fraction of the LLM

- all-LLM: 17.2s
- System One: 9.2s

**1.9

### 00:08:41

# What people are building with Clef and Clairic

### agent guardrails
block unsafe tool calls before they run

### agent drift
flag when an agent starts behaving differently

###

### 00:09:12

# What people are building with Clef and Clairic

- **agent guardrails**
  block unsafe tool calls before they run
- **agent drift**
  flag when an agent

### 00:09:40

# Onwards.
## What are you going to build?

cloudflare is a neolab
Michelle Chen / Group Product Manager
[https://cloudflare.com/neolab](https://cloudflare

### 00:10:12

# Onwards.
What are you going to build?

### cloudflare is a neolab
Michelle Chen / Group Product Manager
LIVE TRANSLATION
[Cloudflare logo]
[QR

### 00:10:36

# AI Engineer Code Summit
## cloudflare is a neolab
Michelle Chen / Group Product Manager

[Cloudflare logo]
[QR code linking to https://www.cloudflare.com/]

### 00:11:08

# LAUREN TAN
## Principal Engineer, SpaceX
AIE Code 2023 JP SF, CA
[SpaceX logo]

### 00:11:41

# AI Engineer Code Summit
## All Code Is Slop (Except Mine)
### Lauren Tan / Principal Engineer **SPACEX**

Presented by Google DeepMind

[QR code]

### 00:12:11

# AI Engineer Code Summit
## All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer **SPACEX**

[QR code]

### 00:12:36

# All Code Is Slop (Except Mine)

## OUR BLESSED CRAFT
- OUR GLORIOUS AGENTS
- OUR GREAT PROMPTING
- OUR NOBLE ITER

### 00:13:09

# quality & quantity
## everyone can be a coding machine

> the new meta is shipping fast without compromising on quality
> @poteto

### All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer SPACEX

[Cartoon illustration of a person happily typing on a laptop]
[QR code linking to https://poteto.dev/](https://poteto.dev/)

### 00:13:36

# All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer SPACEX

## help agents write good code

### low trust
most people get stuck here

- agent

### 00:14:08

# how do i trust my agents more?

### the poteto pyramid

- **codebase** (good api design, architecture, refactoring)
- **static analysis** (lints, types, compilers, tests, ci)
- **verification** (formal, runtime)
- **prose** (rules, skills, AGENTS.md)
- **human review**

@poteto

[Inverted pyramid diagram divided into five horizontal layers, with an arrow labeled "cost" pointing downwards along the left side]

### 00:14:40

# how do i trust my agents more?
### the poteto pyramid

- codebase (good api design, architecture, refactoring)
- static analysis (lints, types, compilers, tests, ...)
- **verification** (formal, runtime)
- prose (rules, skills, AGENTS.md)
- human review

@poteto
[Inverted pyramid diagram showing five layers: codebase, static analysis, verification, prose, and human review, with a "cost" arrow pointing downwards alongside the pyramid.]

### 00:15:11

# how do i trust my agents more?
## the poteto pyramid

**code is memory**

- codebase (good api design, architecture, refactoring)
- static analysis (lint

### 00:15:39

# AI Engineer Code Summit
## Presented by Google DeepMind

# All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer SPACEX

[Illustration of multi-story buildings with balconies and terraces covered in abundant greenery, resembling vertical forests. Small anime-style characters are visible on some balconies, engaged in activities like watering plants, drinking, waving, and using a laptop.]
[QR code for live translation]

### 00:16:09

# Organic Architecture

## All Code Is Slop (Except Mine)

### Lauren Tan / Principal Engineer SPACEX

AI Engineer Code Summit
Presented by Google DeepMind

@pplato

### 00:16:41

# each copy makes the next copy more likely

- one workaround
- the pattern

## All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer SPACEX

[

### 00:17:04

# dune: a framework for agents

- **app framework** (navigation, rendering, IPC)
  - one folder per feature
  - strict import bans
  - no comments in

### 00:17:36

# All Code Is Slop (Except Mine)
## nuance tends to lead to slop
### just design better APIs
@poteto

Lauren Tan / Principal Engineer SPACEX

[Illustration of a person with glasses looking confused at a control panel with a small robot beside them]
[QR code]

### 00:18:12

# nuance tends to lead to slop
just design better APIs

@potato

### All Code Is Slop (Except Mine)
Lauren Tan / Principal Engineer SPACEX

[https://www

### 00:18:37

# directory structure is a form of context

### Dune

- `electron-renderer/`
  - `features/`
  - `client/`
- `primitives/`

### 00:19:08

## stop agents from writing unsolicited markdown
@poteto
[Illustration of a person asking "Source?" to a robot who replies "I made it up", surrounded by `.md` files.]

### 00:19:36

# quick fixes considered harmful

## Sep 9
```js
// release later, in case it comes back
setTimeout(() => release(id), 0)
```
fixes a flicker