Inside Olostep Monitors: Turning Natural-Language Intent Into an Agentic Monitor

Most AI systems read the web once and freeze that snapshot in time. The web is not static: prices shift, listings appear and disappear, status pages flip, blog posts get published, terms of service get edited. For agents to act on real business signals, they need to see the web as it changes — reliably, on a schedule, with enough determinism that downstream automations can trust the output.

This post is a technical walkthrough of the Olostep Monitors API (POST /v1/monitors): what happens between the moment you describe a monitor in plain English and the moment a notification lands in your inbox, your webhook, or as an SMS.

We will keep some internals abstract on purpose, but everything described here is what the system actually does end‑to‑end.

1. The API surface in one paragraph

A monitor is created with a single POST /v1/monitors request. Three fields drive the entire lifecycle:

• query — a natural‑language description of what to monitor (a URL is usually embedded in the text).
• frequency — a natural‑language schedule, for example every day at 9am America/Los_Angeles or every 5 minutes. The API parses it and derives a cron expression.
• Exactly one notification target: email, webhook_url, or phone_number (E.164 for SMS).

Optional fields:

• output_schema — a JSON Schema that constrains a structured extraction step on every run.
• metadata — free‑form key/value tags returned on every event and notification (useful for routing on your side).

The endpoint validates the input, provisions the monitor, registers its schedule, and returns a monitor object with id, status: active, the parsed cron_expression, and the original frequency string. Subsequent operations — GET, list, pause, resume, delete, and the per‑monitor events feed — are all keyed off the returned id.

curl -s -X POST "https://api.olostep.com/v1/monitors" \
  -H "Authorization: Bearer $OLOSTEP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "Track changes in https://example.com/products/widget-pro pricing and stock information",
    "frequency": "every day at 9am America/Los_Angeles",
    "email": "alerts@example.com"
  }'

So far, so familiar. The interesting part is what the platform does between scheduled ticks.

2. From natural language to a deterministic workflow

When you create a monitor, the query is not just a prompt that gets sent to an LLM at run time. Behind the scenes, a multi‑agent system inspects the request, verifies the candidate sources, and compiles the natural‑language description into a deterministic workflow plan that the runtime will execute on every scheduled tick.

This split — agents at planning time, deterministic execution at run time — is the central design choice of Monitors. It is what lets the system adapt to very different requests (a status page, a product listing, a reviews section, a blog index) while still guaranteeing a consistent, reproducible result for each individual monitor, run after run.

A few properties follow directly from this:

• The plan is fixed once the monitor is created. Every run executes the same workflow with the same parameters.
• The natural‑language frequency is materialized once into a cron expression. From that point on, the trigger is a normal scheduled job, not an LLM decision — so if you said every day at 9am America/Los_Angeles, the schedule is deterministic and timezone‑aware.

In short: LLM reasoning is used where it pays off — understanding intent and verifying sources — and is deliberately kept out of the parts of the system that have to be deterministic.

3. Anatomy of a single monitor run

When the scheduler fires for a given monitor, the runtime simply follows the workflow that was compiled at creation time. The pipeline is target‑anchored and roughly the same shape for every monitor:

[capture a snapshot of the current state of the target]
        │
        ▼
