Dev.to AI 🤖 Ai 👁 0 📖 8 min read

One watcher, three prices, one rule: an agent watch that remembers its baseline

Every agent demo is a watcher right now, so let me save you the lesson I keep paying for: the watching is not the hard part. The hard part is tomorrow. A signal watch, in plain words, is one agent checking the same sign

Every agent demo is a watcher right now, so let me save you the lesson I keep paying for: the watching is not the hard part. The hard part is tomorrow.

A signal watch, in plain words, is one agent checking the same signal on a schedule: a price, a lead source, a mention feed, your own numbers. Reading the signal takes one call. What takes the rest of the week is everything the watch needs across time: a baseline that is still there after the session ends, a threshold that does not drift when a prompt gets edited, and proof on the quiet days that the watch ran at all. Without those, the alert, when it finally fires, is a number measured against a memory nobody can produce.

I run Zambo, a work layer for AI agents: per-agent memory that persists between sessions, handovers that turn work into published records, and a verifiable receipt for every call. I pointed it at exactly this problem, ran a small watch for real with a fresh identity, and then packaged the whole pattern so any agent can install it and run it. This is the pattern, what it cost, and the place my own tooling broke on contact.

Start with no code at all

If you have never run a watch, run this version first. Add the Zambo endpoint (https://zambo.dev/mcp) to one chat AI and put it on whatever loop you already use. The two-minute setup is at https://zambo.dev/add/. Then paste this into its instructions:

Run a signal watch on Zambo:

  1. Connect to https://zambo.dev/mcp. When the endpoint issues your caller handle, save it in this conversation and present it on every call. Your memory, including the baseline you are about to save, keys to that handle. Keep one job id for the whole watch and reuse it on every pass.
  2. First pass only: read the signal (for a price watch, call live_price for each asset). Then save ONE fact with memory_remember: the values, each value's receipt link, and the rule in plain words, for example "alert when any watched asset moves 3 percent or more from its baseline". Keep the remember receipt.
  3. Every later pass: recall the baseline with memory_recall and read the values out of the recalled fact. Never work from your chat transcript; the remembered fact is the baseline of record.
  4. Read the signal again. Compute each move against the recalled baseline and apply the rule exactly as stated. A move under the threshold is a quiet day, even if it is close.
  5. Save the reading with memory_remember either way: the values, the moves, and the rule's outcome. A quiet day with no saved reading is a gap in the record.
  6. Wrap the pass with handover: a summary (lead with the alert and the size of the move if the rule fired; say "quiet check, no alert" with the values and moves if it did not), a goal naming the watch and the rule, the operator as recipient, and next steps. Send the operator the handover link. That link is the digest: the record anyone can verify at https://zambo.dev/verify/ .

That is the whole shape. Everything after this section is the same pattern run by code, at full depth, with the receipts to inspect.

The pattern, at depth

One watch is one job id (a single _session_id) and one identity. The watcher initializes once, is issued its own caller handle, saves that handle in its own state file, and presents it on every call. Memory keys to the handle: the baseline saved on day one is recallable on day thirty, across restarts and reconnects, because it lives in the endpoint's memory, not in a transcript. A second watch gets a second handle; two watches sharing one handle share one memory and their baselines collide.

The baseline is a remembered fact, and it carries three things: the values, the receipt of each reading they came from, and the rule in plain words. The check pass recalls that fact and reads the values back out of the recalled text. It never works from the local state file's copy of the numbers (the file holds the identity; a fallback copy of the numbers rides along for emergencies, and the run below shows why the distinction matters). Then it re-reads the signal, computes each move, applies the rule exactly as stated, saves the reading whether or not the rule fired, and wraps the digest: an alert format when the rule fires, a quiet format when it does not, so a reader can always tell a checked quiet day from a day the watch never ran.

The run

November 2, 2026, one fresh identity (signal-watch-demo), one job id (signal-watch-2026-11-02), the package's own watch.py doing the work. The rule, stated inside the baseline fact: alert when any watched asset moves 3 percent or more from its baseline.

The baseline pass, 20:45 UTC, read BTC at $76,800.00 (https://zambo.dev/run/a78b8851-5ab7-4b4d-bf70-a90a46a87b6c), ETH at $2,244.62 (https://zambo.dev/run/b1adb980-2b13-4680-bc97-2b3b4e54c745), and SOL at $91.29 (https://zambo.dev/run/25da9cc8-616d-4383-9498-3aaad7ee5f27), then saved the baseline fact with the rule and all three receipts inside it: https://zambo.dev/run/a6fe88a7-a882-4880-90f8-5437bb05aa7d

The canonical check pass recalled the baseline from memory alone (BTC 76800.0, ETH 2244.62, SOL 91.29, verbatim), then read BTC at $76,793.00 (https://zambo.dev/run/cb8202ea-3913-468f-b7b8-f281c8cf6122), ETH at $2,245.12 (https://zambo.dev/run/adf91ada-41b8-4253-a396-54fa019d5bdd), and SOL at $91.34 (https://zambo.dev/run/598d63b7-8144-46f8-9707-b4a15169acd8). The moves: BTC -0.01 percent, ETH +0.02 percent, SOL +0.05 percent. Nothing reached 3 percent, so the rule returned no alert. The reading was saved anyway (https://zambo.dev/run/12b0616b-e825-4574-9501-ac88ef06f2d6) and the quiet-day digest was wrapped: https://zambo.dev/handover/121aa53f-1981-4330-9133-49e386aabf1e

Open that link. It is a quiet digest and it says so: the prices, the moves, and the words "no alert". A check run minutes after its baseline should be quiet, and a system that cries alert here to make a better story is exactly the system whose real alerts you would learn to ignore.

One honest failure from the same hour: the first check pass completed, but my baseline parser tripped on the decimal point in the recalled numbers and completed the values from the local fallback copy. The recall itself was perfect; the bug was mine, in twenty lines of parsing. I fixed the parser, proved the fix against a fresh recall (all three baselines extracted from memory text alone), and the canonical pass above is the fixed code running end to end. The first pass's digest is on the record too: https://zambo.dev/handover/8654e4d4-765a-47ef-955a-fa67e84cab6d . That is what a checkable record is for: it caught my tooling being sloppy, in public, where I could not quietly pretend otherwise.

What a watch costs

The free tier is per agent: 20 calls plus 1 wrap-up free every day for the watcher's own caller handle, and picking up a handover is always free. Counted from this run: the baseline pass cost 4 counted calls (3 prices and the baseline save); each check pass cost 5 (the recall, 3 prices, the reading save); the digest wrap was the free daily wrap-up. Run once a day, a three-signal watch costs 5 counted calls a day after day one, inside the free tier. When a watch outgrows free, the line is per agent: a Day Pass is $0.99 for one agent, unlimited for 24 hours; the Zambo Pass is $29 for one agent for 30 days. One-time payments, never subscriptions. Scheduling is yours: Zambo does not start the passes, your cron or agent loop does, and one check per scheduled pass is the discipline. A watch that checks five times an hour spends its allowance proving nothing moved.

The package

The pattern ships as an installable agent package, zambo-watch 1.0.0: the skill that teaches it, watch.py (baseline mode and check mode, handle persistence included), the no-code paste above, and the run record with every link live.

It is one of five patterns in a family that runs on Zambo; its sibling, shipped first, is the swarm package (https://pypi.org/project/zambo-swarm/), for the days the job is bigger than one agent. And the package proves itself from fresh installs: the watch.py copies installed from PyPI and from npm were each run baseline plus check against the live endpoint by separate fresh identities, and each wrapped its own digest (https://zambo.dev/handover/a82cead1-e4e3-4fa9-abee-05baf4c96e80 and https://zambo.dev/handover/0048c820-2519-41e8-80b3-c9db1840acc1).

Do not take my word for it

Pick any number in the digest, open its receipt, and check it at https://zambo.dev/verify/. A receipt proves the saved result was not changed since it was saved, and the check recomputes that from the record itself. It does not prove the price was right or the threshold was wise, and I am not claiming otherwise. If a receipt from this run ever fails to verify, that is news and I want to hear it.

Your scheduler still runs your watch. Zambo is where its baseline lives, where its readings land, and where its alerts get proven. That is the whole pitch, and every link above is the evidence.

Try it free: add Zambo to your AI in one step at zambo.dev/add. 20 calls plus 1 wrap-up free every day, picking up in another AI is always free, no card and no signup wall.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.

Share 𝕏 Twitter ✈ Telegram ↗ Reddit 🟧 HN
← News 🤖 Ai 🏠 Home