How to track changes to external rules your team relies on

Agent Swarm can run a scheduled check against one public source you choose, flag the text that changed, and hand a source-linked brief to the person who owns the decision. It does not read the rule for you, and it does not decide whether the rule applies.

This page is for the CEO or CTO of a company with 20 to 100 engineers and a moat outside software. The rule that changes how the business runs usually comes from a regulator or a payment network, and nobody's job is to watch that page.

The short answer

A working loop has four parts, and different machinery runs each one.

1. A schedule fires. A cron expression or an interval, with the timezone named explicitly, so a weekly check runs at the hour you meant (Scheduled Tasks).
2. A script fetches the page and records it. One approved URL, requested over HTTP, stored with the retrieval date and the raw text.
3. Code compares the text with the last stored copy. The comparison runs in a script or a code-match node, where the same two documents produce the same answer, never in a model's reading of a long page (Workflows).
4. Only if the text changed, an agent writes a change brief. The changed passages quoted, a link to the official page, the date, and the questions the comparison cannot answer. A human-in-the-loop node then holds the run until the named owner responds (HITL Gates).

The owner opens the original, decides whether the change applies, and decides what happens next. The agent's output is a briefing for that person.

Adapting the loop to a real source is configuration work done per source. A source that serves an OpenAPI spec, a GraphQL endpoint or an MCP server can go through a registered script connection, where the credential stays at network egress and the script gets a typed client. A page that serves plain HTML needs a small fetch script with a retry policy (scripts runtime). Either way, the URL and the extractor are per-source decisions that someone makes and writes down, next to the name of the owner.

An illustrative workflow

Illustrative design. This is a hypothetical adaptation of documented patterns to one public source. It is not a shipped regulatory-monitoring feature, and it is not a customer result.

Picture an operations lead at a payments company of about 150 people. The source is one card network's published rules page that the compliance lead chose and approved. The design has five stages.

The schedule. A cron entry runs the workflow every Monday at 07:00 in the company's timezone. The schedule names the timezone, so the run does not drift when the clocks change (Scheduled Tasks).

The fetch. A script node requests the approved URL and stores three things: the page text, the URL it came from, and the retrieval timestamp. Storing the URL with the text is what makes a later brief checkable by someone who was not there when the run fired.

The comparison. A second script node loads the previous stored text and diffs it against the new copy, block by block, keeping the nearest heading with each changed block. A model asked to compare two long pages reports different changes on different runs, and a reviewer cannot tell a real edit from a sampling difference. A script answers the same question the same way every time, which is the property that makes the next step worth reading.

The brief. When the diff is empty, the run ends and says nothing. When it is not, an agent reads the changed blocks in context and writes a brief: each passage quoted under its heading, a link to the official page, the retrieval date, and the open questions such as whether a definition elsewhere on the page still applies. The brief states what changed and what the agent could not establish. It does not say the change is material to this business.

The gate. The run reaches a human-in-the-loop node, which raises an approval request and notifies the named owner, then stays paused until that person answers (HITL Gates). The owner opens the official page, reads the passages in place, and records one of three answers: it applies, it does not apply, or it needs a specialist. The brief and that answer together are the record that a check ran and a person reviewed it.

Adapting this design to your source takes a fetch script or a connector and configuration per source, and the script connections guide is where that starts.

No change is not the same as failed to check

The loop above has two quiet outcomes that look identical from the outside: the page did not change, and the check did not run. Only one of them is good news.

The documented pattern for this is to make the no-op silent and the failure loud. A workflow that finds nothing new exits without notifying anyone, because a scheduled job's default is silence (No-op When Nothing Changed). The same page tells you to distinguish "nothing changed" from "I failed to check" and to treat the second as a failure that alerts.

For a policy source that distinction carries weight. A person who sees no message on Monday concludes the rule did not change, and that conclusion is the whole product of the run. If the fetch returned a 403, a login wall or a page of boilerplate, and no one heard about it, the silence now means the opposite of what the reader assumes. So the failed fetch posts to the owner of the source, with the status code and the URL, and the run records the failure. A run that could not read the page is a broken check, and it should look broken.

