WAKE: While Agents Keep Executing

The Problem

1.1 Agents That Work in the Dark

The promise of autonomous AI agents is that they work independently — researching, writing, deciding, building — without requiring constant human attention. This promise is being fulfilled. Today, agents operate continuously, often around the clock, across multiple providers and runtimes.

But a gap has opened between what agents can do and what humans can see. An agent completes a task: where does the output go? An agent reaches a decision it cannot make alone: how does it ask? An agent takes an action that turns out to be wrong: how would the human have known in time to prevent it?

Most current implementations handle this poorly. Outputs arrive in email. Questions surface in Slack. Decisions are made silently. The human discovers what happened — sometimes much later, sometimes after consequences have compounded.

The result is not the calm, confident delegation that autonomous agents promise. It is anxiety. Specifically, the anxiety of not knowing what your agents did while you were not watching.

1.2 The Absence of a Standard

The core issue is the absence of a standard. Every agent, every platform, and every integration invents its own delivery mechanism. This creates three compounding problems:

Fragmentation. A human overseeing agents from multiple providers must check multiple places to understand what their workforce has done. There is no single view, no consistent vocabulary, no shared interaction model.

No Human-Centred Design. Because each agent invents its own delivery mechanism, none are optimised for the human experience. The human adapts to the agent, rather than the agent adapting to the human.

No Accountability Layer. Without a standard delivery mechanism, there is no standard audit trail. When something goes wrong — and eventually something will — it is extremely difficult to reconstruct what an agent did, when, why, and what guidance it received.

1.3 What Is Missing

What is missing is not more powerful agents. It is a simple, open, human-first standard for the moment when an agent needs to surface work to a human — and the moment when the human responds. This is the gap WAKE is designed to fill.

Design Principles

Before specifying the protocol, it is worth establishing the principles that shaped it. These are not technical constraints — they are human ones.

The WAKE Protocol

3.1 Overview

The protocol defines two interactions and three endpoints:

Delivery — an agent posts a structured payload to a designated endpoint, describing the work it has completed, the question it is asking, or the update it is surfacing. It receives a delivery identifier in return.

Response (single) — the human reviews the delivery and responds with one of a small set of structured actions, optionally accompanied by feedback or edited content. The agent retrieves this response by polling GET /wake/v1/response/{delivery_id} or receiving it via webhook.

Response (bulk) — for agents managing concurrent tasks, GET /wake/v1/responses retrieves all outstanding responses in a single request, filtered by agent ID and an optional since timestamp. This replaces per-delivery polling with a single sweep per agent — essential at any meaningful scale.

That is the entirety of the protocol. Everything else — the interface the human uses, the storage layer, the notification mechanism, the audit trail — is an implementation concern, not a protocol concern.

3.2 Delivery

An agent delivers work by sending an HTTP POST request to the designated endpoint.

{
  "agent_id":         "research-agent-01",
  "provider":         "claude",
  "type":             "update | question | output | alert",
  "headline":         "Market research report ready for your review",
  "summary":          "Completed analysis of the top 10 competitors.",
  "details":          // object | string | null — never include credentials,
  "callback_webhook": "https://...",  // optional
  "timeout_seconds":  3600           // optional
}

Success response — 201 Created:

{
  "delivery_id": "550e8400-e29b-41d4-a716-446655440000",  // UUID v4
  "status":      "received",
  "created_at":  "2026-03-08T11:42:00Z"
}

3.3 Response Retrieval

An agent retrieves a human's response either by polling or via webhook callback.

{
  "delivery_id":    "550e8400-e29b-41d4-a716-446655440000",
  "status":         "pending | approved | rejected | redirected",
  "feedback":       "string",         // optional
  "edited_content": null,             // object | string | null
  "responded_at":   "2026-03-08T12:10:00Z"
}

3.4 Agent Behaviour Requirements

A compliant agent implementation must:

