The Prompt is the Platform - Dominik Tornow, Resonate HQ

At-a-Glance

• Verdict: Watch fully
• Core thesis: By 2026, coding agents will make traditional platforms obsolete because they can generate bespoke implementations from reusable specifications; the key innovation is moving agents upstream into design via deterministic simulation, not just implementation and verification.
• Why it matters: This presents a concrete methodology for agent-driven system design that Resonate HQ has already validated in production, including moving from abstract specification → simulation → concrete spec → implementation, fundamentally changing where engineering value lives.
• Best use: Study this as a working playbook for building AI-assisted infrastructure: the four-stage process, the 'forbidden fruit' debugging technique, and the strategic shift from reusing implementations to reusing specifications.

Executive Summary

Dominik Tornow, CEO of Resonate (a durable execution platform), argues that general-purpose software platforms will be replaced by bespoke implementations generated on-demand by coding agents. The central insight: reuse will move upstream from implementations to specifications. Rather than one general-purpose server, Resonate now derives multiple target-specific implementations (Postgres, NATS.io, etc.) from a single abstract specification. This shift redefines the product—it's no longer the code artifact but the protocol specification itself.

Initial attempts to jump directly from abstract spec to concrete implementation failed. Agents produced systems that passed happy-path tests but broke under concurrency, process failure, and network failure. The breakthrough came from inserting intermediate artifacts and moving agents upstream into design, not just build/verify. The refined process: abstract specification → simulation implementation → concrete specification → production implementation. The simulation layer is 'executable design' where agents discover correct algorithms under partial order and partial failure before writing production code.

