The 3 Pillars of Autonomy – Michele Catasta, Replit

How do you build a coding agent for someone who cannot evaluate its technical decisions? That is Replit’s starting problem. Since the first Replit Agent launch in September of the preceding year, Michele Catasta’s team has pursued autonomy because its users cannot be expected to supervise software development.

Low-latency coding assistance keeps an expert in the loop: prompt, inspect the change, accept or reject it, and continue working. But slower interactions can fall into swyx’s semi-async valley of death—too slow to preserve concentration, yet insufficiently autonomous to let the user delegate and leave. Catasta describes Replit moving through that valley toward agents that run for several hours. A missing dimension remains: whether the person waiting for the result knows how to intervene when something goes wrong.

The driving comparison makes that distinction concrete. Tesla FSD represents supervised autonomy: a licensed driver sits at the wheel to handle exceptional situations, even if the system handles nearly all ordinary driving. Many coding agents make the same assumption about their users’ technical expertise. Replit instead wants the Waymo experience: the user sits in the back, needs no driving license, and has no steering wheel to take over. Knowledge workers should be able to specify what they want without deciding how the software must be built.

The progression began with IDE completions and assistance, often using feedback loops shorter than a minute and requiring constant supervision. Early agents then used ReAct to combine reasoning and actions on top of language models. Provider investment in native tool calling enabled a subsequent generation. Catasta places a third generation at roughly an hour or more of coherent autonomous work; Replit Agent 3, launched a couple of months before the talk, exemplifies that stage. The important change is not merely continuing to execute, but remaining coherent across a long task.

Autonomy need not mean a long runtime or a loss of user control. Agent 3’s scope of responsibility is taking the technical decisions. A broad request can therefore create a long interval between user interactions, while a narrow request can still be autonomous and fast. The user controls what gets built; the agent handles how it gets built.

That makes elapsed runtime a poor badge of achievement. Every task contains some minimum, irreducible amount of work, performed through a loop of planning, implementing, and testing. Catasta describes the target as “maximize the reducible runtime,” defining it as a span during which the agent accomplishes the task without requiring technical decisions from the user. The practical objective is a capable technical collaborator that absorbs complexity while leaving the user free to shape the result.

Three capabilities support that responsibility:

• Frontier-model capability: the baseline intelligence inside the main agent loop. Replit builds on the work of model providers rather than treating model development as the subject of this talk.
• Verification: checks for local correctness at each step. Without them, small mistakes accumulate until later work rests on broken foundations. The aspiration is high reliability, not a measured reliability rate supplied here.
• Context management: preservation of global coherence. The agent must retain the user’s intent and expectations while tracking both the overall goal and its current task.

Verification prevents the agent from confidently extending a mistake; context management prevents it from correctly completing work that no longer serves the goal.

A generated application can look finished while containing painted doors: buttons with no connected handler, or screens displaying mock data instead of database records. The same incompleteness appears in backend components, even when it is less visible. Catasta reports that Replit’s internal evaluations found more than 30% of individual features broken when first connected by the agent. He also reports that almost every application contained at least one broken feature. These are internal findings; the talk supplies no sample size or evaluation protocol.

Users rarely inspect every button and field, so these failures often arrive as surprises that undermine trust. Asking nontechnical users for feedback does not solve the problem: they cannot reliably provide the technical observations an agent needs. They can click through an interface, but that work is tedious. Replit’s first agent release relied on this kind of manual quality assurance, and the team found that users did not want to spend their time testing.

Autonomous testing changes the source of feedback. The agent can gather observations from the application without waiting for a person, catch small errors before they compound, and check whether an asserted completion actually happened. This last check matters when frontier models leave work unfinished or hallucinate a successful result: a claim in the conversation is not evidence from the running application.

Verification methods expose different kinds of failure. Static analysis and execution provide a starting point, but neither establishes that a complete user workflow works. Generated unit tests check individual behavior; API tests reach endpoints. Browser interaction extends verification to the application the user actually encounters.

For web applications, the distinction between computer use and browser use is especially useful: one interacts through the visible interface, while the other can use programmatic access to the document structure.

Replit combines these channels and generates applications that are amenable to testing. Its primary path is programmatic interaction: inspect the database, read logs, make API calls, and click through the application. Screenshots and computer use provide a fallback when other approaches fail. Together, these observations give the agent enough feedback to continue implementation and repair the painted doors it encounters.

A browser agent can expose generic tools for opening a tab, clicking, and filling a form. Catasta uses Stagehand as an example of this tool-oriented approach. The difficulty is enumerating the long tail: even a tool collection that hypothetically covers almost all interaction types can miss an application’s unusual gestures or workflows. This is a comparison of interaction designs at the time of the talk; current Stagehand also supports deterministic locator interactions.

Replit instead has the agent write Playwright code directly. Catasta’s experience is that LLMs are good at generating it, and a programming language offers more expressive combinations than a fixed menu of browser tools. A test can combine navigation, input, clicks, and assertions into a single executable workflow.

For example, a task-list application’s Add button should do more than make a row appear temporarily. A useful Playwright test can add a named task and reload the page to check whether it remains:

import { test, expect } from '@playwright/test';