1. Post a delivery payload before taking any action that warrants human oversight.
2. Record the returned delivery_id for later response retrieval.
3. Not block indefinitely on a response. Proceed after timeout_seconds with clearly documented assumptions.
4. On receiving rejected, not proceed with the originally proposed action.
5. On receiving redirected, incorporate edited_content and feedback before proceeding.
6. Log all deliveries and responses locally for audit purposes.

3.5 Versioning

The protocol is versioned using a v{major}.{minor} scheme. This document describes v1.0. Implementations should include the protocol version in the endpoint path: /wake/v1/deliver. Breaking changes increment the major version. Additive changes increment the minor version. Implementations are encouraged to support at least one prior major version during transition periods.

Design Decisions and Rationale

4.1 Why Four Delivery Types?

The four delivery types — update, question, output, alert — cover the full range of reasons an agent might surface work to a human, while remaining simple enough to be immediately understood. They also allow implementations to treat different types differently: updates might be archived quickly, while questions might surface more prominently given their need for a response.

4.2 Why a Headline Field?

The headline field exists because first impressions matter. When a human opens an interface showing twenty deliveries, the headline is what they read first. By making it a required field and encouraging positive framing, the protocol nudges agents toward communication that respects the human's attention. An agent that says "Draft proposal ready for your review" is a better collaborator than one that says "TASK_COMPLETE: output_blob_47".

4.3 Why Asynchronous?

Synchronous human-in-the-loop patterns — where agents block waiting for a response — break down at scale. A human overseeing ten agents cannot be expected to respond to each one immediately. Asynchronous delivery means agents can continue working in parallel, humans can respond to deliveries in batches, and the overall system operates more efficiently. The timeout_seconds field exists for cases where a genuinely time-sensitive decision cannot wait indefinitely.

4.4 Why Not Include Authentication?

Authentication is an implementation concern, not a protocol concern. Different deployments will have radically different authentication requirements: a solo operator self-hosting may use a simple API key; a large deployment may require OAuth 2.0 and role-based access control. The protocol specifies what is exchanged, not how access is controlled. Implementations should enforce appropriate authentication for their context.

4.5 Why Only Four Response Statuses?

The four response statuses — approved, rejected, redirected, pending — give the human meaningful choices without creating decision paralysis. More granular statuses introduce ambiguity that agents cannot reliably act on. The feedback field provides the nuance; the status provides the clear instruction.

Security

The protocol operates at the boundary between autonomous agents and human decision-makers. This boundary is a meaningful attack surface. A compromised delivery could trigger a human to approve a harmful action. A forged response could cause an agent to proceed without genuine human authorisation.

5.1 What the Protocol Mandates

Delivery ID Generation

Delivery IDs must be cryptographically random UUID v4 values. Sequential or predictable IDs allow enumeration attacks. Implementations must not use sequential integers, timestamps, or any other predictable scheme.

Transport Security

All protocol traffic must be transmitted over HTTPS. Implementations must not accept or serve protocol requests over unencrypted HTTP in any production context. This applies to both the delivery endpoint and any webhook callbacks.

Webhook Callback Validation

Webhook callback_webhook URLs must be validated against an implementer-controlled allowlist before any response is dispatched. Implementations must not deliver response data to arbitrary URLs. Webhook payloads must be signed with HMAC-SHA256:

import hmac, hashlib

def verify_webhook(secret: str, payload: bytes, signature: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret.encode(), payload, hashlib.sha256
    ).hexdigest()
    # Use constant-time comparison to prevent timing attacks
    return hmac.compare_digest(expected, signature)

Prompt Injection Protection

Delivery details fields may contain untrusted content — including text crafted to manipulate the receiving agent's behaviour. Implementations must handle all content in delivery payloads as untrusted and apply appropriate sanitisation before rendering or passing to downstream systems.

Delivery ID Integrity

Agents must verify that response delivery_id values match identifiers they submitted. This prevents response injection attacks where a malicious actor returns a response to a different delivery than the one the agent is polling for.

5.2 What the Protocol Delegates

Reference Implementation

A reference implementation of WAKE is provided as part of GardenRoom.ai — a hosted platform built on this protocol. GardenRoom provides:

