From Interactive to Autonomous

Every LLM-powered system sits somewhere on a five-level autonomy spectrum, distinguished by who decides the next action and when execution stops.

Level 0 — Manual prompting. A human writes a prompt, reads the response, writes the next prompt. The system has no memory between sessions and no ability to act on external systems. ChatGPT's default mode operates here: stateless, reactive, bounded by a single conversation turn. The human provides all context, all judgment, and all execution control. Throughput is limited by human typing speed and reading speed — roughly 1-3 meaningful exchanges per minute for technical tasks.

Level 1 — Turn-based. The agent proposes an action — a code edit, an API call, a shell command — and waits for human approval before executing. Cursor's default agent mode works this way: it suggests a file edit, the developer accepts or rejects, and only then does the next step proceed. The agent has tool access and can observe the results of its actions, but every side effect requires human consent. Latency per step is dominated by human review time (median 8-15 seconds per approval in developer tooling studies), which caps throughput at roughly 4-7 actions per minute (Mozannar et al. 2024). The human is still in the loop for every decision, but the agent handles execution mechanics — looking up API documentation, writing boilerplate, running tests. The labor split shifts: the human becomes a reviewer rather than an author.

Level 2 — Goal-based. The agent receives a goal ("resolve this GitHub issue"), plans a sequence of actions, and executes them without per-step approval. It stops when it detects the goal is met or when it hits a predefined failure budget. Devin, SWE-agent, and OpenAI Codex operate here. The critical addition is an automatic stop condition — a test suite passing, a linter returning zero errors, or a maximum step count reached. Without an explicit stop condition, goal-based agents burn tokens indefinitely: a 200-step debugging loop at gpt-4o rates costs roughly $2-4 in a single run. Goal-based agents also introduce a new failure mode: the agent believes the goal is met when it is not. A code agent that patches a test to pass (rather than fixing the underlying bug) has technically met its stop condition. Evaluation infrastructure — external test suites, mutation testing, human spot-checks — becomes essential.

Level 3 — Proactive (event-driven). The agent monitors an event stream — webhook deliveries, database changes, queue messages — and activates when a relevant event arrives. No human initiates the run. A GitHub issue triage bot that labels incoming issues within 30 seconds of creation operates at this level. The agent is always listening but only acts when triggered. The shift from Level 2 is subtle but architecturally significant: the agent no longer needs a human to formulate a goal. The goal is implied by the event type — an issues.opened event implies "triage this issue," a pull_request.opened event implies "run initial review checks." The agent maps event types to goals through a dispatch table maintained by engineers. Proactive agents require webhook infrastructure, signature verification, idempotency guarantees, and always-on hosting — none of which Level 2 systems need.

Level 4 — Fully autonomous. The agent runs continuously, self-directs its priorities, and manages its own scheduling. It decides what to work on, when to escalate, and when to pause. Production examples are rare and tightly scoped: autonomous trading systems, self-healing infrastructure agents that detect drift and remediate without tickets, and continuous security monitoring agents that scan for vulnerabilities and apply patches. The autonomy is real but bounded — these systems operate within hard constraints (maximum trade size, approved patch categories, restricted network access) that prevent unbounded action.

The practical ceiling for most production deployments today is Level 3. The gap between Level 3 and Level 4 is not primarily technical — it is a trust and liability problem. When an autonomous agent merges a bad PR at 3:00 AM, the question "who is responsible" has no clean answer.

The DAPER cycle

Autonomous agents follow a five-phase execution loop that maps cleanly to control theory's sense-plan-act cycle, extended with explicit reporting. Every agent run — whether triggered by a webhook, a cron schedule, or a queue message — follows this sequence.

