Talk by Dominik Tornow (Resonate HQ) on how coding agents affect software engineering practices: instead of relying on general-purpose libraries, frameworks, or platforms, agents synthesize bespoke systems on demand. The talk covers where agents fail, where they succeed, and a workflow treating the specification as the product and the prompt as the platform. # Channel Identity Observations — "The Prompt is the Platform" ## Speaker Self-Identification (Explicit Claims) - **Creator identity stated directly:** > "I'm Dominic Tornow. I am founder and CEO of Resonate." - **Company self-description (creator's own words):** > "Resonate is a durable execution platform built with minimalism and simplicity as its core technical values." - **Claimed product scope:** > "The product is no longer the implementation. The product is the specification, the protocol." - **Claimed ecosystem breadth:** Resonate SDKs for **TypeScript, Python, Rust, Go, and Java**, plus a reference server implementation. - **Claimed partnerships:** Collaboration with infrastructure providers, named example: **Synadia, the company behind NATS.io**. ## Intended Audience (Observable Presentation) - **Technical/software engineering audience:** The talk assumes familiarity with distributed systems concepts — consistency models, optimistic concurrency, fuzz testing, transaction boundaries — without introductory framing. - **Practitioners evaluating AI-assisted engineering:** Core question posed is: > "How can agents participate in specifying the system? Not just building or verifying it." - **Infrastructure/platform engineers specifically:** Emphasis on "durable execution right on top of their existing infrastructure with minimal additional dependencies" targets teams invested in their current stacks. ## Claimed Scope of the Channel/Company Presentation - **A working theory about the field**, presented as a thesis: > "General-purpose implementations will increasingly be replaced by bespoke implementations generated on demand." - **A methodology demonstration**, not just opinion: a step-by-step pipeline — *abstract specification → simulation implementation → concrete specification → concrete implementation* — illustrated with a concrete case study (Resonate on NATS.io, Rust on Postgres). - **An engineering philosophy:** Three years of protocol reduction, "centered around two objects, a durable promise and a durable task." ## Demonstrated Presentation Patterns (Observable, Not Claimed) - **Case-study structure:** Opens with a provocative thesis ("the platform is unnecessary"), then supports it with a narrative of a failed first attempt, a corrective process change, and a successful outcome. - **Candor about failure:** > "And the agent failed. The gap between the abstract specification and the concrete implementation was too large." - **Pedagogical use of concrete examples:** Walks through a versioned key-value store read (foo → bar → baz, version 2) to explain stale reads. - **Audience engagement:** Closes with a call to action: > "If you have any questions, please don't hesitate to reach out. You will find me in Resonate's Discord." — Observable evidence of a community channel and accessible creator posture. ## Claims vs. Demonstrations Summary | Type | Evidence | |---|---| | **Creator claim** | Resonate's value proposition, partnership with Synadia, SDK coverage | | **Demonstrated pattern** | Technical depth, failure transparency, structured methodology narrative, audience outreach via Discord | No channel-level conclusions (e.g., audience size, upload cadence, private motivations) can be drawn from this single video; observations above are limited to what this talk directly states and demonstrates. # Delivery Observations: "The Prompt is the Platform" — Dominik Tornow ## Overall Tone & Register - **Calm, declarative, measured delivery.** The speaker presents claims as settled conclusions rather than open questions: "In 2026, coding agents will quietly retire their first software platform." - **Engineer-to-engineer register**: assumes audience familiarity with concepts like transactions, consistency models, and fuzz testing, without pausing to define them. - Occasional dry, understated humor: "Not as a new library, a new framework, or a new platform," and "ace this task instead of falling flat on its face." ## Rhetorical Structure & Habits ### Reframing via question-substitution A recurring move: the speaker poses a question, then explicitly replaces it with a better one. > "So, the question is no longer can we build a server? The question is, can we repeatedly synthesize trusted servers from the same specification?" > "We did not ask, 'Can the agent build the production system?' Instead, we asked, 'What does the agent need in order to design the system first, and build the system second?'" > "So, how do we set up our agent for success?" ### Self-interrogation as a pacing device He frequently narrates his own next question: > "So, we have to ask, what does this new reality mean for us? If implementations become generatable, where does our value live?" ### Contrast pairs Delivery repeatedly leans on paired opposites: - "abstract" vs. "concrete" — "The specification must be abstract. Only the implementation must be concrete." - "It is not corruption. That is not a bug in the key value store." - "Not just the invariant failed, but the invariant failed because..." - "The simulated implementation is not the product. It is executable design." ## Recurring Phrases & Vocabulary - **"The prompt is the platform"** — the title phrase, introduced early ("At this point, the prompt is the platform") and returned to in the closing ("The prompt is the platform and the specification is the product"). - **Repetition for emphasis** through anaphora: > "The specification must not assume a concrete database schema or concrete indices. The specification must not even assume a relational database... It must not assume a key-value store. It must not assume weak consistency. It must not assume strong consistency." > "It broke on the concurrency. It broke on the process failure. It broke on the network failure." - **Signature terms**: "minimalism and simplicity," "durable execution," "deterministic simulation," "concrete specification," "forbidden fruit" (his own coined label), "executable design." ## Narrative & Teaching Pattern - **Narrative arc of trial and correction**: he presents a failed first attempt ("And the agent failed"), diagnoses the cause ("The gap between the abstract specification and the concrete implementation was too large"), amends the process, then iterates again. This failure→fix→limitation→next-step structure repeats across the talk. - **Stepwise enumeration of the process**, stated and restated: "the process becomes abstract specification, simulation implementation, concrete specification, and then concrete implementation." - **Concrete walkthroughs** after abstract claims — e.g., the versioned key-value store example ("We create a key with value foo, then we update it to bar, then we update it to baz") and the simulated trace-event example. - **Attribution of failure to the setup, not the agent**: "The agent helped us build the system, but the agent did not help us design the system." ## Uncertainty Notes - This is a single talk; recurring habits above are observable within it, but whether they generalize across the speaker's other presentations is **not verifiable from this source**. - No audience interaction or delivery tempo/intonation is observable from the transcript alone; tone observations rest on word choice and phrasing only. # Position Record: "The Prompt is the Platform" — Dominik Tornow, Resonate HQ ## Speaker Identification - **Sole speaker:** Dominik Tornow, self-identified as **founder and CEO of Resonate**, "a durable execution platform built with minimalism and simplicity as its core technical values." --- ## Central Claims & Positions ### 1. Prediction: Agents Will Retire Traditional Software Platforms - Tornow opens with a forward-looking claim: *"In 2026, coding agents will quietly retire their first software platform. Not because it's bad, simply because the platform is unnecessary."* - This is stated as a working theory, not an established fact: *"At Resonate, we have a working theory where software engineering is headed."* ### 2. Reuse Moves Upstream: From Implementation to Specification - **Claim:** General-purpose implementations will be replaced by **bespoke implementations generated on demand**, as minimal extensions of existing infrastructure — not as new libraries, frameworks, or platforms. - **Consequence for Resonate's business:** Value shifts from implementation to specification; *"The product is no longer the implementation. The product is the specification, the protocol."* - The guiding thesis: *"At this point, the prompt is the platform"* and, restated at the close, *"the prompt is the platform and the specification is the product."* - New framing of the engineering question: *"can we repeatedly synthesize trusted servers from the same specification?"* ### 3. Agents Should Participate in Design, Not Just Build and Verify - Tornow observes that agentic engineering discourse over-focuses on **verification** (*"How do we know the result is correct?"*). - His position: agents should move **upstream** into **specifying and designing** the system, not just building or verifying it. --- ## Reasoning & Evidence Presented ### Pipeline: Abstract Spec → Simulation → Concrete Spec → Implementation - The specification must be **implementation-agnostic**: it must not assume schemas, indices, a relational database, key-value store, weak or strong consistency. *"Only the implementation must be concrete."* ### First Attempt (Postgres, Rust) — Documented Failure - Asking the agent directly to *"Build a Resonate server in Rust on top of Postgres"* **failed** — the gap between abstract spec and concrete implementation was too large. - Result: worked on the happy path, passed basic tests, but **broke on concurrency, process failure, and network failure**. *"Closer to a prototype, but not a production system."* ### Second Attempt — Concrete Specification as Intermediary - Inserted a **concrete specification** (schema, indices, SQL queries, transaction boundaries), derived interactively with the **human as the main driver**. - This worked technically, but revealed a limitation Tornow preserves explicitly: *"The agent helped us build the system, but the agent did not help us design the system."* ### Third Attempt (Resonate on NATS) — Simulation-Driven Design - Reframed the question: *"What does the agent need in order to design the system first, and build the system second?"* - Gave the agent a **deterministic simulation environment** (Python, simulating the needed parts of NATS.io) and asked it to build a **simulated implementation** — described as *"executable design"* whose purpose is to discover the correct algorithm **under partial order and partial failure**. - Process: **abstract specification → simulated implementation → concrete specification → concrete implementation**. - Outcome claim: *"the agent was able to close the gap"* — proof of concept verified by fuzz testing, then concrete spec, then production implementation. - Humans remain involved, but the **agent is now a driver** in design. ### Key Technical Points on Consistency - NATS primitives: queues, key-value store, delayed/scheduled messages — described as target-platform concepts, not Resonate concepts. - Stale reads are **legal** behavior, not corruption: *"The implementation has to be correct when the target behaves legally"* — not merely when it behaves conveniently. - Building correct applications on a model with occasional stale reads is *"not simple. Not for humans. Not for agents."* ### "Forbidden Fruit" Mechanism - The simulation records facts hidden in production: whether a read was fresh or stale, and the hidden latest value. - Crucial qualification preserved: *"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."* - Purpose: give agents immediate, unambiguous feedback — not just *that* something failed but *why* (which invariant broke, from what stale view). ### Minimalism as Enabler - *"Minimalism and simplicity are not the starting point. They are the finish line."* — three years of shrinking the protocol by asking what to remove. - Result: a very small protocol with **two objects: a durable promise and a durable task**. - Rationale: even simple concurrent distributed protocols have a complex state and behavior space. --- ## Qualifications & Tensions Preserved - The opening 2026 prediction is explicitly a **theory** ("If this theory holds true"). - Tornow does not claim agents design autonomously: **"Humans are still involved in the design process"** — the claim is only that the agent becomes *a driver*. - The reported success rests on **speaker-reported internal experience** (the Postgres failure and the NATS success); no external verification is offered in the talk. - Acknowledged unresolved difficulty: correctness under stale-read concurrency remains hard for both humans and agents. ## Cited Context - Partnership with **Synadia**, "the company behind NATS.io," used as the worked example for agentic engineering practices. # Speaker Attribution Record ## Video - **Title:** The Prompt is the Platform - Dominik Tornow, Resonate HQ - **Video ID:** `01a15ca8-dada-7cae-94c6-05ca9c6bd311` ## Speakers | Speaker | Role | Evidence | |---|---|---| | **Dominik Tornow** (transcript spells first name both "Dominic" and "Dominik") | **Creator / Sole presenter** | Self-identified: *"I'm Dominic Tornow. I am founder and CEO of Resonate."* | - No other speakers, guests, narrators, or interviewers appear in the transcript. - Entire talk is first-person delivery by the presenter; no dialogue or Q&A recorded. ## Referenced Entities (Non-Speaking) - **Resonate** — presenter's company; described as a durable execution platform with server and SDK implementations (TypeScript, Python, Rust, Go, Java). - **Synadia** — identified as the company behind **NATS.io**, an open-source messaging system; named as an infrastructure partner. - **NATS / NATS.io** — target platform used in the talk's examples (key-value store, queues, scheduled messages). - **Postgres** — cited as an example target for agent-generated implementation. - **Resonate's Discord** — cited as the contact channel at the talk's close. ## Third-Party Claims - None attributed to external parties; all claims are the presenter's own assertions about Resonate's methods and partnerships. ## Promotional Segments - **Company/product promotion:** The talk itself promotes Resonate's platform, SDKs, protocol, and partnership strategy throughout — presented as a company talk by its founder/CEO. - **Partner mention:** Synadia/NATS.io partnership framed as a product collaboration. - **Call to action:** *"please don't hesitate to reach out. You will find me in Resonate's Discord."* ## Provenance Notes & Availability - **Comment availability:** Not stated in transcript; no curated metadata supplied. - **Timestamps:** Not present in the transcript. - **Uncertainty:** Speaker's first name appears in two spellings ("Dominic" / "Dominik") within the transcript; title uses "Dominik." In 2026, coding agents will quietly retire their first software platform. Not because it's bad, simply because the platform is unnecessary. I'm Dominic Tornow. I am founder and CEO of Resonate. Resonate is a durable execution platform built with minimalism and simplicity as its core technical values. And these properties will play a central role in this talk. At Resonate, we have a working theory where software engineering is headed. General-purpose implementations will increasingly be replaced by bespoke implementations generated on demand. 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. If this theory holds true, reuse will move upstream. Instead of reusing a general-purpose implementation, we will reuse a specification, and we will derive a bespoke implementation from it. In fact, we can build many bespoke implementations tailor-made for the infrastructure that is already in place. We just have to ask the agent. At this point, the prompt is the platform. Resonate is a durable execution platform. We have an implementation of the Resonate server. We have implementations of the Resonate SDK for TypeScript, Python, Rust, Go, and Java. So, we have to ask, what does this new reality mean for us? If implementations become generatable, where does our value live? And our answer? Our value moves from implementation to specification. Now, this changes how we think about Resonate. The product is no longer the implementation. The product is the specification, the protocol. And from that protocol, we want to derive multiple server implementations. One is the general-purpose Resonate server, our reference implementation. Others are implementations built with infrastructure partners. For customers and partners, this means durable execution right on top of their existing infrastructure with minimal additional dependencies. So, the question is no longer can we build a server? The question is, can we repeatedly synthesize trusted servers from the same specification? And if so, how? When we talk about agentic engineering, we focus all of our attention on verification. How do we know the result is correct? But today, I want to focus on the specification instead. And more importantly, how can agents participate in specifying the system? Not just building or verifying it. Now, Resonate is partnering multiple infrastructure providers to bring durable executions natively to their technology stack. One of them is Synadia, the company behind NATS.io, an open-source messaging system designed for building modern distributed systems. For the rest of this presentation, we will use Resonate on NATS.io to explore our agentic engineering practices. How do we go from specification to implementation? First, we need to level set our mental model. This picture is a common view of agent decoding. There's an agent, there's a specification, and then there's an implementation. And for many applications, that is enough. But it is not enough for what we are trying to do. Because we are not trying to generate one implementation from a specification. We are trying to generate multiple target-specific implementations from the specification. So, the specification must not take any aspect of an implementation into account. The specification must not assume a concrete database schema or concrete indices. The specification must not even assume a relational database with tables and transactions at all. It must not assume a key-value store. It must not assume weak consistency. It must not assume strong consistency. The specification must be abstract. Only the implementation must be concrete. So, we ask the agent to follow the abstract specification and generate a concrete implementation. Specifically, at first, we ask the agent, "Build a Resonate server in Rust on top of Postgres." And the agent failed. The gap between the abstract specification and the concrete implementation was too large. The agent generated a system that worked on the happy path. It passed the basic tests, but it was not correct. It broke on the concurrency. It broke on the process failure. It broke on the network failure. The implementation was closer to a prototype, but not a production system. So, we amended the process. Instead of asking the agent to jump directly from abstract spec to concrete implementation, we inserted an intermediary artifact, the concrete specification. That concrete specification was derived interactively with the agent. But, the human was the main driver. For Postgres, that meant making target-specific decisions explicit. The data schema, the indices, the SQL queries, the transaction boundaries. Once those decisions were written down, the agent was indeed able to implement the production system. So, this worked. But, it also revealed the limitations. The agent helped us build the system, but the agent did not help us design the system. And if the specification is a reusable product, then that's not enough. Now, the next step is obvious. Agents have to move upstream. But, how? When we started building Resonate on Natero, we changed the question. We did not ask, "Can the agent build the production system?" Instead, we asked, "What does the agent need in order to design the system first, and build the system second?" So, we gave the agent access to a deterministic simulation environment. And we gave it a different task. Do not build the production system. Build a simulated implementation. The simulated implementation is not the product. It is executable design. Its purpose is to discover the correct algorithm under partial order under partial failure. And once these algorithms are discovered, tested, and verified in simulation, then we ask the agent to write the concrete specification. And only then to be asked the agent to write the production implementation. So, the process becomes abstract specification, simulation implementation, concrete specification, and then concrete implementation. This is the point where the agent moves upstream. Humans are still involved in the design process, but now the agent is a driver. Two ingredients make this possible. Minimalism and simplicity. Unfortunately, minimalism and simplicity are not the starting point. They are the finish line. We spent 3 years making the protocol smaller and simpler. Every time we ran into a problem, we asked, "What can we take away? What abstraction can we erase? What property can we remove? What relationship can we break?" The result is a very small protocol centered around two objects, a durable promise and a durable task. That simplicity matters because even simple concurrent distributed protocol have a complex state and behavior space. So, in other terms, implementing even simple protocols on top of a few simple primitives is tough. Let's make this concrete with NATS. NATS gives us a small set of primitives we can build on. Queues, a key-value store, and delayed or scheduled messages. These are not resonate concepts. These are the concepts of the target platform. So, the design question becomes how can we express the resonate protocol using only these primitives? Let's focus on the key value store. The key value store is versioned. We create a key with value foo, then we update it to bar, then we update it to baz. So, the latest value is baz at version two. Most of the time, when we read the key, that is exactly what we get. A fresh read. And if all reads were fresh, the design would be straightforward. But sometimes, the read is stale. Here, the latest value is still baz at version two. But the read returns foo at version zero. That is not corruption. That is not a bug in the key value store. That is a valid read under the consistency model of the target platform. And that matters because our implementation cannot be correct only when the target behaves conveniently. The implementation has to be correct when the target behaves legally. So, the simulation environment has to expose exactly this kind of behavior. Fresh reads, stale reads, and the version information that tells us which world we are in. Unfortunately, we do not know the read was stale simply by reading. We will find out later when we try to write. Here, we read version zero. So, we try to update version zero. But, the key has already moved on. The right fails. That is the moment the target tells us the word you saw is not the current word. Building always correct applications on top of a concurrency model that allows occasional stale reads is not simple. Not for humans. Not for agents. So, how do we set up our agent for success? What tools does our agent need to ace this task instead of falling flat on its face? Agents thrive on feedback. Immediate unambiguous feedback. Not just feedback that shows this went wrong. Feedback that shows why and how this went wrong. What stale value was returned? What logic was triggered? What right failed? And which invariant broke because of that? So, we built a deterministic simulation testing environment in Python. And inside that environment, we simulated the parts of Nuts IO we depend on. Here, for example, is a simulated key-value store. It keeps a full version history for every key. On get, the simulated store sometimes returns the latest version. But, sometimes, controlled by the deterministic random generator, the store returns an older version. On update, the store enforces optimistic concurrency. The right only succeeds if the version you read is still the latest version. Otherwise, it raises. This gives the agent a store that behaves like the real store in the ways that matter for correctness. But, unlike the real target, the simulation is deterministic, it's repeatable, and it's inspectable. So, when the agent writes the wrong algorithm, we can reproduce the exact execution that broke it. And the agent can repair the algorithm against that trace. But, deterministic simulation does more than just inject stale reads. It lets us expose facts the real platform hides. We call this the forbidden fruit. In production, when you read from the key-value store, you only get the value and the version you observed. You do not get to know whether that read was fresh or stale. You do not get to see the latest value you missed. And you shouldn't get that information because real code cannot depend on it. But, in simulation, we can record it. Here, every get emits a trace event. If the read is fresh, the trace says, "This was fresh." If the read is stale, the trace says, "This was stale. This is what you got, and this is what the latest value was." That information is forbidden to the algorithm, but it is incredibly useful to the agent. It lets us explore failures in terms the agent can act on. Now, this is what a trace event looks like. The production code only receives the result. It sees the promise was pending. This is all the real platform would tell us. But, the simulation also records the type of the read. This read was a stale read. And it records the latest value that was hidden from the algorithm. The latest value says the same promise is already settled. That difference is exactly the kind of fact an agent needs when it's debugging a distributed algorithm. Not just the invariant failed, but the invariant failed because the algorithm made a decision from a stale view of the world. 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. Cause and effect becomes visible. The agent does not just learn that the system is wrong, it learns why the system is wrong. And with this approach, the agent was able to close the gap. First, the agent built a proof of concept in the deterministic simulator, verified by fuzz testing. From the proof of concept, the agent derived the concrete specification, where we already knew the algorithm was correct. And like before, from the concrete specification, the agent derived an implementation. Deterministic simulation lets agents participate in the design, not just in the implementation. Humans are still in the design process, but this time the agent is the driver. From a single abstract specification, the agent designed and built the platform. Via simulation to concrete specification to concrete implementation. The prompt is the platform and the specification is the product. Thank you very much for watching. If you have any questions, please don't hesitate to reach out. You will find me in Resonate's Discord.