test('a newly added task survives reload', async ({ page }) => {
  const taskName = `Review launch checklist ${Date.now()}`;

  await page.goto('http://localhost:3000');
  await page.getByRole('textbox', { name: 'New task' }).fill(taskName);
  await page.getByRole('button', { name: 'Add task', exact: true }).click();

  await expect(page.getByText(taskName, { exact: true })).toBeVisible();
  await page.reload();
  await expect(page.getByText(taskName, { exact: true })).toBeVisible();
});

This example checks a visible outcome across a reload; a database observation would answer the separate question of where the task was stored. Once saved, the script can be rerun after subsequent changes. The agent’s testing work therefore accumulates into a regression suite instead of disappearing as a one-time sequence of interactions.

Catasta reports that Replit’s combined testing approach is roughly an order of magnitude cheaper and faster than computer use. The Agent 3 launch announcement gives a different speed figure—3× faster and 10× more cost-effective—and the comparison conditions are not documented well enough to reconcile the two. The engineering motivation is nevertheless clear: verification must be affordable enough to repeat, and fast enough not to dominate the user’s wait.

Catasta reports that, in Replit’s experience, most tasks—including ambitious ones—can be accomplished within a 200,000-token context window using context management. His argument is that autonomous agents do not need to wait for windows containing tens or hundreds of millions of tokens. The relevant capability is managing state across the trajectory, not retaining every observation in the active prompt.

State can live in several places outside that prompt:

• The codebase: the current implementation records decisions and completed work.
• Documentation: explanations written alongside code preserve information the agent may need later.
• Plans and task lists: persisted descriptions retain the overall objective and unfinished work.
• Filesystem memories: notes can be stored and read back when the agent judges them relevant.

Catasta credits Anthropic with advocating this last pattern. External storage gives the agent a way to preserve information without paying for all of it in every active context.

As an example of sustained work, Catasta cites Anthropic’s report that Claude Sonnet 4.5 maintained focus for more than 30 hours on complex multistep tasks. That is a vendor observation, rather than a standardized task-duration benchmark. He also mentions OpenAI results on mathematics without identifying a specific model or experiment. Together, these examples motivate his view that coherent long execution is already possible; the next question is how to organize the context that supports it.

A subagent gives the main loop a fresh workspace for a bounded concern. Its context does not need to inherit the entire conversation. The agent builder selects the information required for that particular task, lets the subagent finish, and brings the result back into the main loop:

1. Invoke a subagent from the core loop.
2. Supply a fresh context containing the smallest useful subset of information.
3. Let the subagent complete its assigned work.
4. Return its result to the core loop and continue.

This is separation of concerns applied to model context: detailed intermediate work can remain local to the task that needs it.

Catasta’s production plot shows Replit Agent’s “memories per compression” rising from roughly 35 to 45, and more recently 50, after introducing a new subagent orchestrator. He associates the change with less context pollution and less frequent recompression. The talk does not define the metric’s counting unit, so the plotted values are best read as Replit’s operational signal of improved context handling.

For testing, subagents became more than a cost optimization. Replit began automated testing before its orchestration architecture was mature. When the main loop both generated code and performed browser actions, the resulting stream mixed code changes with browser operations and observations. Catasta says that this heterogeneity confused the agent. The Playwright framework alone was not enough; testing also needed its own context.

The resulting boundary is explicit. The main agent decides when its output needs verification. A subagent performs the testing, then its context is discarded. In the architecture described in the talk, only the last observation returns to the main loop. The coding agent gets feedback on its work without carrying the full browser interaction history into every subsequent decision.

An agent can be capable of long autonomous work and still offer an unengaging experience. The user writes a long prompt, watches it become a task list, leaves for lunch, and returns hoping the work is finished. Catasta introduces parallelism primarily as a way to shorten that wait, rather than as something that inherently makes each agent more capable.

The trade is familiar from computing: use additional compute to reduce elapsed time. Parallel agents may repeatedly gather and process the same context; Catasta offers roughly 80% shared context per agent as an illustrative estimate. Their outputs also need integration. An expert developer might resolve merge conflicts, but Replit cannot hand that job to users who do not know what a merge conflict is.

Several workloads make the extra compute attractive:

• Testing alongside implementation: even optimized testing is slow, so making it the only active work can stall visible progress.
• Asynchronous information gathering: another process can collect useful information and inject it into the main coding loop.
• Multiple trajectories: when the budget permits, the system can explore alternative attempts at the same time.

But the common user-as-orchestrator pattern leaves the coordination work with the person: mentally decompose the request, dispatch tasks into separate threads, and reconcile the results. That last step can be difficult even with capable developer tools.

Replit’s direction for its next agent version is to move orchestration into the code loop. The agent would determine subtasks and choose parallelism dynamically, rather than requiring the user to design the execution plan. That removes another technical responsibility from the person requesting the software.

Task decomposition also provides an opportunity to reduce conflicts before they happen. The orchestrator can choose work boundaries that keep subagents from modifying the same things. Catasta does not claim that this eliminates every merge conflict: corner cases remain, and combining parallel work is still an engineering problem. Code-loop orchestration is presented as Replit’s main bet for the coming months, not as a completed capability. The intended endpoint is an agent that owns both the technical work and its coordination, while the user continues to direct what the software should accomplish.