Detect. A trigger fires: a webhook arrives, a cron schedule ticks, a database row changes, a queue message appears. The agent wakes up. Detection is passive — the agent does not poll. The infrastructure (webhook server, cron daemon, message broker) handles event delivery. The agent's detection logic validates that the event is relevant (correct event type, correct repository, not a duplicate) and extracts the minimum information needed to proceed: an issue number, a PR URL, a deployment ID.
Analyze. The agent fetches context beyond the raw trigger. A GitHub issues.opened event contains a title and body, but the Analyze phase pulls the repository's recent commit history, existing labels, contributor list, similar open issues (via embedding search over historical issues), and the project's labeling conventions. Enrichment transforms a 2KB webhook payload into a 20-50KB context package. This phase dominates latency for triage agents: 200-500ms for API calls to GitHub, the vector database, and any internal knowledge bases. The quality ceiling of the agent's output is set here — an agent that skips enrichment and works from the raw event alone achieves roughly 62% label accuracy versus 89% with full context (Yang et al. 2025).
Plan. Given the enriched context, the agent decides what to do. This is the LLM-heavy phase — reasoning over the context to produce a concrete action plan. For a triage bot: determine the correct labels (from the repository's label set, not invented), estimate priority based on keywords and reporter history, decide whether to assign to a specific engineer or to the on-call rotation, and draft an informational comment. The plan is typically structured output — a JSON object with fields for each action — not free-text. Structured output reduces downstream parsing errors from ~15% (free-text extraction) to <1% (JSON mode with schema validation) (OpenAI 2024).
Execute. The agent carries out the plan: applies labels via the GitHub API, posts a comment, assigns a reviewer, updates an internal tracker. Each action is a discrete, retriable operation. Execution order matters — post the comment before assigning the reviewer, so the reviewer sees context when they receive the notification. Failures at this stage are typically transient (rate limits, network timeouts) and handled by retry policies with exponential backoff.
Report. The agent notifies stakeholders of what it did: a Slack message to the team channel, a structured log entry, a status update on the issue itself. Reporting is not optional — silent agents erode trust faster than incorrect agents. A triage bot that labels 50 issues correctly but never tells anyone is indistinguishable from one that is broken. Reports include what the agent did, why (a one-sentence justification), and what it is uncertain about (flagged items for human review).

The DAPER cycle runs once per event. A single agent may execute thousands of cycles per day, each independent. The cycle is also the unit of observability: trace IDs attach to a single DAPER execution, making it straightforward to debug individual runs.

Event-driven vs. schedule-driven

Event-driven agents respond to external stimuli in near-real-time. A Slack support bot processes messages within 1-3 seconds of arrival. The latency budget is tight: users expect sub-5-second responses in chat contexts, which constrains model choice (streaming gpt-4o-mini at ~50 tokens/s versus o3 at ~15 tokens/s). Event-driven agents must handle bursts — a popular open-source repo might receive 30 issues in an hour during a release, and the agent must process each within its SLA.

Schedule-driven agents run on cron intervals: every 6 hours, every Monday at 09:00 UTC, every 15 minutes. A deployment readiness checker that scans staging environments overnight is schedule-driven. The latency budget is relaxed — a 30-second execution time is invisible inside a 6-hour interval. Schedule-driven agents trade immediacy for simplicity: no webhook infrastructure, no signature verification, no always-on HTTP server. They need state tracking to avoid reprocessing — a high-water mark (timestamp of the most recent processed item) or cursor-based pagination.

The choice is architectural, not cosmetic:

Event-driven agents need webhook infrastructure, signature verification, and idempotency guarantees
Schedule-driven agents need state tracking to avoid reprocessing (high-water marks, cursor-based pagination)
Hybrid agents combine both: a cron job that polls for missed webhooks (GitHub's webhook delivery log API exposes failed deliveries), or a webhook handler that defers expensive work to a scheduled batch

Most production systems are hybrid. A triage bot handles issues.opened events in real-time (event-driven) but runs a daily sweep for issues that were opened during an outage and never received a webhook (schedule-driven).

The trust gradient

Production autonomous agents do not launch at full autonomy. They follow a graduated trust model, analogous to how organizations onboard new employees: start with read-only access, earn write access through demonstrated competence, and gain broader permissions over time.

Phase 1 — Read-only observation (1-2 weeks). The agent processes events and logs what it would do, but takes no action. Every incoming issue produces a log entry: "would apply labels [bug, backend], would assign to @alice, confidence 0.87." Engineers review these logs daily, comparing the agent's decisions to what they would have done. Metric: agreement rate. Target: >90% before advancing.
Phase 2 — Guarded execution (2-4 weeks). The agent acts, but only on low-risk operations (adding labels, posting informational comments). High-risk actions (closing issues, merging PRs, modifying infrastructure) require human approval via a Slack prompt. The approval flow: agent posts "I want to close issue #423 as duplicate of #401. Approve?" with Accept/Reject buttons. Approval latency (median 4-12 minutes during business hours) is acceptable for non-urgent actions. Metric: zero critical errors (wrong issue closed, wrong PR merged).
Phase 3 — Autonomous with guardrails (ongoing). The agent executes most actions independently. Guardrails enforce boundaries: maximum number of issues closed per hour (circuit breaker at 10x normal rate), restricted API scopes (no repo deletion, no org-level changes), mandatory cooldown periods between destructive operations (30 seconds between issue closures). Anomaly detection flags unusual patterns — an agent that suddenly labels every issue as critical triggers an alert and pauses.
Phase 4 — Full autonomy with audit (ongoing). The agent operates independently. All actions are logged to an immutable audit trail (append-only database table or event stream). Periodic human review (weekly, then monthly) checks for drift — gradual degradation in accuracy that automated metrics miss because the agent's errors are plausible.

Each phase transition requires evidence. The gradient is a ratchet — autonomy increases monotonically unless a failure triggers a rollback to a more restricted phase.

Production examples

GitHub issue triage. Incoming issues hit a webhook endpoint. The agent classifies by component (frontend, backend, infra), estimates severity from the description and reporter history, applies labels, and assigns to the on-call engineer for that component. Median processing time: 2-4 seconds. Cost per triage: $0.002-0.005 at gpt-4o-mini rates. A team processing 50 issues/day saves roughly 25 minutes of human triage time daily — modest per-day, but 150+ hours annually. The agent handles the 80% of issues that are straightforward classification; the remaining 20% (ambiguous, cross-cutting, politically sensitive) are escalated.

Slack support bot. Customer questions in a #support channel trigger the agent. It searches a knowledge base (vector similarity over documentation embeddings, top-5 chunks by cosine similarity), drafts a response, and posts it as a thread reply. If confidence is below a threshold (best chunk similarity < 0.78), it escalates to a human with the partial answer attached — giving the human a head start rather than forcing them to research from scratch. Production deployments handle 60-80% of questions autonomously, with human agents reviewing escalations (Intercom 2025). Cost per response: $0.003-0.01. Average resolution time drops from 45 minutes (human-only) to 3 minutes (bot-handled) for the autonomous tier.

Deployment pipeline agent. A merge to main triggers the agent via a push webhook. It runs the test suite, checks for migration conflicts, verifies environment variable parity between staging and production, validates that the Docker image builds successfully, and either promotes the build to production or posts a detailed failure report as a GitHub comment on the merge commit. The agent replaces a 15-step manual runbook that previously required a senior engineer and 20-30 minutes. On failure, it creates a GitHub issue with the failure context, links it to the commit, and assigns the PR author — turning a "check Slack for deploy status" workflow into a structured notification.