# The Prompt is the Platform Dominik Tornow, Resonate HQ, Inc | AI Engineer World's Fair 2026 | 17:33 Source: https://www.youtube.com/watch?v=DqtmZE6Hl0g Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks. Page: https://aietalks.com/talks/the-prompt-is-the-platform Published: 2026-06-29 Tags: agents, code-generation, coding-agents, reliability, testing ## TL;DR - Coding agents can generate target-specific software from an abstract specification, so reuse moves from implementations to specifications. - Agents failed when asked to jump directly from an abstract protocol to production code, especially under concurrency, process failure, and network failure. - A deterministic simulation gives agents actionable feedback and lets them design algorithms before producing a concrete specification and production implementation. ## Summary Dominik Tornow argues that coding agents will reduce the value of general-purpose software platforms by generating bespoke implementations for the infrastructure already in place. Resonate's product therefore becomes its abstract protocol, while servers and SDKs can be derived for different targets. A direct attempt to generate a Rust server on Postgres produced code that passed basic tests but failed under concurrency and failures. Tornow's revised workflow inserts a deterministic simulation and a target-specific concrete specification. The agent first discovers an algorithm in simulation, then writes down the schema, queries, and consistency decisions, and only afterward generates production code. The simulator models NATS key-value behavior, including stale reads and optimistic concurrency failures. It also records information hidden from production code, such as whether a read was stale and what the latest value was, so the agent can understand why an invariant failed. Humans remain involved, but the agent drives more of the design. ## Key ideas ### Software reuse can move from implementations to specifications [00:29](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=29s) Tornow's working theory is that general-purpose implementations will increasingly be replaced by bespoke systems generated on demand. The reusable asset becomes a specification, from which an agent can derive implementations tailored to existing infrastructure. For Resonate, this changes the product definition. The Resonate protocol is the product, while the general-purpose server is a reference implementation. Other servers could be generated with infrastructure partners, giving customers durable execution on their current technology stack with fewer added dependencies. The engineering question becomes whether trusted servers can be synthesized repeatedly from the same specification. ### An abstract specification must avoid implementation assumptions [05:38](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=338s) Tornow separates the abstract protocol from every concrete target. The specification cannot assume a database schema, indices, relational tables, transactions, a key-value store, weak consistency, or strong consistency. Those choices belong in the implementation. This matters because the goal is to generate multiple target-specific implementations rather than one implementation. The talk uses Resonate on NATS.io as its example. NATS provides queues, a key-value store, and delayed or scheduled messages, but these are primitives of the target platform rather than concepts in the Resonate protocol. ### Direct generation from an abstract specification produced a prototype [04:56](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=296s) The first request was to build a Resonate server in Rust on Postgres. The gap between the abstract specification and the concrete implementation was too large. The generated system worked on the happy path and passed basic tests, but failed under concurrency, process failure, and network failure. Tornow describes it as closer to a prototype than a production system. The team then added a concrete specification between the abstract protocol and the code. For Postgres, a human and the agent made the schema, indices, SQL queries, and transaction boundaries explicit. Once those decisions were written down, the agent could implement the production system. ### Agents need to participate in design, so simulation comes before production code [07:16](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=436s) The concrete-specification workflow still left the agent helping to build the system rather than design it. Tornow changed the task by giving the agent a deterministic simulation environment. The agent was told to build a simulated implementation, not the production system. This simulation was executable design used to discover the correct algorithm under partial order and partial failure. After the algorithm was tested and verified in simulation, the agent wrote the concrete specification and then the production implementation. The resulting workflow is abstract specification, simulation implementation, concrete specification, and concrete implementation. ### Minimalism is a result of removing protocol complexity [08:37](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=517s) Tornow says minimalism and simplicity were not the starting point for Resonate. The team spent three years making the protocol smaller. When problems appeared, they asked what could be removed, which abstraction could be erased, which property could be dropped, or which relationship could be broken. The resulting protocol centers on two objects, a durable promise and a durable task. Even this small protocol has a complex state and behavior space because concurrent distributed systems are difficult to implement on top of simple primitives. ### The simulator must model legal but inconvenient platform behavior [09:29](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=569s) NATS's versioned key-value store can return a stale value. A key may currently contain baz at version two while a read returns foo at version zero. Tornow stresses that this is valid behavior under the target's consistency model, not corruption. The implementation must work when the platform behaves legally, not only when reads are fresh. A later write reveals the stale read: an update based on version zero fails because the key has already advanced. The simulator therefore exposes fresh reads, stale reads, versions, and optimistic concurrency failures. ### Hidden simulation facts give the agent explanations it can act on [13:42](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=822s) The real key-value store gives production code the value and version it observed, but does not reveal whether the read was stale or what newer value was missed. The simulator records those facts as trace events. It can tell the agent that a read was stale, show the returned value, and show the latest hidden value. The algorithm cannot depend on this extra information, but the agent can use it to understand a failure. Instead of learning only that an invariant broke, the agent can see that it made a decision from a stale view of the world. Tornow calls this information the "forbidden fruit" because it is unavailable to real application code but useful for debugging and design. ### The agent can derive a tested algorithm, specification, and implementation [16:26](https://www.youtube.com/watch?v=DqtmZE6Hl0g&t=986s) With deterministic simulation, the agent built a proof of concept and verified it through fuzz testing. It then derived a concrete specification from the tested algorithm, followed by an implementation. This moves the agent upstream into system design while keeping humans involved. The overall claim is that a single abstract specification can lead through simulation to a concrete specification and then to a target-specific implementation. Tornow summarizes the arrangement with the phrase, "The prompt is the platform and the specification is the product." ## Notable quotes - "At this point, the prompt is the platform." (01:27) - "The product is no longer the implementation. The product is the specification, the protocol." (01:54) - "The simulation is not the product. It is executable design." (07:25) - "The agent does not just learn that the system is wrong, it learns why the system is wrong." (15:32) - "The prompt is the platform and the specification is the product." (16:57) ## Tools & references mentioned - Resonate - Think Distributed Systems - Synadia - NATS.io - TypeScript - Python - Rust - Go - Java - Postgres ## Who should watch - You are building coding-agent workflows for distributed systems and need a process that handles concurrency and failure rather than only happy-path behavior. - Your team maintains a protocol across several infrastructure targets and is considering whether the specification should become the main product. - You want to use simulation and deterministic traces to give an agent more useful feedback while keeping production code unable to depend on hidden test information.