Autonomous & Headless Agents — Core

Why

The autonomy spectrum has five levels defined by who controls execution. Level 0 is manual prompting where the human controls everything. Level 1 is turn-based where the agent proposes actions but waits for human approval before executing. Level 2 is goal-based where the agent receives a goal and executes autonomously until an evaluator confirms completion or a budget is hit. Level 3 is proactive or event-driven where the agent monitors an event stream and activates when a relevant event arrives without human initiation. Level 4 is fully autonomous where the agent self-directs priorities and manages its own scheduling. The practical ceiling for most production deployments is Level 3. The gap between Level 3 and Level 4 is primarily a trust and liability problem, not a technical one. The other options describe different taxonomies that do not map to the autonomy spectrum: model adaptation, coordination patterns, and learning paradigms are separate dimensions entirely.

Why

The DAPER cycle is the standard execution loop for autonomous agents. Detect: a trigger fires such as a webhook, cron tick, or queue message. Analyze: the agent fetches context beyond the raw trigger, enriching a 2KB webhook payload into a 20-50KB context package. Plan: the agent uses the LLM to reason over the enriched context and produce a concrete action plan as structured output. Execute: the agent carries out the plan through API calls, applying labels, posting comments, or triggering deployments. Report: the agent notifies stakeholders of what it did, why, and what it is uncertain about. The DAPER cycle runs once per event, and a single agent may execute thousands of cycles per day. Each cycle is also the unit of observability, with trace IDs attaching to a single execution. The other options describe data pipelines, software development lifecycles, and security pipelines, none of which describe the autonomous agent execution loop.

Why

Webhook providers like GitHub retry deliveries when the handler does not respond quickly. GitHub retries after 10 seconds on timeout, and a slow handler that runs agent logic synchronously inside the webhook endpoint will exceed this window, causing GitHub to redeliver the same event. This creates duplicate processing unless the agent implements idempotency checks. The correct pattern is to accept the POST, enqueue the payload for asynchronous processing, and return 200 immediately. The handler should do three things: read the body, enqueue it, and return. Everything else happens asynchronously. The memory footprint argument about threads is a secondary concern, not the primary reason. The HTTP specification does not mandate 100ms response times for POST requests. While deduplication is needed regardless since webhooks guarantee at-least-once delivery, minimizing unnecessary retries reduces the deduplication burden and processing cost.

Why

HMAC-SHA256 signature verification ensures that the webhook payload was sent by the expected platform, such as GitHub, and has not been modified in transit. The platform computes HMAC using a shared secret configured when the webhook was registered, and sends the result in the X-Hub-Signature-256 header. The agent computes the same HMAC over the received body using its copy of the secret and compares using hmac.compare_digest, which is a constant-time comparison that prevents timing attacks. If the signatures do not match, the payload is rejected with 401. HMAC does not compress the payload or reduce bandwidth. It does not encrypt the content; HTTPS handles transport encryption. The signature is not a unique delivery identifier; GitHub provides X-GitHub-Delivery for deduplication. Without signature verification, an attacker could send fake webhook payloads to the agent endpoint, potentially triggering unauthorized actions like label changes, deployments, or issue closures.

Why

The three-plane architecture separates autonomous agent infrastructure into three independent components with distinct scaling characteristics, failure modes, and upgrade cadences. The Routing and Policy plane makes decisions before any LLM call executes, including model selection, credential brokering, tool permissions, and egress policy. The Runtime plane provides the execution environment with guarantees about isolation, durability, and failure recovery through sandboxed execution, durable workflows, retry policies, and output verification. The Intelligence plane contains the LLM-powered reasoning including tool calling, multi-step planning, context management, and output generation. This separation enables independent evolution: Intelligence changes happen weekly, Policy changes monthly, and Runtime changes quarterly. Coupling them would force synchronized releases across all three cadences. No single framework spans all three planes, so production systems compose tools from each one.