The Prompt is the Platform - Dominik Tornow, Resonate HQ

AI Engineer · 17 min · 200 sentences · from YouTube's caption track

Each timecode opens YouTube at the start of that sentence. Line anchors (#s42) are the cue ids in the WebVTT, and every line carries its start and end seconds. All transcripts has every talk, and the whole corpus as one file.

00:02In 2026, coding agents will quietly retire their first software platform.
00:09Not because it's bad, simply because the platform is unnecessary.
00:15I'm Dominic Tornow.
00:16I am founder and CEO of Resonate.
00:19Resonate is a durable execution platform built with minimalism and simplicity as its core technical values.
00:27And these properties will play a central role in this talk.
00:31At Resonate, we have a working theory where software engineering is headed.
00:37General-purpose implementations will increasingly be replaced by bespoke implementations generated on demand.
00:47Not as a new library, a new framework, or a new platform, but as a minimal extension of the infrastructure that is already in place.
00:57If this theory holds true, reuse will move upstream.
01:03Instead of reusing a general-purpose implementation, we will reuse a specification, and we will derive a bespoke implementation from it.
01:16In fact, we can build many bespoke implementations tailor-made for the infrastructure that is already in place.
01:24We just have to ask the agent.
01:27At this point, the prompt is the platform.
01:33Resonate is a durable execution We have an implementation of the Resonate server.
01:38We have implementations of the Resonate SDK for TypeScript, Python, Rust, Go, and Java.
01:45So, we have to ask, what does this new reality mean for us?
01:51If implementations become generatable, where does our value live?
01:57And our answer?
01:59Our value moves from implementation to specification.
02:05Now, this changes how we think about Resonate.
02:09The product is no longer the implementation.
02:12The product is the specification, the protocol.
02:15And from that protocol, we want to derive multiple server implementations.
02:21One is the general-purpose Resonate server, our reference implementation.
02:26Others are implementations built with infrastructure partners.
02:31For customers and partners, this means durable execution right on top of their existing infrastructure with minimal additional dependencies.
02:40So, the question is no longer can we build a server?
02:44The question is, can we repeatedly synthesize trusted servers from the same specification?
02:51And if so, how?
02:58When we talk about agentic engineering, we focus all of our attention on verification.
03:03How do we know the result is correct?
03:07But today, I want to focus on the specification instead.
03:12And more importantly, how can agents participate in specifying the system?
03:18Not just building or verifying it.
03:23Now, Resonate is partnering multiple infrastructure providers to bring durable executions natively to their technology stack.
03:31One of them is Synadia, the company behind NATS.io, an open-source messaging system designed for building modern distributed systems.
03:41For the rest of this presentation, we will use Resonate on NATS.io to explore our agentic engineering practices.
03:49How do we go from specification to implementation?
03:53First, we need to level set our mental model.
03:58This picture is a common view of agent decoding.
04:02There's an agent, there's a specification, and then there's an implementation.
04:07And for many applications, that is enough.
04:11But it is not enough for what we are trying to do.
04:15Because we are not trying to generate one implementation from a specification.
04:23We are trying to generate multiple target-specific implementations from the specification.
04:29So, the specification must not take any aspect of an implementation into account.
04:36The specification must not assume a concrete database schema or concrete indices.
04:42The specification must not even assume a relational database with tables and transactions at all.
04:48It must not assume a key-value store.
04:50It must not assume weak consistency.
04:52It must not assume strong consistency.
04:56The specification must be abstract.
04:59Only the implementation must be concrete.
05:04So, we ask the agent to follow the abstract specification and generate a concrete implementation.
05:10Specifically, at first, we ask the agent, "Build a Resonate server in Rust on top of Postgres."
05:20And the agent failed.
05:23The gap between the abstract specification and the concrete implementation was too large.
05:31The agent generated a system that worked on the happy path.
05:35It passed the basic tests, but it was not correct.
05:39It broke on the concurrency.
05:41It broke on the process failure.
05:42It broke on the network failure.
05:45The implementation was closer to a prototype, but not a production system.
05:52So, we amended the process.
05:54Instead of asking the agent to jump directly from abstract spec to concrete implementation, we inserted an intermediary artifact, the concrete specification.
06:07That concrete specification was derived interactively with the agent.
06:12But, the human was the main driver.
06:16For Postgres, that meant making target-specific decisions explicit.
06:22The data schema, the indices, the SQL queries, the transaction boundaries.
06:28Once those decisions were written down, the agent was indeed able to implement the production system.
06:34So, this worked.
06:37But, it also revealed the limitations.
06:40The agent helped us build the system, but the agent did not help us design the system.
06:48And if the specification is a reusable product, then that's not enough.
06:54Now, the next step is obvious.
06:56Agents have to move upstream.
07:00But, how?
07:04When we started building Resonate on Natero, we changed the question.
07:09We did not ask, "Can the agent build the production system?"
07:14Instead, we asked, "What does the agent need in order to design the system first, and build the system second?"
07:23So, we gave the agent access to a deterministic simulation environment.
07:28And we gave it a different task.
07:31Do not build the production system.
07:35Build a simulated implementation.
07:38The simulated implementation is not the product.
07:42It is executable design.
07:46Its purpose is to discover the correct algorithm under partial order under partial failure.
07:52And once these algorithms are discovered, tested, and verified in simulation, then we ask the agent to write the concrete specification.
08:01And only then to be asked the agent to write the production implementation.
08:06So, the process becomes abstract specification, simulation implementation, concrete specification, and then concrete implementation.
08:17This is the point where the agent moves upstream.
08:21Humans are still involved in the design process, but now the agent is a driver.
08:29Two ingredients make this possible.
08:32Minimalism and simplicity.
08:35Unfortunately, minimalism and simplicity are not the starting point.
08:39They are the finish line.
08:41We spent 3 years making the protocol smaller and simpler.
08:45Every time we ran into a problem, we asked, "What can we take away?
08:49What abstraction can we erase?
08:51What property can we remove?
08:53What relationship can we break?"
08:56The result is a very small protocol centered around two objects, a durable promise and a durable task.
09:04That simplicity matters because even simple concurrent distributed protocol have a complex state and behavior space.
09:13So, in other terms, implementing even simple protocols on top of a few simple primitives is tough.
09:24Let's make this concrete with NATS.
09:26NATS gives us a small set of primitives we can build on.
09:31Queues, a key-value store, and delayed or scheduled messages.
09:38These are not resonate concepts.
09:40These are the concepts of the target platform.
09:44So, the design question becomes how can we express the resonate protocol using only these primitives?
09:54Let's focus on the key value store.
09:57The key value store is versioned.
10:00We create a key with value foo, then we update it to bar, then we update it to baz.
10:06So, the latest value is baz at version two.
10:11Most of the time, when we read the key, that is exactly what we get.
10:17A fresh read.
10:19And if all reads were fresh, the design would be straightforward.
10:23But sometimes, the read is stale.
10:29Here, the latest value is still baz at version two.
10:33But the read returns foo at version zero.
10:38That is not corruption.
10:40That is not a bug in the key value store.
10:43That is a valid read under the consistency model of the target platform.
10:52And that matters because our implementation cannot be correct only when the target behaves conveniently.
10:59The implementation has to be correct when the target behaves legally.
11:06So, the simulation environment has to expose exactly this kind of behavior.
11:11Fresh reads, stale reads, and the version information that tells us which world we are in.
11:20Unfortunately, we do not know the read was stale simply by reading.
11:25We will find out later when we try to write.
11:29Here, we read version zero.
11:31So, we try to update version zero.
11:34But, the key has already moved on.
11:36The right fails.
11:39That is the moment the target tells us the word you saw is not the current word.
11:48Building always correct applications on top of a concurrency model that allows occasional stale reads is not simple.
11:57Not for humans.
11:58Not for agents.
12:00So, how do we set up our agent for success?
12:03What tools does our agent need to ace this task instead of falling flat on its face?
12:11Agents thrive on feedback.
12:14Immediate unambiguous feedback.
12:18Not just feedback that shows this went wrong.
12:22Feedback that shows why and how this went wrong.
12:27What stale value was returned?
12:30What logic was triggered?
12:32What right failed?
12:33And which invariant broke because of that?
12:38So, we built a deterministic simulation testing environment in Python.
12:42And inside that environment, we simulated the parts of Nuts IO we depend on.
12:48Here, for example, is a simulated key-value store.
12:53It keeps a full version history for every key.
12:57On get, the simulated store sometimes returns the latest version.
13:02But, sometimes, controlled by the deterministic random generator, the store returns an older version.
13:10On update, the store enforces optimistic concurrency.
13:14The right only succeeds if the version you read is still the latest version.
13:18Otherwise, it raises.
13:23This gives the agent a store that behaves like the real store in the ways that matter for correctness.
13:30But, unlike the real target, the simulation is deterministic, it's repeatable, and it's inspectable.
13:37So, when the agent writes the wrong algorithm, we can reproduce the exact execution that broke it.
13:45And the agent can repair the algorithm against that trace.
13:53But, deterministic simulation does more than just inject stale reads.
14:02It lets us expose facts the real platform hides.
14:07We call this the forbidden fruit.
14:10In production, when you read from the key-value store, you only get the value and the version you observed.
14:16You do not get to know whether that read was fresh or stale.
14:20You do not get to see the latest value you missed.
14:24And you shouldn't get that information because real code cannot depend on it.
14:30But, in simulation, we can record it.
14:34Here, every get emits a trace event.
14:38If the read is fresh, the trace says, "This was fresh."
14:41If the read is stale, the trace says, "This was stale.
14:44This is what you got, and this is what the latest value was."
14:49That information is forbidden to the algorithm, but it is incredibly useful to the agent.
14:57It lets us explore failures in terms the agent can act on.
15:05Now, this is what a trace event looks like.
15:09The production code only receives the result.
15:12It sees the promise was pending.
15:17This is all the real platform would tell us.
15:20But, the simulation also records the type of the read.
15:25This read was a stale read.
15:28And it records the latest value that was hidden from the algorithm.
15:32The latest value says the same promise is already settled.
15:37That difference is exactly the kind of fact an agent needs when it's debugging a distributed algorithm.
15:45Not just the invariant failed, but the invariant failed because the algorithm made a decision from a stale view of the world.
15:54Again, the algorithm is not allowed to depend on this information, but the agent is allowed to use it to explain why the algorithm it designed was wrong.
16:04Cause and effect becomes visible.
16:08The agent does not just learn that the system is wrong, it learns why the system is wrong.
16:16And with this approach, the agent was able to close the gap.
16:22First, the agent built a proof of concept in the deterministic simulator, verified by fuzz testing.
16:33From the proof of concept, the agent derived the concrete specification, where we already knew the algorithm was correct.
16:45And like before, from the concrete specification, the agent derived an implementation.
16:52Deterministic simulation lets agents participate in the design, not just in the implementation.
17:03Humans are still in the design process, but this time the agent is the driver.
17:08From a single abstract specification, the agent designed and built the platform.
17:12Via simulation to concrete specification to concrete implementation.
17:18The prompt is the platform and the specification is the product.
17:24Thank you very much for watching.
17:25If you have any questions, please don't hesitate to reach out.
17:29You will find me in Resonate's Discord.