The Prompt is the Platform - Dominik Tornow, Resonate HQ
https://www.youtube.com/watch?v=DqtmZE6Hl0g
AI Engineer · 17 min · 200 sentences · sentence-level transcript from YouTube's caption track; each line begins at the time shown

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