The same logic covers the first run. There is no previous copy to compare against, so the first pass stores the text and reports the baseline rather than announcing that everything changed.

A run that never starts leaves no trace inside the loop. The scheduler is a poller on an interval, 10 seconds by default, so a swarm whose API is down, a container that is restarting, or a schedule someone switched off produces no fetch, no comparison, and no failure to report (Scheduled Tasks). The silence is identical to a clean week, and nothing the workflow writes can break it.

Two checks catch that case from outside the run:

• An uptime monitor on the API's /health route, which is unauthenticated, catches the case where nothing can fire at all (Deployment). It proves the API is running, not that this workflow ran, and the deployment guide makes the same point: verify with /health and a completed task, not /health alone.
• A watchdog reads a record the run writes. The fetch step writes a dated entry to the swarm KV store before it compares anything, and a separate check alerts when the entry for this week is missing (KV). That record also makes a gap visible after the fact to whoever reads the history next.

The limitation belongs next to the source list. A watchdog on the same host as the policy check fails with it, so two schedules in one deployment still cannot report that deployment being down. The check that closes the gap has to live somewhere else: an external cron, an uptime service that alerts on a missing signal, or a person who opens the schedules dashboard on a Monday. Without one, a quiet week means either no change or no run.

Where it breaks

Stale sources. A page that stops answering, or that moves behind a consent wall, stops producing comparisons. The alert above tells you it happened; it does not fix the source. Someone has to repair the extractor or approve a new URL, and the run stays broken until they do.

False positives. Navigation and cookie banners change without any rule changing. So do session identifiers, and so does today's date. Reordered blocks read as edits. An extractor that keeps the whole page instead of the rule text will produce a diff every week, and a brief every week is one the owner stops opening. Trim to the part of the page that carries the rule, and treat the extractor as code that needs a test.

Silent source changes. The harder failure is a page that changed meaning without changing text: content moved to a new URL, a PDF replaced the HTML, or the same rule now appears in a different document. A comment thread that says "see the updated schedule" leaves the text identical and the meaning different. Nothing in a text comparison catches that. Keep the source URL in the record, review the source list on a schedule, and treat a page that has stopped changing for a year as a question worth asking rather than a success.

Scope. The loop watches the sources you approved, one URL at a time. It does not know that the same rule also appears in a guidance note or a state-level addendum somewhere else on the internet. A team that reads a quiet report as "we are covered" has read it wrong, and the honest version of that sentence belongs in the brief.

What stays with people

Four things stay with people at every step.

Reading the original. The brief quotes what changed, and the owner still opens the page, because a quoted paragraph can lose the sentence above it.

Deciding what applies. Scope and thresholds depend on facts the agent does not have, and so do exemptions and effective dates. Whether a new rule touches this product or this contract is a judgment with a name attached to it.

Changing policy. The agent never edits a policy document, never updates a customer term and never tells anyone they are compliant. If a rule change requires action, a person writes the change and a person signs it.

Keeping the trail. The owner records the decision and its reason, which is what lets the next person answer "how did we handle that in March" without searching chat history.

When something else fits better

Two cases do not need this.

You need someone to analyze the rule. A specialist regulatory-change service sells jurisdiction coverage and curated interpretation, plus someone to call about a clause. If your team has no capacity to read the source and reach a view, routing a diff to them changes nothing.

You have one or two sources that change rarely. A person reading a page once a month is cheaper and better than a workflow, and the workflow's real cost is maintaining the extractor.

The middle case is where the loop pays: several public sources, each of which one named person must read, changing often enough that nobody notices when one does.

Where to go next

The patterns this page adapts are all public. Lead prospecting shows scheduled discovery with a store of what the run already saw and a human gate before anything goes out. No-op workflows covers the silent-run design. HITL gates covers the pause and the approval. Scheduled tasks and workflows cover the pieces those patterns are built from.

For the reasoning behind this work, our note on the technology operations moat covers why operational knowledge is worth keeping inside a company.

The code is on GitHub under the MIT license.