The enabling infrastructure is a deterministic simulation environment in Python that models target platform primitives (e.g., NATS.io's versioned key-value store with stale reads, queues, delayed messages). Critically, the simulation exposes 'forbidden fruit'—information real platforms hide, like whether a read was stale and what the actual latest value was. This gives agents immediate, unambiguous causal feedback: not just 'the invariant failed' but 'the invariant failed because the algorithm made a decision from a stale view.' Agents can then debug distributed concurrency correctness issues that would otherwise be opaque.

Resonate spent three years simplifying its protocol (durable promise, durable task) to make this agent-driven approach feasible. The result: agents now design and build platform implementations on infrastructure partners' stacks (Postgres, NATS.io) with minimal additional dependencies. Humans remain in the loop but agents are the driver in the design phase. This approach has already produced production systems, proving the methodology works beyond prototypes.

Key Takeaways

• Claim: Agents failed to generate production-quality systems when asked to jump directly from abstract specification to concrete implementation on Postgres. | Evidence: The generated Rust/Postgres system worked on happy paths and passed basic tests, but broke on concurrency, process failure, and network failure—it was closer to a prototype than a production system. | Caveat: The failure was due to the gap being too large; no discussion of which specific agent/model was used or whether different prompting strategies were attempted before inserting the intermediary artifacts. | Implication: For Ken's agent systems: direct spec-to-code generation is insufficient for distributed systems correctness; you need intermediate scaffolding and a design phase, not just a build phase. | Timestamp: timestamp unavailable
• Claim: Inserting a 'concrete specification' artifact (making target-specific decisions explicit: schema, indices, SQL queries, transaction boundaries) enabled the agent to implement a production Postgres-based system, but humans remained the main driver of design. | Evidence: After human-driven interactive derivation of the concrete spec, the agent successfully implemented the system. However, this revealed a limitation: the agent helped build but did not help design. | Caveat: This worked but was insufficient if the specification is meant to be a reusable product across multiple infrastructure targets; it required heavy human involvement in making design decisions explicit. | Implication: For Ken: codifying architectural decisions as intermediate artifacts is a forcing function for correctness, but stopping there limits agent leverage. To scale across targets, agents must participate in design, not just translation. | Timestamp: timestamp unavailable
• Claim: Deterministic simulation environments with 'forbidden fruit' debugging enable agents to discover correct distributed algorithms by exposing causal relationships hidden in production (e.g., whether a read was stale and what the true latest value was). | Evidence: Resonate built a Python simulator for NATS.io primitives (versioned key-value store, queues, delayed messages). On GET, it sometimes returns stale versions controlled by deterministic randomness. Trace events record not just results but whether reads were fresh/stale and the actual latest value. Example: production code sees 'promise pending,' but simulation reveals 'stale read, you got version 0, latest was settled.' | Caveat: This information is 'forbidden' to the algorithm itself (real code cannot depend on it), but is provided to the agent for debugging. No discussion of how much human effort was required to build the simulation environment or how generalizable this approach is to other platforms. | Implication: For Ken's AI ops: deterministic simulation with causal telemetry is a high-leverage technique for agent-driven correctness in concurrent/distributed systems. The key is making cause-and-effect visible so agents can iterate on algorithms, not just syntax. | Timestamp: timestamp unavailable
• Claim: The four-stage process (abstract spec → simulation implementation → concrete spec → production implementation) successfully moved agents upstream into design; agents are now the driver while humans remain in the loop. | Evidence: Using this process on NATS.io: agent built a proof-of-concept in the deterministic simulator, verified by fuzz testing; derived a concrete specification where the algorithm correctness was already known; then derived the production implementation. This closed the gap that earlier attempts could not. | Caveat: No specifics on iteration counts, human intervention frequency, or failure modes in the simulation phase. Also unclear how much domain expertise (distributed systems, concurrency models) is still required from humans to guide the agent. | Implication: For Ken: this is a validated playbook for agent-assisted infrastructure engineering. The simulation layer de-risks design before committing to production. Agents can now participate in architectural decisions, not just code generation. | Timestamp: timestamp unavailable
• Claim: Minimalism and simplicity are not the starting point but the finish line; Resonate spent three years simplifying its protocol to two core objects (durable promise, durable task) to make agent-driven multi-target generation feasible. | Evidence: Every time they hit a problem, they 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 that can be implemented on NATS primitives (queues, key-value store, delayed messages). | Caveat: No details on what was removed or what complexity existed before. Also, simplicity may come at the cost of expressiveness or performance—no trade-offs discussed. | Implication: For Ken's investment thesis and agent ops: protocols/specifications designed for agent generation require upfront design discipline. Simplicity is a feature that compounds; complex specs will remain human-bottlenecked. This also implies that legacy platforms not designed with simplicity in mind will be harder to agent-ify. | Timestamp: timestamp unavailable
• Claim: The specification becomes the product, not the implementation; value moves upstream from code artifacts to reusable protocols that generate many bespoke implementations. | Evidence: Resonate's product is now the protocol, from which they derive a general-purpose reference server and multiple infrastructure-partner-specific implementations (Postgres, NATS.io, etc.). Customers get durable execution on their existing infrastructure with minimal dependencies. | Caveat: No discussion of how this changes pricing, support, or GTM strategy. Also, no mention of how specifications are versioned, evolved, or governed when the implementation is no longer the source of truth. | Implication: For Ken's content/business strategy: this is a major shift in value capture for infrastructure companies. If implementations become commoditized, competitive moats live in specification quality, ecosystem lock-in, and agent tooling. Also relevant for investing: platforms that can't articulate a simple, reusable spec will struggle in an agent-driven world. | Timestamp: timestamp unavailable

Detailed Brief

Core Thesis: From Reusing Implementations to Reusing Specifications

• Claims: By 2026, coding agents will retire traditional software platforms because bespoke implementations generated on-demand will replace general-purpose ones.; Reuse will move upstream: instead of reusing a general-purpose implementation (library, framework, platform), engineers will reuse a specification and derive bespoke implementations from it.; Resonate has multiple SDKs (TypeScript, Python, Rust, Go, Java) and a server implementation; their value now lives in the specification/protocol, not the code artifacts.
• Evidence: Resonate is partnering with infrastructure providers (e.g., Synadia/NATS.io) to bring durable execution natively to their stacks.; The question changed from 'Can we build a server?' to 'Can we repeatedly synthesize trusted servers from the same specification?'
• Caveats: No timeline evidence for the 2026 prediction; it's a working theory, not a validated forecast.; No discussion of how this applies to domains outside infrastructure (e.g., application logic, UIs, or less well-specified systems).
• Implications: For Ken's investing lens: platforms that cannot articulate a simple, abstract specification will be disrupted. The moat shifts from code quality to specification quality and agent tooling.; For Ken's AI ops: this validates the agent-as-compiler mental model—where specs are high-level code and implementations are compilation targets.

The Failed First Attempt: Abstract Spec to Concrete Implementation

• Claims: Resonate initially asked an agent to build a Rust server on Postgres directly from an abstract specification.; The agent failed: the gap was too large, and the generated system broke on concurrency, process failure, and network failure.; The agent generated a prototype that passed happy-path tests but was not production-ready.
• Evidence: Explicit mention: 'The agent generated a system that worked on the happy path. It passed the basic tests. But it was not correct.'; The implementation 'broke on concurrency, broke on process failure, broke on network failure.'
• Caveats: No details on which agent/model was used, prompt engineering strategies, or whether other approaches (e.g., step-by-step prompting) were tried.; Unclear how much of the failure was due to agent limitations vs. insufficient specification detail.
• Implications: For Ken: this is a cautionary tale for agent-driven infrastructure. Happy-path correctness is easy; edge-case correctness (concurrency, failure handling) is where agents currently fail without scaffolding.; For Ken's workflow: direct spec-to-code may work for deterministic, non-distributed logic but is insufficient for stateful, concurrent systems.

The Amended Process: Inserting a Concrete Specification Artifact

• Claims: Resonate inserted an intermediate artifact—a concrete specification—between abstract spec and implementation.; For Postgres, the concrete spec made target-specific decisions explicit: data schema, indices, SQL queries, transaction boundaries.; With this concrete spec, the agent was able to implement a production system.; However, humans were still the main driver of the design; the agent only helped build, not design.
• Evidence: 'Once those decisions were written down, the agent was indeed able to implement a 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.'
• Caveats: No discussion of how much iteration was required to write the concrete spec or how much domain expertise was needed.; This approach worked for Postgres but required re-doing the concrete spec for each target (NATS.io, etc.), limiting reusability.
• Implications: For Ken: codifying architectural decisions is a forcing function for correctness and agent success. The act of writing the concrete spec surfaces implicit assumptions.; For Ken's agent systems: agents can translate well-specified designs into code, but without moving them upstream into design, you're still human-bottlenecked on the hard problems.

The Breakthrough: Deterministic Simulation as Executable Design

• Claims: For NATS.io, Resonate changed the question: 'What does the agent need in order to design the system first and build the system second?'; They gave the agent access to a deterministic simulation environment and a new task: build a simulated implementation, not a production system.; The simulation is 'executable design'—its purpose is to discover correct algorithms under partial order and partial failure.; The new four-stage process: abstract specification → simulation implementation → concrete specification → production implementation.; This moved agents upstream; humans are still involved, but the agent is now the driver.
• Evidence: The simulation environment is in Python and models NATS.io primitives: queues, key-value store (versioned, with stale reads), delayed messages.; The simulated key-value store uses a deterministic random generator to inject stale reads, exposing the complexity real platforms hide.; '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.'
• Caveats: No details on how much effort was required to build the simulation environment or how much of it was reusable across targets.; Unclear how the agent was prompted/guided to use the simulation effectively; humans may still be heavily involved in setting up the simulation harness.
• Implications: For Ken's AI ops: deterministic simulation is a high-leverage tool for agent-driven correctness. It turns opaque distributed failures into debuggable, reproducible scenarios.; For Ken's investing thesis: infrastructure companies that provide agent-friendly simulation/testing harnesses will have a GTM advantage in an agent-driven world.

The 'Forbidden Fruit' Technique: Exposing Hidden Causality

• Claims: The simulation exposes 'forbidden fruit'—information the real platform hides, like whether a read was stale and what the actual latest value was.; Production code cannot depend on this information, but agents can use it for debugging.; Trace events record not just the result but the type of read (fresh/stale), the value returned, and the latest value that was hidden.; This lets agents understand why an algorithm failed: 'the invariant failed because the algorithm made a decision from a stale view of the world.'
• Evidence: Example trace event: production code sees 'promise was pending,' but simulation records 'stale read, you got pending, but latest was 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.'
• Caveats: This requires careful design: you must ensure the 'forbidden fruit' information is only used for debugging, not baked into the algorithm itself.; No discussion of how the agent was prevented from depending on this information in the production code.
• Implications: For Ken: this is a novel debugging pattern for agent-driven systems. The key insight is that agents need causal explanations, not just error messages, to iterate effectively.; For Ken's content: 'forbidden fruit debugging' is a reusable concept—expose information in test/simulation that is unavailable in production to make failures explainable.

Distributed Systems Realities: Stale Reads and Optimistic Concurrency

• Claims: NATS.io's key-value store is versioned; most reads are fresh, but sometimes reads are stale.; Stale reads are not bugs—they are valid under the consistency model of the target platform.; You don't know a read was stale until you try to write; writes enforce optimistic concurrency and fail if the version has moved on.; Building correct applications on top of eventual consistency with stale reads is hard for humans and agents alike.
• Evidence: Example: create key with 'foo' (v0), update to 'bar' (v1), update to 'bas' (v2). A stale read returns 'foo' (v0) even though latest is 'bas' (v2). When you try to update v0, the write fails because the key is already at v2.; 'Building always correct applications on top of a concurrency model that allows occasional stale reads is not simple. Not for humans. Not for agents.'
• Caveats: No discussion of alternative consistency models (strong consistency, linearizability) or why NATS.io's model was chosen.; Unclear how frequently stale reads occur in practice or whether there are tuning knobs.
• Implications: For Ken's AI ops: eventual consistency is a major challenge for agents. Without simulation, agents will write algorithms that appear correct under happy-path strong consistency but break in production.; For Ken's workflow: if you're building on eventually consistent systems (most cloud primitives), you need simulation harnesses that inject stale reads, not just unit tests.

Minimalism and Simplicity as Preconditions for Agent Success

• Claims: Minimalism and simplicity are not the starting point—they are the finish line.; Resonate spent three years simplifying its protocol, repeatedly asking: 'What can we take away?'; The result is a very small protocol centered on two objects: durable promise and durable task.; Simplicity matters because even simple concurrent distributed protocols have complex state and behavior spaces.
• Evidence: 'Every time we ran into a problem, we ask: what can we take away? What abstraction can we erase? What property can we remove? What relationship can we break?'; NATS.io primitives: queues, key-value store, delayed messages—'These are not resonate concepts. These are the concepts of the target platform.'
• Caveats: No details on what was removed or what the protocol looked like before simplification.; Simplicity may trade off against expressiveness or performance—no discussion of these trade-offs.
• Implications: For Ken's investing lens: protocols/platforms designed for agent generation will outcompete those that aren't. Simplicity is a competitive moat in an agent-driven world.; For Ken's content: this validates the 'worse is better' philosophy—agent-friendly systems are minimal, not maximal. Complex, feature-rich platforms will be harder to agent-ify.

Results: Agents Designed and Built Production Systems on NATS.io

• Claims: Using the four-stage process, the agent built a proof-of-concept in the deterministic simulator, verified by fuzz testing.; From the proof-of-concept, the agent derived a concrete specification where the algorithm correctness was already known.; From the concrete spec, the agent derived a production implementation.; This closed the gap: agents now participate in design, not just implementation.
• Evidence: '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 FOSS testing. From the proof of concept, the agent derived a concrete specification, where we already knew the algorithm was correct. And like before, from the concrete specification, the agent derived an implementation.'
• Caveats: No specifics on iteration counts, human interventions, or edge cases that still required manual fixes.; Unclear how generalizable this process is to other infrastructure targets or less well-defined domains.
• Implications: For Ken: this is a validated, production-deployed methodology for agent-driven infrastructure engineering. It's not a research prototype—it shipped.; For Ken's workflow: the four-stage process is a reusable framework. The simulation layer is the key innovation.

Notable Concepts & Terms

• Durable Execution Platform: Resonate's core product; ensures workflows survive failures (process crashes, network partitions) by durably persisting execution state. Think Temporal, but with a focus on minimalism.
• Abstract Specification: A specification that does not assume any implementation details (no database schema, no consistency model, no concrete primitives). It's purely logical. The goal is reusability across many target platforms.
• Concrete Specification: A target-specific specification that makes implementation decisions explicit: schema, indices, queries, transaction boundaries. It bridges the gap between abstract spec and production code.
• Executable Design: The simulated implementation is not the product; it's a design artifact that discovers correct algorithms under partial order/failure before committing to production code.
• Forbidden Fruit Debugging: Exposing information in simulation that the real platform hides (e.g., whether a read was stale, what the latest value was). Agents use this for debugging but cannot depend on it in production algorithms.
• Deterministic Simulation: A test environment where all randomness (e.g., stale reads) is controlled by a deterministic seed, making failures reproducible and debuggable. Critical for agent-driven concurrency correctness.
• Stale Reads: In eventually consistent systems, a read may return an old version of the data even though a newer version exists. Not a bug—it's a valid behavior under the consistency model. The challenge is building correct algorithms on top of this.
• Optimistic Concurrency Control: NATS.io key-value store uses versioned writes; updates only succeed if you're writing to the latest version. If the version has moved on, the write fails, forcing a retry.
• NATS.io: An open-source messaging system (by Synadia) designed for modern distributed systems. Provides primitives: queues, versioned key-value store, delayed messages.
• Durable Promise / Durable Task: The two core objects in Resonate's protocol. Promises represent async results; tasks represent work to be done. Durability means they survive failures.
• Four-Stage Process: The methodology: abstract specification → simulation implementation → concrete specification → production implementation. This moves agents upstream into design.

Operator Notes / Why Ken Should Care

• For Ken's agent systems playbook: the four-stage process (abstract spec → simulation → concrete spec → production) is a validated framework for building production infrastructure with agents. The simulation layer is the key unlock—it turns opaque distributed failures into debuggable, reproducible scenarios.
• For Ken's investing thesis: platforms that can't articulate a simple, abstract specification will struggle in an agent-driven world. Competitive moats shift from code quality to specification quality, agent tooling, and ecosystem lock-in. Resonate's bet is that the protocol is the product.
• For Ken's content strategy: 'forbidden fruit debugging' is a reusable pattern. Expose causal information in test environments that is unavailable in production so agents can understand why algorithms fail, not just that they fail. This is critical for iterating on distributed systems correctness.
• For Ken's AI ops: deterministic simulation is high-leverage for agent-driven correctness in concurrent/distributed systems. Without it, agents will write algorithms that pass happy-path tests but break under edge cases (stale reads, race conditions, partial failures).
• For Ken's GTM / workflow automation: if you're building on eventually consistent primitives (most cloud services), you need simulation harnesses that inject real-world behaviors (stale reads, network delays, etc.), not just unit tests. This applies to workflow orchestration, state management, and distributed task execution.
• Strategic implication: Resonate's approach validates the 'specification as product' model. If implementations become commoditized by agents, value accrues to reusable specs, agent-friendly tooling, and ecosystem partnerships. This has implications for how infrastructure companies price, support, and evolve their offerings.

Watch Map

• timestamp unavailable: Introduction: coding agents will retire platforms by 2026; the prompt becomes the platform, the specification becomes the product.
• timestamp unavailable: The failed first attempt: abstract spec to concrete implementation on Postgres failed due to concurrency/failure handling.
• timestamp unavailable: The amended process: inserting a concrete specification artifact enabled production systems but kept humans as the main design driver.
• timestamp unavailable: The breakthrough: deterministic simulation as executable design; the four-stage process moves agents upstream into design.
• timestamp unavailable: Deep dive on NATS.io: stale reads, optimistic concurrency, and why distributed correctness is hard for agents.
• timestamp unavailable: The 'forbidden fruit' technique: exposing hidden causality (fresh vs. stale reads, latest values) in simulation for agent debugging.
• timestamp unavailable: Results: agent-designed and built production systems on NATS.io via the four-stage process.
• timestamp unavailable: Closing thesis: minimalism and simplicity are the finish line; the specification is the product; agents participate in design, not just implementation.

Source/Metadata

• Title: The Prompt is the Platform - Dominik Tornow, Resonate HQ
• Transcript words: 3869
• Duration seconds: 1053
• Timestamp note: Timestamps were unavailable in the transcript; watch_map notes are logical chapter markers based on content flow.