"Keep your Tamagotchi alive" (Yegge)

Steve Yegge's "keep your Tamagotchi alive" framing captures a crucial insight about working with AI agents at L4: they are not fire-and-forget automations.

·Developer role is formally defined as "manager of agent fleet"
·Span of control is measured: how many parallel agents each developer effectively supervises
·Performance evaluation includes agent supervision effectiveness (not just personal code output)

·Span of control target is defined per role (e.g., 3-5 agents for standard developers, 5-10 for senior)
·Agent supervision training is part of standard developer onboarding

Evidence

·Updated role descriptions defining developer as agent supervisor
·Span of control metrics dashboard
·Performance review criteria including agent supervision effectiveness

What It Is

Steve Yegge's "keep your Tamagotchi alive" framing captures a crucial insight about working with AI agents at L4: they are not fire-and-forget automations. A Tamagotchi is the 1990s virtual pet toy that required regular feeding, attention, and care to stay alive - neglect it and it would die. Yegge's point is that AI agents in agentic workflows have the same character: they need ongoing direction, course-correction, and care from the developer supervising them. An agent that has been running for 45 minutes without human check-in has either gotten stuck, gone in a wrong direction, or made a series of small decisions that compound into a large problem.

The Tamagotchi metaphor is precise in ways that less colorful framings miss. Tamagotchis don't break in dramatic ways - they degrade gradually through accumulated neglect. Agents fail similarly: they drift from the intended direction incrementally, making locally reasonable decisions that collectively diverge from what the developer intended. By the time the developer checks in and discovers the drift, undoing the accumulated wrong decisions may be more work than starting fresh. Regular check-ins are not about distrust of the agent - they are about the nature of agentic systems that make sequential decisions under uncertainty.

Yegge introduced this framing in the context of his 8-stage evolution model of developer AI adoption. Stage 6 (multi-agent orchestration) and Stage 7-8 (orchestrator) are where the Tamagotchi dynamic is most acute. At Stages 1-3, agents are short-lived: you ask a question, you get an answer, the interaction is over. At Stage 6+, agents run for extended periods, make many decisions, and accumulate state. The supervision requirement scales with the duration and autonomy of the agent task.

The practical implication is that developers need to build supervision rhythms into their workflow rather than treating agent supervision as an optional check-in when they feel like it. These rhythms - the 15-minute review cadences, the checkpoint structures, the explicit intervention criteria - are the "feeding schedule" for the Tamagotchi. They are not bureaucratic overhead; they are what prevents the accumulated decisions of an unsupervised agent from becoming expensive problems to untangle.

Why It Matters

The Tamagotchi framing reshapes how developers think about agent supervision in ways that improve outcomes:

Prevents costly drift - an agent checked every 15 minutes corrects small deviations before they compound; an agent checked after 3 hours has accumulated 3 hours of decisions built on early misunderstandings that all need to be unwound
Reframes supervision as care, not distrust - developers who think of supervision as "checking up on the agent because it might fail" will under-supervise because it feels like a vote of no confidence; developers who think of supervision as "keeping the Tamagotchi alive" will supervise regularly as natural ongoing care
Calibrates supervision intensity to task risk - not all agents need the same supervision frequency; a Tamagotchi that needs constant attention is a different thing from one that needs daily feeding; agents working on well-defined tasks with high context need less supervision than agents working on open-ended tasks with ambiguous requirements
Makes handoffs explicit - the Tamagotchi metaphor makes clear that agents need a continuous owner, not just an initiator; when a developer starts an agent and then goes into a three-hour meeting, the Tamagotchi is in danger; organizations with mature L4 practices have explicit handoff protocols for when an agent's primary supervisor needs to step away
Normalizes course-correction as part of the job - course-correcting an agent mid-task is not a failure state; it's normal supervisory work, analogous to a tech lead checking in on a junior developer and redirecting them when they've gone down the wrong path; the Tamagotchi framing makes this normal, not exceptional

Tip

Set a 15-minute timer when you launch an agent and make a deliberate check-in the default behavior when the timer goes off. This creates the supervision rhythm before you need it. The timer is especially important when you're new to fleet management and haven't yet developed the instinct for when agents need attention.

Getting Started

Establish your supervision cadence - decide on a check-in frequency based on agent task type. For well-defined tasks with high context: every 20-30 minutes. For open-ended tasks with ambiguous requirements: every 10-15 minutes. For long-running tasks overnight: end-of-day review plus check-in first thing in the morning. Write this down and hold to it.
Define your intervention criteria - what agent behaviors trigger immediate intervention versus can wait for the scheduled check-in? Immediate: agent appears to be in a loop, agent has made a significant assumption that changes the scope, agent has encountered a test failure it doesn't know how to resolve. Scheduled: agent is making progress, minor stylistic decisions that don't affect correctness.
Build a dead-man's switch into long-running agents - for agents that run for more than an hour, build in explicit checkpoint prompts where the agent pauses and summarizes what it has done so far and what it plans to do next. This forces a legible handoff point and gives the supervisor a structured opportunity to course-correct before more work is built on a wrong direction.
Keep a supervision log for complex tasks - for long-running or high-risk agent tasks, keep a brief log: "10:15 - checked in, agent is implementing auth handler, looks correct. 10:30 - agent asked for clarification on session timeout behavior, directed it to use existing SessionManager pattern. 10:45 - agent finished, reviewing output." This log is both a discipline mechanism and a debugging aid if something goes wrong.
Practice the handoff conversation - when you need to step away from a running agent, practice explicitly handing it off: either to a colleague (who becomes the Tamagotchi owner) or by pausing the agent with explicit state documentation so it can be resumed. The handoff should communicate: current task status, any decisions made since launch, known risks or ambiguities, and what the next check-in should verify.
Build supervision cost into sprint planning - if an agent task is estimated at 2 hours of agent compute time, the developer cost is not zero - it's 30-45 minutes of supervision time (check-ins, course corrections, final review). Sprint planning should account for supervision cost, not just agent execution time.

