Sign Up Sign In

Introduction

AIGears gives stateless AI agents the stateful infrastructure they need to act over time. No matter how capable a model becomes, it cannot live between sessions: it can't wait three days, it can't remember a commitment across a context reset, it can't pause for a human's sign-off, and it can't watch the outside world for change while it isn't running. AIGears supplies that persistence — so your agent can register an intention now and be called back later, even after its process is gone.

Why AIGears exists

An agent runs, produces a turn, and stops. Everything it "knows" lives in a context window that vanishes when the turn ends. That leaves four walls every agent developer eventually hits:

  • It forgets. State from this run is gone by the next one.
  • It can't wait. There is no "come back in three days" — only the current turn.
  • It shouldn't act unilaterally. Some actions need a human to approve them first, and the agent can't block on that.
  • It can't watch. It can't notice that a page, feed, or endpoint changed while it was idle.

AIGears turns each of these into a durable record owned by your Team. You register the intention through one of three surfaces; we hold the state, do the waiting, and call your webhook back when it's time to act.

The four primitives

Each primitive solves one of the four walls. Every operation on every primitive is available on all three surfaces — see its guide for the worked walkthroughs.

  • Schedules — fire a webhook at a future time, optionally recurring on a cron expression. The foundation the others lean on.
  • Deadlines — remember a dated obligation with an escalation policy that reminds, before and after due, over webhook and email.
  • Approvals — block an agent action on a human's sign-off, delivered as a single-use capability URL; a webhook fires back with the decision.
  • Watches — subscribe to an external source (URL / RSS / JSON) and get a webhook when it changes.

Three ways to use it

The same Team state is reachable through three surfaces — three front doors onto one service layer:

  • Dashboard — a logged-in human in the browser. Best for setting things up by hand and inspecting what your agents have done.
  • HTTP API — a plain REST API authenticated by an API Key. Best for code and non-MCP agent frameworks.
  • MCP — the hosted MCP server, driven by an MCP-capable agent whose operator authenticates over OAuth. Best when the agent should manage its own state directly as tool calls.

All three converge on the same shared state: a schedule you create over the HTTP API shows up in the Dashboard and is visible to your MCP agent. Throughout these docs, every operation is shown on all three surfaces using a sticky tab convention — pick a surface once and the tabbed examples follow your choice from page to page. Read more in Surfaces & authentication.

Where to go next

  • Getting started — the five-minute path from sign-up to your first fired schedule.
  • Concepts — the mental model: surfaces, teams and keys, webhooks and signing, idempotency, the audit log, limits.
  • Examples — end-to-end stories that combine the primitives into real agent workflows.