Give your agent ears.
Agent Monitors watches the things you care about — files, APIs, repos, docs, CLIs — and tells your agent the moment they change. No polling loop. No re-asking. Your agent finds out on its own.
Your agent can already see and act — eyes (computer-use), and hands (tools). Hearing is the sense it's missing — and the one nobody else is building.
02 · the problem
Today, you're the polling loop.
Right now, you are how your agent finds things out. "Check my email again." "Any new comments?" "Did CI pass yet?" You keep going back and poking it. You're the loop — running on your own attention.
Or you wired one up yourself: a script that wakes the agent every few minutes to go look. Now it burns tokens on every tick whether or not anything changed, re-derives what's different by eyeballing two big blobs, and quietly breaks the next time a session restarts.
- A pile of polling loops, each spending tokens every tick
- Re-deriving diffs in-context, eyeballing two big blobs
- All fighting the same rate limits and locks
- Scattered across shell scripts you'll never find again
- Silently broken the moment a session restarts
- One simple markdown file per thing you care about
- Heard only when it matters, pre-digested
- Reliable across restarts and tool updates
- Private — it all stays on your machine
- Future-proof — declare it once; the plumbing can change underneath
Stop being the loop. Let your agent be told.
03 · how it works
Declare what matters. Your agent hears the rest.
The whole thing is one small file. The top says what to watch; the body says what it means and what to do.
--- name: Watch the upstream API spec watch: type: url url: https://api.vendor.com/openapi.json --- The upstream API spec changed. Diff it against my client in src/api/ and flag any breaking changes I need to handle.
The watch: block — what to watch
The facts the runtime handles for you: where to look and how to tell when it changed. Deterministic, off to the side. You never write a polling loop.
The body — what it means & what to do
Your judgment, in plain language, run by the agent only when the watch actually fires. One small file declares both halves.
You write the file
A MONITOR.md next to your code: what to watch, and what it means. Versioned, in one place.
A daemon watches
A lightweight local daemon watches deterministically, off to the side. No tokens spent while nothing changes.
Your agent is told
Only when something actually changes — pre-digested, and delivered at a moment it can act on it.
04 · why it holds up
Built to survive contact with real work.
Monitor everything that matters — not just what you can afford to poll.
Polling taxes you on every tick, so you ration what you watch. Agent Monitors charges you only when something happens — so the ceiling lifts. One agent can stay aware of dozens of things at once.
Your agent gets the answer, not the homework.
A precise, pre-computed diff — it won't hallucinate or miss a change the way an agent comparing two big blobs does. Cheaper and more correct.
It doesn't forget while you're away.
A durable local daemon remembers what each session last saw. Restart your agent, update your tools — you won't miss what happened in the gap.
Your data stays on your machine.
The daemon is local; what it watches and remembers lives on your disk, not someone's cloud. Your internal Slack, your private repos, your docs.
One watch, many agents.
Twenty agents polling the same API is twenty loops fighting rate limits and locks. Point them at one monitor instead — one ingress, no contention.
One file beats a graveyard of shell scripts.
Declarative, versioned, in one place — not monitoring hacks scattered across script folders you'll never find again.
Write it once; it keeps working.
A monitor declares what to watch and what to do — never how the signal reaches your agent. As agent tools gain better ways to receive signals (channels and beyond), Agent Monitors adopts them and your existing monitors just work.
No — the opposite. A channel is how a signal gets in; a monitor is what you're listening for. Most of what matters — a file, a CLI's output, a new blog post — never pushes itself anywhere; something has to go listen. Channels are the ear canal. Monitors are the hearing.
Works wherever your agent has hooks — Claude Code, Codex (CLI & desktop), and Cursor. One shared mechanism, not one vendor.
05 · quickstart
Your first five minutes.
- Install the CLI —
npm install -g @agentmonitors/cli. - Scaffold a monitor —
agentmonitors init my-first-monitorwrites a ready-to-editMONITOR.md. Say what to watch and what it means. - Run the daemon —
agentmonitors daemon runwatches deterministically, off to the side, and delivers through your agent's hooks. - Start your agent — the next time something changes, it hears about it. No re-asking.
$ npm install -g @agentmonitors/cli $ agentmonitors init slack-api-specs --type api-poll ✓ created monitors/slack-api-specs/MONITOR.md $ agentmonitors daemon run ○ agentmonitors · 3 monitors active · watching # …later, without you asking ◉ heard the Slack API spec changed ↳ your agent already has the diff
doors
Getting started
Install, author your first monitor, run it, and see a signal land in your agent.
Authoring monitors
The full watch: model, every source, urgency, and notify timing.
Docs
The open, host-agnostic Monitor Standard — available as rendered HTML and raw markdown.
Troubleshooting
Symptom-first fixes when a monitor doesn't fire, doesn't notify, or stops working.
Using an AI coding agent? Point it at agentmonitors.io/skill.md — it's a self-contained, agent-readable setup guide that installs the CLI, authors a monitor, and proves it fires, with no other context required.