CueAPI — Summary

CueAPI is an open-source scheduled job server for AI agents that replaces dumb cron with outcome-aware scheduling: when an agent's scheduled task runs, it reports success or failure back to CueAPI, which then retries on failure (exponential backoff at 1, 5, 15 minutes), maintains a complete execution history, and sends email + webhook alerts when retries are exhausted. The server ships as a Python/FastAPI application with a Docker Compose install, runs at localhost:8000, and exposes a REST API for schedule management and execution monitoring. Its README is written specifically for AI agents — the very first line is a structured prompt to any AI agent reading the page: "For AI agents: This is the CueAPI server. Run it with git clone ... && docker compose up. Base URL: http://localhost:8000." The CLAUDE.md defines a strict automated pipeline where Claude Code opens PRs, merges on CI pass, and deploys; a separate "Argus" agent tests staging and promotes to production.

Among the seeds, CueAPI resembles the "Markdown scaffold, zero primitives" archetype (claude-conductor), but applied to infrastructure rather than coding methodology: instead of templates that guide agent behavior, CueAPI provides the scheduling infrastructure that makes agent behavior schedulable and observable. No seed addresses the problem of reliably scheduling and monitoring AI agent tasks.

CueAPI — Overview

Origin

Published by the cueapi organization (GitHub: cueapi/cueapi-core). Version 0.1.0. 8 stars. Python/FastAPI. Active (last push 2026-05-26). Apache 2.0 license. Open core model: cueapi-core is the full OSS engine; cueapi.ai adds dashboard, managed email alerts, billing.

Philosophy

"Cron fires jobs. That is all it does. It has no concept of whether your job succeeded. CueAPI does."

"Your agents are failing silently. CueAPI tells you when and why."

The README opens with the problem framing:

# This is what your agent sees with cron:
0 3 * * * python run_agent.py

# Did it run? Who knows.
# Did it succeed? No idea.
# Did it retry on failure? No.
# Are you alerted? Never.

Agent-Targeted Design

The README is unusual in starting with a structured instruction block explicitly for AI agents:

<!-- Pipeline validation: 2026-04-04 -->
> **For AI agents:** This is the CueAPI server. Run it with `git clone https://github.com/cueapi/cueapi-core && cd cueapi-core && docker compose up`. Base URL: `http://localhost:8000`. Register: `POST /v1/auth/register` with `{"email": "you@example.com"}`. API key is returned directly in the response. No email required. All requests need `Authorization: Bearer YOUR_API_KEY`. Create a cue: `POST /v1/cues` with {"name": "task-name", "schedule": {"type": "recurring", "cron": "0 9 * * *"}, "callback": {"url": "https://your-handler.com"}}`.

This is a machine-readable README — designed so that an AI agent reading the docs can immediately start using the API without further instructions.

Two-Agent Pipeline (from CLAUDE.md)

CueAPI — Architecture

Distribution

• Docker Compose (primary self-hosted method)
• Direct Python/pip install
• Hosted at cueapi.ai (cloud)

Required Runtime

• Docker + Docker Compose
• Python 3.9-3.12

Tech Stack

Repository Structure

cueapi-core/
├── app/
│   ├── auth.py          # Authentication
│   ├── config.py        # Configuration
│   ├── database.py      # DB connection
│   ├── main.py          # FastAPI app
│   ├── middleware/      # Middleware
│   ├── models/          # Database models
│   ├── routers/         # API route handlers
│   ├── schemas/         # Pydantic schemas
│   ├── services/        # Business logic
│   └── utils/           # Utilities
├── worker/              # Background job worker
├── alembic/             # Database migrations
├── tests/               # 367 tests
├── examples/            # Usage examples
├── docs/                # Documentation
├── CLAUDE.md            # Agent pipeline definition
├── docker-compose.yml   # Self-hosted deployment
└── Makefile             # Common operations

API Surface

REST API at localhost:8000:

• POST /v1/auth/register — register, get API key immediately (no email verification)
• POST /v1/cues — create a scheduled cue
• GET /v1/cues — list cues
• GET /v1/executions — view execution history
• POST /api/hooks (or configured callback URL) — receive execution outcomes

CLAUDE.md Pipeline

The CLAUDE.md defines a multi-repo automated pipeline involving Claude Code + Argus:

• cueapi-core (OSS)
• cueapi (hosted, private)
• cueapi-python (SDK)
• cueapi-cli
• Marketing site, docs, blog

CueAPI — Components

REST API Endpoints

Core Concepts

Retry Logic

Automatic retries on failure at 1, 5, and 15 minutes (exponential backoff). Exhausted retries trigger email + webhook alerts.

Two-Agent Pipeline Components (CLAUDE.md)

Tests

367 pytest tests covering the full API surface.

CueAPI — Uniqueness

Differs from Seeds

CueAPI addresses a problem no seed framework tackles: scheduled execution with outcome awareness for AI agents. All 11 seeds assume an interactive or on-demand execution model (human types a command, agent runs). CueAPI enables agents to operate on schedules, with automatic retry on failure and alerts when retries are exhausted. This is the infrastructure that makes "run this agent at 3am every day" a reliable operation rather than a fire-and-forget cron job. The closest seed is ccmemory (persistent infrastructure for agent operation), but ccmemory provides knowledge storage while CueAPI provides reliable scheduled execution. The machine-readable README header — a paragraph explicitly written for AI agents, with exact API calls and response formats — is unique in the corpus: it is documentation designed to be consumed by agents, not humans, with <!-- Pipeline validation: 2026-04-04 --> as a freshness timestamp for agent parsers. The CLAUDE.md's explicit statement "No human reviewer required" for PR merges is the most autonomy-granting agent pipeline definition found in this batch.

Positioning

CueAPI is scheduled-job infrastructure for the agentic era. It is complementary to all other frameworks: any framework can schedule its workflow on CueAPI. The open-core model (OSS server + hosted SaaS with dashboard) is a standard infrastructure product pattern applied to the agent-scheduling space.

Observable Failure Modes

1. Callback URL dependency: The agent must expose an HTTP endpoint. Local development agents cannot easily receive CueAPI callbacks without a tunnel (ngrok, etc.).
2. No agent identity: Cues are tied to API keys, not to specific agent identities. Multiple agents using the same key have no execution isolation.
3. Outcome reporting is optional: Agents can receive cue callbacks without reporting outcomes. Silent failures are possible if the agent doesn't implement the outcome reporting pattern.
4. Open-core tension: Dashboard and managed alerts are hosted-only. Self-hosted users have no UI visibility into their execution history.