Jonas Templestein

CEO prev. cofounder/CTO Monzo, dad of three

[Jonas Templestein @jonas]

2025 will be the year we see the first self-driving startups.

Level 0: No AI
People do everything. They come up with ideas, build products, and run operations. Many legacy businesses still work this way.

Level 1: People use AI tools ⬅︎ we are here
People might use ChatGPT to help write copy or Cursor to help write code. This is where most startups are today.

Level 2: AI agents complete tasks based on human instructions
People might ask AI agents to write software from a plain-English spec or tell it execute well-defined customer service processes. At this point entire departments (like support or QA) get largely replaced by AI. No startups I know of operate at this level yet—but if yours does, let me know.

Level 3: AI agents propose changes to their own instructions
They might propose new customer service processes and product changes in response to customer feedback. Humans would still approve each of those changes. Just a few people could run a large company this way.

Level 4: AI agents autonomously change their instructions
At this point startups become self-improving. Humans would only be involved as an escalation point or where required by the real world (e.g. to raise capital or to incorporate). At this point many startups would only have one human.

Level 5: No humans
AI agents decide which businesses to start, raise capital (through crypto tokens or other means), build and run them. No humans required. This would require major reforms in the legal and financial system.

[Jonas Templestein @jonas]

@mmkalmmkal we shall use this tomorrow!

[Jonas Templestein @jonas]

@RhysSullivan @mmkalmmkal you'd like this

[Andrew Jefferson @EastlondonDev]

At microagi we want to put Europe at the front of physical and embodied AI. That’s why we’ve created the microagi research fellowship.

Fellows can build in our lab in Zurich or Munich, work with our team, our datasets and our partners like Unitree, Nvidia, and Google.

If you know someone who should be focussing on physical AI without any distractions, tag them, if you’re the first to tag someone who is accepted we’ll send you 10.000 USD

[Jonas Templestein @jonas]

@LambrosPetrou I’m so excited to read the source code!

[Jonas Templestein @jonas]

@acoyfellow V nice. If you’re in an IT environment where you can’t install chrome extensions, you can also just copy the snippet from https://t.co/wbnK5Tr5FE into your chrome console

[Jonas Templestein @jonas]

@swyx It’s like role=developer messages in gpt

[Jonas Templestein @jonas]

Love this! Have you considered open sourcing this?

It could serve as a reference implementation of the kind of system you can build from durable objects and KV

The CF primitives and platform are amazing but there is very little high quality reference code for it out there

I think it would really help adoption of durable objects in particular if you open sourced some of the first party products you’ve been launching

cc @dok2001

[Jonas Templestein @jonas]

@RhysSullivan Aren’t you doing codemode? You can use source code comments

Just use the same instructions you’d normally use for when to insert comments in the code

[Jonas Templestein @jonas]

Thanks for the response! Would you expect this to work then?

using streams = newWebSocketRpcSession("wss://…");
await streams.get("/some/stream").ping();

Where the server-side main object is an instance of a named WorkerEntrypoint

If get() returns a DO stub, like this:

get(path: string) {
return this.env.STREAMS.getByName(path);
}

The result is: Could not serialize object of type "DurableObject"

And if get() returns another named entrypoint like this

get(path: string) {
return this.ctx.exports.StreamEntrypoint({ props: { path } });
}
→ ServiceStub serialization requires the 'experimental' compat flag

[Jonas Templestein @jonas]

@KentonVarda is there any chance capnproto gets replaced with capnweb in workers rpc one day? It would be really useful for us!

We've got a capabilities based workers rpc system that is really ergonomic to use from within either our own workers, dynamic workers, or workers for platforms.

We've got a `ProjectCapability extends WorkerEntrypoint` at the root that is passed scopes/policies via props

And then we can write code like

await env.PROJECT.streams.get("/some/path").append({ event })

Now I thought I could use capnweb to make it so our end-to-end test runner (aka a nodejs script) can ALSO write the same kind of code! That would save us another pointless layer of wrapping. My tests could just be like this:

await using projectRpc = withProject({projectId})
const event = await projectRpc.streams.get("/some/path").append({event})

withProject is just a tiny fixture that creates a capnweb session

And this _mostly_ just works an is super great already. But there are some sharp edges. For example, I can't just pass service binding or durable object stubs across capnweb rpc boundary - I have to wrap everything into an explicit RpcTarget (unless I'm misunderstanding something... v possible)

And at the same time, there are some capnweb features I'd really like to use in our worker code now. For example ReadableStream<Event> instead of ReadableStream<Uint8Array>

I guess it's quite niche and there are probably lots of considerations we're not very close to (e.g. performance)?

[Jonas Templestein @jonas]

The end-state of this direction could be a system that lets you create "service bindings" from any JS runtime environment into a cloudflare worker from anywhere

As long as you trust the caller, you can then do away with any other additional RPC frameworks

[Jonas Templestein @jonas]

Another great use case are runtime environments like browser extensions, extensions for pi/openclaw/opencode etc, our own local dev environments

Anything that wants to sometimes be a server reachable from the internet but can’t shell out to cloudflared or ngrok or whatever - but can use fetch

[Jonas Templestein @jonas]

This is literally a 20 lines of code wrapper around capnweb

As always, fetch is all you need. The client just uses fetch to pass the server a fetch function and then the server can fetch into the client.

Now that we have this primitive, we keep thinking of stuff that used to be hard that is suddenly v easy to build

[Misha Kaletsky @mmkalmmkal]

Aand we just accidentally built ngrok. Deployed captun to https://t.co/DsvAClNtNd, so you can run `npx captun 3000` and get a public url.

But even better is JS usage. Create a public tunnel from anywhere: your agent, your test harness, or your browser tab. Rough, but working

[Jonas Templestein @jonas]

Massive shoutout to @KentonVarda for making capnweb - I really hope cloudflare keeps investing in it and capnproto interop

[Jonas Templestein @jonas]

@dwarkesh_sp Have you considered interviewing two people with different perspectives at the same time?

I love that you interview people with different perspectives, but wish the interviewees could react to each other

[Jonas Templestein @jonas]

@threepointone So good! Then just let the agent write its own subclass and run in dynamic worker durable object facet

[Jonas Templestein @jonas]

@lucasmeijer I played with this a bit when llama.cpp came out

You can do all kinds of cool stuff

Invent crazy shorthand that gets auto-expanded to save tokens and prevent common errors

[Jonas Templestein @jonas]

Yes - but also just in the responses api in general

I think ultimately you want some kind of clearing house where the caller can set deadline and cost constraints and the clearing house fulfils requests optimally

Initially each LLM provider could do this separately and eventually you might get a commodities market for compute

[Tibo @thsottiaux]

Should we bring batch compute to codex? Aka /slow mode

[Jonas Templestein @jonas]

@theo @jullerino 🫡