[compare against the previous snapshot under the user's intent]
        │
        ▼
[notify if — and only if — something relevant has changed]

3.1 Snapshot

On every run, the platform captures a snapshot of the current state of the monitored target. Pages are rendered (so client‑side content is included), the snapshot is stored in private per‑monitor storage, and — when an output_schema was provided — a structured representation of the page is produced alongside the raw content. The structured payload always validates against the user‑provided JSON Schema, so downstream systems can rely on its shape.

3.2 Comparison under intent

The new snapshot is then compared to the previous one. The key idea here is that the differences considered by the system are not just textual changes: they are interpreted under the monitoring intent expressed in the original query. A reviews page may technically change every minute (timestamps, ad slots, ordering) while still containing no change a human would care about. The platform's job is to filter exactly that.

The output of this step is a small, well‑typed object that drives everything downstream:

{
  "changed": true,
  "summary": "Price changed from $49 to $45 and stock moved to low availability."
}

summary is the canonical human‑readable description of the change. Every notification (email body, webhook payload, SMS) is derived from it.

3.3 Notification

If, and only if, the comparison decides that a relevant change has occurred, the run sends a notification on the channel configured at create time — email, webhook_url, or phone_number (SMS). If nothing relevant changed, nothing leaves the system. No change, no notification. This is a hard contract, not a heuristic.

Snapshots from every run — whether they triggered a notification or not — are persisted and can be browsed later via GET /v1/monitors/:id/events, each event carrying a short‑lived pre‑signed URL so you can pull the raw snapshot content securely.

4. Make the intent explicit in your query

Because the comparison step is intent‑aware, how you phrase the query matters. The monitor will act according to what you ask for — so it pays off to be explicit about the kind of changes you actually care about.

A few examples of phrasings that change the behavior of the same monitor:

"Monitor X and notify me about new listings versus the previous run."
"Watch Y and alert me when an item disappears."
"Track Z and tell me about anything that changes."
"Snapshot the current reviews on this page on every run."

These are not magic keywords — they are natural‑language statements of intent that the system uses to decide what counts as a change worth surfacing. If your downstream system wants the full current state every run (for example, to overwrite a table), say so. If you only want deltas, say that. The rule of thumb: a monitor will give you what you describe, so describe it precisely.

5. Worked examples

5.1 Notify me when uptime issues appear in the OpenAI API

{
  "query": "Monitor OpenAI uptime status and notify me when API uptime drops below 99%",
  "frequency": "every 20 minutes",
  "email": "info@olostep.com"
}

Compiles to: capture the OpenAI status page hourly → compare against the previous snapshot under the intent ("uptime issues") → if something relevant changed, email the summary. Otherwise, silent.

5.2 Snapshot new YC startups, deliver them via webhook

{
  "query": "Alert me when a new startup launches on Y Combinator",
  "frequency": "every hour",
  "webhook_url": "https://hooks.example.com/startups",
  "output_schema": {
    "type": "object",
    "properties": {
      "startups": {
        "type": "array",
        "items": {
          "type": "object",
          "properties": {
            "company_name":     { "type": "string" },
            "user_name":        { "type": "string" },
            "url":              { "type": "number" },
            "tagline":          { "type": "string" }
          }
        }
      }
    }
  }
}

5.3. Only new job listings, please

{
  "query": "Notify me when Olostep publish a new job listing",
  "frequency": "every hour",
  "webhook_url": "https://hooks.example.com/job"
}

The phrase "newly appeared listings versus the previous run" tells the monitor to ignore re‑orderings, ad slots, and unrelated DOM noise. Only a genuinely new listing at the top of page 1 triggers a notification.

6. What this is not (yet)

A few honest scoping notes, so expectations stay calibrated:

• A monitor is a pipeline over a target, not a free‑form research agent. If you describe an open‑ended task ("find me opportunities on the web today"), the create call will compile something, but it won't be as crisp as a target‑anchored monitor.
• Snapshots are tied to monitors; cross‑monitor joins are not part of the API surface. Do those in your warehouse.

7. Getting started

1. Generate an API key from your Olostep dashboard.
2. POST /v1/monitors with a query, a frequency, and any of email / webhook_url / phone_number.
3. Wait for the first run (or trigger via your existing automations once you start chaining things together).
4. Inspect history with GET /v1/monitors/:id/events. Pause, resume, update frequency, or delete as needed.

If your business depends on knowing when the web changes — and on a system that won't cry wolf every time a page re‑renders — give it a try, and tell us what you'd want next.

Reference

• API documentation: https://docs.olostep.com/features/monitors
• API dashboard: https://www.olostep.com/dashboard/monitors