Raising an Agent Season 2 - Series
What Is the Computer For Now?
The second season of Amp's documentary podcast follows the team's move from locally managed coding agents to remote-controllable, parallel agents running in isolated environments. The first six episodes cover Amp Neo, ephemeral orbs, verification, production feedback loops, 'jellyware,' software economics, workflow evaluations, operational reliability, and the changing role of personal computers. Episodes 5 and 6 examine broader agent responsibilities, token budgets, specialized runners, and the team's weekly coordination, selective code review, and small, feature-flagged releases.
Episodes Browse 6 summaries 3 of 6
Quinn Slack and Thorsten Ball describe extending agent work beyond implementation into deployment checks, user follow-up, and operations. They also discuss Amp's recent outages and ask whether remotely running agents and task-specific software will make the personal computer less central to their work.
Key Points Covered
- Delegate follow-through, not just code changes: Thorsten recounts an agent coordinating a change across three repositories. Quinn describes longer-lived threads that wait for deployment, identify affected users from feedback and logs, prepare follow-up emails, and monitor feature usage and errors. Their internal plugins provide the necessary access; the email example includes a human send-or-cancel review 02:52–08:55(opens in a new tab).
- Test instructions with cases that should and should not trigger them: Quinn describes generating small evaluations after system-prompt changes, running scenarios across modes and models, and iterating on missed behavior. The same approach can test whether removing an instruction preserves the intended outcomes, rather than letting the prompt grow indefinitely 09:53–11:59(opens in a new tab).
- Preserve the reasons behind changes where agents can retrieve them: The hosts say shared thread history lets agents recover earlier investigations, human intent, shipped fixes, and customer communication—not just commit messages 10:55–13:40(opens in a new tab). They favor one coding-agent product across the team to keep history and production-access configuration consistent. They acknowledge that shared integrations can support multiple products, but say they have not seen this done as well 35:29–37:33(opens in a new tab).
- Test whether agents use new tooling without a reminder: Thorsten adds tooling to check database-change performance in production, which is hard to assess outside production. He then gives agents in fresh orbs—isolated remote execution environments—database tasks without mentioning that tooling. The coordinating agent reads their threads, checks tool selection and parameters, adjusts the setup, and repeats. He does not detail the production safeguards 13:40–17:58(opens in a new tab).
- Separate incident causes from assumptions about agent-written code: Thorsten reports roughly 18–20 incidents over six weeks, grouped into upstream-provider problems, infrastructure issues, and shipped code defects. A storage-node failure required hours of data movement to restore redundancy; code incidents included queries that overloaded the database. Quinn says code defects accounted for about a third of incident count but a smaller share of downtime and affected users. These are the team's retrospective estimates, not a controlled comparison of development methods 20:04–27:11(opens in a new tab).
- Redundancy can change the product contract: Quinn explains that sandbox providers differ in snapshot and resume support. Adding provider failover can force reduced functionality and still leave the problem of recovering an existing environment when its original provider is unavailable. More redundancy therefore adds compatibility and recovery decisions, not just spare capacity 26:09–29:17(opens in a new tab).
- Make operational evidence useful before relying on agents during incidents: Thorsten says misleading error logs can send agents toward the wrong cause, just as they can mislead an unfamiliar human operator. The team is working on actionable logs, access to the same metrics humans use, and explanations of component relationships. Quinn recommends starting outside an active incident: grant log access, investigate errors, fix them, and confirm after deployment that they disappear 32:27–36:33(opens in a new tab).
- Task-specific tools challenge the need for a carefully maintained local desktop: Thorsten contrasts manually scrubbing video and arranging screenshots in a design tool with a teammate's orb-built frame selector that inserts frames into a thumbnail template with a live preview 37:33–41:23(opens in a new tab). Thorsten also describes dictating tasks on a walk and checking the resulting agent threads afterward. These examples lead the hosts to speculate that personal devices may mainly capture input and display results while more work runs remotely 43:20–49:23(opens in a new tab).
- Workflow defaults embody bets about model behavior: Quinn says Amp changed its default for messages sent during a task from queuing—waiting until the agent finishes—to steering—delivering the message at the next available opportunity during work. He argues that steering gives the agent useful input sooner. Some users say their workflows still need queuing, which remains configurable; the hosts predict it will fade 49:23–51:25(opens in a new tab).
Full video: https://www.youtube.com/watch?v=7pstrDQ4xLs(opens in a new tab)
Episode page: https://ampcode.com/podcast/season-02/episode-04(opens in a new tab)