Price & Site Monitoring
Product prices, “in stock” labels, public announcements — pages that only change once in a while are the worst kind to refresh by hand. This recipe sets up an agent that visits a page on a fixed schedule and only pings you when the content is different from the last time it looked.
How it works
- The agent checks the page once per interval.
- It pulls out the values you care about (price, stock wording, a specific sentence) and compares them with what it saved last run.
- If something changed, it sends a message via Notify User (during autonomous runs a push notification goes out too).
- If nothing changed, it stays silent and waits for the next interval.
The “stay silent” part is the key. If the agent reports every single run, the notifications turn into noise and you start ignoring the real signal.
Tools to enable
In the agent’s Settings tab → Enabled Tools, turn these on.
| Category | Tool | What it does in this recipe |
|---|---|---|
| 🌐 Information | HTTP Request | Reads the price/text from a static page (enough for most cases) |
| 🌐 Information | Web Browser | Use this only if the page needs login, clicks, or scrolling |
| 💾 Memory & files | Read File | Pulls back the last seen value |
| 💾 Memory & files | Write File | Saves this run’s value for next time |
| ✍️ Output | Notify User | Delivers the alert only when something changes (used automatically during autonomous runs) |
| ⏰ Automation | Schedule Create / Schedule List | Lets the agent register and manage its own recurring runs |
💡 If HTTP Request can read the page, prefer it — it’s faster and lighter. Switch on Web Browser only for pages that need a login or are rendered with JavaScript.
Example system prompt
Put a behavior block like this in the agent’s Settings → System prompt. Adjust the URL and rules to your case.
Role: price & site monitoring agent.
Watch:
- https://example.com/product/123 (product price and "in stock" label)
On every run:
1. Fetch the page above.
2. Extract the price number and the stock label.
3. Read monitoring/last_seen.md to load the previous values.
- If the file does not exist, save this run's values as the baseline and stop.
4. Compare with the previous values.
- If the price changed or the stock label changed, alert the user.
- Summarize what changed (before → after) in one short line.
- If nothing changed, do not send any message.
5. Overwrite monitoring/last_seen.md with the values seen this run.
Only alert on actual changes. Stay silent when values are identical.Two parts matter most:
- If there is no previous value, save the baseline and stop — so the first run doesn’t false-alarm.
- Never send “no change” updates — repeated “nothing happened” pings drown out the real ones.
Setting up the schedule
Tell the agent something like “check this page every hour” and it will register its own schedule via Schedule Create. You can see and edit those schedules from the agent’s detail page → Schedules subpage.
Because registering a schedule sets up future autonomous runs that spend credits, it asks for your approval once before the schedule is created by default. If you’d rather it register without prompting, set Schedule Create to auto-approve in the per-tool approval settings.
Some examples of how to phrase the interval:
- “every hour” → runs once per hour
- “every weekday at 9 am” → runs Monday through Friday at 9:00
- “every 3 hours” → runs every 3 hours
Start with a generous interval like one hour, then adjust based on the page. Polling too often risks getting throttled by the site and burns through credits faster.
First run — baselining
A fresh monitoring agent has no previous value to compare against. The system prompt above handles this with the rule “if the file doesn’t exist, save the baseline and stop” — so the first run quietly records the starting values and exits without sending an alert. Comparison starts on the second run.
If you’d rather set the baseline manually, ask the agent in chat: “save the current values as the baseline” — one run is enough.
Tuning — reducing noise
If the page wiggles in small ways and the alerts get too frequent, add thresholds to the system prompt:
- Price threshold example: “Ignore price changes under 5%. Only alert if the change is 5% or more, or the stock label changed.”
- Time threshold example: “Do not send two change alerts within 12 hours (record the last alert time in memory and compare).”
You can also dictate the alert tone — for instance: “Use an urgent tone for sharp price drops, a calm tone for simple wording changes.”
Next steps
- Equipping Tools — more on each tool used in this recipe
- Morning News Briefing — same “schedule + notify user” pattern, but reports every run instead of comparing
- Research Assistant — chain after the monitor when a big change deserves a deeper dive
Advanced
The section below isn’t needed for the basic recipe. Read it when you want to sharpen comparisons, watch a login-only page, or worry about cost.
Where the previous value is stored
When Write File saves with a relative path like monitoring/last_seen.md, the file lives in the agent’s private memory area. The same agent can read it back on the next run with Read File using the same relative path.
- This memory area is per-agent — other agents on the same team can’t see it.
- If you need the value to be visible to teammates, use Team State Set instead.
- Markdown is the easiest format. For a handful of key-value pairs a couple of lines is plenty.
The top-level memory index file has a size cap, so keep actual data in a subpath like monitoring/... rather than dumping it into the index.
Pages that change a lot
If the page itself fidgets a lot and you keep getting alerts on cosmetic changes, try these in order:
- Narrow what you extract — in the system prompt, instruct the agent to grab specific values (the price number, a single label) rather than diffing whole sections.
- Add thresholds — 5% minimum change, max one alert per 12 hours, etc.
- Lengthen the interval — moving from 5 minutes to 1 hour naturally smooths over tiny jitter.
- Restrict the time window — schedule the checks for business hours (e.g. weekdays 9–18) instead of 24/7. Adjust the recurring schedule the agent registered to match. If you configure an Active Hours band under the agent’s Settings → Heartbeat first, the agent will ask for confirmation whenever a schedule would fire outside that window.
Pages that require login
Member-only prices, dashboards, or pages behind a sign-in form aren’t reachable via HTTP Request. In that case:
- Enable Web Browser and add a rule like “if a login screen appears, hand the screen over to the user so they can log in directly.” The actual handoff is driven by the Ask User tool’s desktop mode (Ask User is on by default, so you normally don’t need to enable anything extra): the agent pauses, hands control of the screen to you, and resumes once you finish and press Done. This way the agent never handles your password directly.
- If the site is one you’ll monitor regularly, connect it ahead of time under Settings → Connections (for supported services). That way the agent doesn’t have to hand off at all.
- Whenever login is involved, scope the agent’s behavior tightly in the system prompt so it doesn’t repurpose any login-only content for other purposes.
Cost notes
- Shorter polling intervals mean more LLM calls and proportionally more credit usage.
- Web Browser is heavier per call than HTTP Request — if both work for the page, prefer the lighter one.
- Telling the agent not to send “no change” messages also cuts the response-generation cost from each interval.