An independent product case study for persistent agent infrastructure. This is not an official Dedalus Labs product or roadmap.
Read the original brief (PDF) · Opportunity · PRD · Metrics & experiments · Learning log · 90-day plan · Runnable persistence exercise
Dedalus Machines makes it possible to give an AI agent a persistent Linux computer rather than a disposable sandbox. That unlocks a useful question: when a multi-step agent pauses, fails, or hands work to another process, how should its task state survive—not just its machine?
This case study proposes a thin durable-agent checkpoint contract: a developer can name a checkpoint, attach safe metadata, observe its progress, and resume or recover a task without rebuilding the agent's working context from scratch.
The proposal focuses on developer activation and reliable recovery. It deliberately avoids inventing customer interviews, usage numbers, benchmarks, or shipping commitments.
Dedalus describes Machines as persistent compute for agents, with an API for running work in isolated Linux microVMs. The company’s Product Manager Intern role asks for people who can understand users, make trade-offs, ship with engineering, and improve developer experience. This repository is my attempt to show that work in public.
- Product context: Dedalus Machines
- Role context: Product Manager Intern
- Company context: Dedalus careers
| Artifact | What it demonstrates |
|---|---|
| Opportunity | User problem, assumptions, alternatives, and the product boundary |
| PRD | A scoped v0 proposal, flows, proposed API shape, and non-goals |
| Metrics & experiments | Clear activation and reliability metrics, plus falsifiable tests |
| Learning log | A reproducible plan to learn the product hands-on and record real observations |
| 90-day plan | How I would sequence discovery, build, and launch work in an internship |
| Persistence exercise | A runnable public-SDK exercise that verifies an artifact persists across separate executions |
If developers can safely checkpoint and inspect agent task state at meaningful boundaries, they will recover from interrupted long-running work faster and trust persistent compute for higher-value workflows.
A checkpoint should be a product primitive, not a loose collection of files. It needs a stable identity, an explicit lifecycle, guardrails around sensitive data, observable events, and a recovery path that is understandable at 2 a.m.
The persistence exercise uses Dedalus’s public Python SDK to write and retrieve a small task artifact across separate executions on one Machine.
It requires your own API key. Running with --create-machine provisions infrastructure and may incur cost, so read the instructions and clean up the Machine when finished. Do not publish your key or any customer data.
This is a proposal, not a claim that I have access to Dedalus’s internal systems or data.
- Facts about Dedalus are linked to public sources.
- Product interfaces below are illustrative and clearly marked as proposed.
- The experiment plan contains no fabricated results. Results will be added only after I run and document them.
- I do not assume a particular internal architecture or customer segment without validation.
- Complete the public Machines quickstart and publish observations in the learning log.
- Run the persistence/recovery exercise and record the setup, command, result, and limitations.
- Conduct a handful of consented developer conversations; publish only anonymized themes and the exact research questions.
- Revise the proposal when the evidence disagrees with the thesis.
Sarvesh Tamse · GitHub profile
Feedback is welcome through issues.