6 steps to get from here to the next level

Common Pitfalls

The set-and-forget failure mode. Developers who launch agents and immediately return to other work for hours, trusting the agent to stay on track, are the most common source of large, expensive messes. The Tamagotchi metaphor exists to prevent this: the agent needs regular attention or it will get sick. Set-and-forget works for narrow, well-tested automation tasks; it doesn't work for agentic workflows that involve open-ended decision making.

Over-supervising and eliminating the throughput benefit. The opposite failure mode is developers who supervise so closely that they're effectively co-piloting rather than managing. If you're watching every agent decision and intervening every few minutes, you're not getting the throughput benefit of agent delegation. Find the rhythm that keeps the Tamagotchi alive without becoming its constant companion.

Not teaching the Tamagotchi what it needs to know before launch. The best supervision is prevention: agents that are well-contextualized before launch make fewer decisions that need course-correction during the run. Investing 10-15 minutes in providing good context before launching an agent is more efficient than 30 minutes of course-correction during the run. Feed the Tamagotchi properly before you put it down.

Confusing checkpoints with micro-management. Checkpoints are structured moments for the developer to review progress and provide direction if needed. They are not the developer taking over the agent's decision-making process. A good checkpoint takes 2-5 minutes and results in either "looks good, continue" or a brief clarification. If checkpoints are taking 20 minutes, the developer is doing the agent's work for it.

Ignoring the organizational dimension. The Tamagotchi metaphor is usually applied to individual agents, but organizations have Tamagotchi dynamics too. An AI adoption initiative that gets attention from leadership one quarter and is deprioritized the next is an organizational Tamagotchi that's not being properly maintained. The same care, direction, and course-correction that agents need individually is also what organizational AI initiatives need from leadership.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob has a developer who launched an ambitious agent task on Friday afternoon - "implement the new reporting dashboard" - and didn't check in until Monday morning. The agent ran over the weekend and produced a substantial amount of code. When the developer reviewed it Monday, they found the agent had made a series of architectural decisions that violated the team's patterns and would require significant rework. The agent had been efficient; the result was not usable.

What Bob should do: Bob should use this as a teachable moment without blame. The developer wasn't negligent - they just hadn't yet internalized the supervision requirement. Bob should share the Tamagotchi framing with the team: agents that run without supervision overnight will drift. For long-running tasks, the team should either break them into smaller tasks that complete within a single developer's working day, or build explicit checkpoints into the agent's task that pause and ask for direction at key decision points. Bob should also establish a team norm: before leaving for the evening with an agent running, the developer should either pause it with a documented state or explicitly scope it to a task that can complete and be reviewed before shutdown.

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been tracking agent task success rates and notices a clear pattern: tasks that run for less than 30 minutes have an 85% success rate; tasks that run for more than 2 hours have a 50% success rate. The duration is correlated with the failure rate, but she's not sure whether it's because longer tasks are harder or because they receive less supervision.

What Sarah should do: Sarah should add a supervision frequency dimension to the analysis: for the tasks that ran for 2+ hours, how often did the developer check in? When she adds this dimension, she will almost certainly find that the failure rate is lower for long tasks with frequent check-ins and higher for long tasks with infrequent check-ins. Duration is not the issue; supervision is. Sarah should use this data to establish a supervision frequency guideline and include it in the AI practices documentation. She should also create a training session specifically on supervising long-running agents, using the Tamagotchi framing to make the supervision requirement memorable.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has internalized the Tamagotchi principle and built it into his workflow systematically. He uses a tmux layout that shows all active agents simultaneously, has 15-minute timer alerts set, and maintains a supervision log for tasks that run more than an hour. He almost never has expensive agent messes to clean up. Colleagues who see his workflow want to replicate it but don't know where to start.

What Victor should do: Victor should share his exact workflow as a setup guide: the tmux configuration, the timer setup, the supervision log template, and his intervention criteria. He should also be explicit about the philosophy: "I think of my agents as Tamagotchis. They need regular attention or they go off track. This isn't a lack of trust in the agent - it's how agentic systems work." Making the philosophy explicit alongside the practice gives colleagues the mental model they need to adapt the approach to their own workflow rather than just copying the implementation details.

What Victor should do - role-specific action plan