• A compliant /wake/v1/deliver and /wake/v1/response endpoint
• A human-facing inbox interface for reviewing and responding to agent deliveries
• Webhook callback support with HMAC-SHA256 signing
• Audit log and delivery history
• Prompt templates for common agent frameworks

The reference implementation is not the only valid implementation. Any system that correctly implements the payload schema, response schema, and agent behaviour requirements described in this document is a compliant implementation. The protocol specification is released under the MIT licence. Implementations may be open or proprietary.

The Broader Vision

This protocol is a small piece of a larger shift that is already underway. The question of how humans maintain meaningful oversight of autonomous AI systems — not just technically, but experientially — is one of the defining design challenges of this decade.

The answer is not more dashboards. It is not more alerts. It is not making humans work harder to stay informed. It is designing systems where agents and humans have a clear, respectful, well-defined relationship: agents do the work, humans provide the judgment that agents cannot, and the interface between them is calm, structured, and built around human needs.

This protocol is a foundation for that relationship. It is intentionally minimal — a single, well-defined seam between the autonomous and the human. What is built on top of that seam is where the real design work begins.

Open Questions

The following questions are open for community discussion as part of the RFC process:

Conclusion

The gap between what autonomous AI agents can do and what humans can see is a solvable problem. It does not require new AI capabilities or complex infrastructure. It requires a shared standard for the moment when an agent surfaces its work to a human — and a commitment to designing that moment around human needs rather than technical convenience.

WAKE is a proposal for that standard. It is intentionally simple, intentionally open, and intentionally focused. We invite implementers, agent developers, and the broader AI community to adopt it, critique it, and improve it.

This document is released under the MIT licence. Contributions, critiques, and implementations are welcome at github.com/wakeprotocol.

Minimal Agent Integration Example

import httpx, time, os

WAKE_URL = os.environ["WAKE_ENDPOINT"]
API_KEY  = os.environ["WAKE_API_KEY"]

def deliver(agent_id, type, headline, summary, details, timeout=3600):
    r = httpx.post(
        f"{WAKE_URL}/wake/v1/deliver",
        headers={"Authorization": f"Bearer {API_KEY}"},
        json={"agent_id": agent_id, "provider": "claude", "type": type,
              "headline": headline, "summary": summary,
              "details": details, "timeout_seconds": timeout}
    )
    return r.json()["delivery_id"]

def await_response(delivery_id, poll=60, max_wait=3600):
    elapsed = 0
    while elapsed < max_wait:
        r = httpx.get(
            f"{WAKE_URL}/wake/v1/response/{delivery_id}",
            headers={"Authorization": f"Bearer {API_KEY}"}
        )
        data = r.json()
        if data["status"] != "pending":
            return data
        time.sleep(poll)
        elapsed += poll
    return {"status": "timeout", "feedback": None}

# Usage
delivery_id = deliver(
    agent_id="research-agent-01",
    type="output",
    headline="Market research report ready for your review",
    summary="Completed analysis of the top 10 competitors in the space.",
    details={"report_url": "https://...", "word_count": 3200}
)

response = await_response(delivery_id)

if response["status"] == "approved":
    proceed_with_next_step()
elif response["status"] == "rejected":
    handle_rejection(response["feedback"])
elif response["status"] == "redirected":
    incorporate_edits(response["edited_content"], response["feedback"])

System Prompt Template

The following addition can be included in any agent's system prompt to enable compliant delivery behaviour:

You are working autonomously on behalf of a human. When you complete
a significant piece of work, reach a decision point you cannot resolve
alone, or encounter an unexpected condition, deliver a structured update
via WAKE before proceeding.

When delivering:
- Frame your headline positively — lead with what has been accomplished.
- Be specific in your summary — one plain-language sentence.
- Do not block waiting for a response. Continue with other work or
  document your assumptions and proceed after the timeout period.
- Respect the human's response — if they reject your proposed action,
  do not proceed. If they redirect you, incorporate their changes fully.

The human is your collaborator. Surface your work clearly.
Act on their guidance immediately.

Full spec: /spec/