What your agent can prove to you.

The alarms you have learned to ignore

Three things make link monitoring hard to trust. A publisher blocks automated requests, or serves the page through JavaScript, and the tool reports the link as lost when it is right there. A dashboard shows a count that was true when someone last opened it. And the newer agent tools answer only while a conversation is open, so nothing checks anything on a Tuesday night.

None of that is a secret. A comparison published by LinkGuard on June 22, 2026 and updated September 11, 2026 says Linkody has “no JavaScript-rendered fetching (so links on modern Webflow or React donor pages can read as ‘lost’ when they’re fine)”. A review of the Ahrefs MCP dated July 16, 2026 puts the chat problem plainly: “It only works inside a chat you start. Close the window and nothing happens.” Those are their words on those dates, quoted here as published. The backlink monitor comparison puts Linkody, LinkGuard and AgentLinkOps side by side on how each decides a link is lost.

The rest of this page describes how AgentLinkOps answers each of those problems, with the source line behind each answer recorded in a public claims ledger that the page quotes rather than paraphrases.

Every answer comes with its evidence

A check does not return a green dot. It returns an observation: the page that was fetched, the final URL after redirects and each hop on the way, the HTTP status, whether the publisher’s robots rules allowed the fetch, a SHA-256 hash of the bytes that were read, and a standing warning that JavaScript execution and visual visibility were not checked. The page HTML itself never enters your repository.

Here is one real observation from the demonstration record, dated September 12, 2026, trimmed to the fields that matter to a buyer:

"state": "present", "reason": "link_found", "httpStatus": 200,
"occurrences": [{ "href": "https://iana.org/domains/example", "anchor": "Learn more", "rel": [] }],
"evidence": { "method": "http_html", "complete": true, "bytes": 559, "rendered": false,
  "sha256": "ff67a9d764d6a2367a187734e697f6a53217db9a21c101d410a113ca871a299d" },
"robots": { "allowed": true, "reason": "robots_allowed" },
"warnings": ["Static HTML observation; JavaScript execution and visual visibility were not checked."]

In the hosted service, each saved observation row keeps that hash beside the result. Your agent reads the history with get_link_history and can pull the retained snapshot with get_link_evidence until retention removes it, at which point the call says EVIDENCE_EXPIRED instead of pretending. Raw snapshots expire after 30 days in the pilot; the observation metadata and the history stay.

The desktop CLI runs the same verifier module the cloud runs, imported from the same file rather than copied, and the tests assert that both paths return the same shape for the same cases. The walkthrough shows that observation in the run that produced it, from the import that started it to the event feed that would carry a change. The rules the verifier follows, and the ones it refuses, are on the methodology page.

Unknown is never reported as lost

When a fetch cannot conclude, the result is unknown with a named reason: robots disallowed, a 403, a login wall, a page that needs a browser. An unknown never fails a run and never means the link was removed. Only an expected link, observed absent, in a complete page, counts against you.

Loss itself has a clock. A watch keeps its last verified state and its latest attempt as separate fields. A first absence starts a confirmation window, and confirmed loss needs two complete absent observations at least 30 minutes apart. One retry, then back to the normal cadence. An unknown in between does not advance that clock.

How often does the verifier have to say unknown? The one dated measurement we have is a benchmark run on September 11, 2026 across the hardest pages of a single target domain. Treat every rate as a floor for that sample and date, not a universal accuracy figure.

The unknowns split into named classes on that day: policy refusals 9.1%, transport 4.5%, HTTP 4.3%, login 4.1%, render-required 2.2%. Those shares belong to that sample. The same run found two false presents, traced them to a redirect-to-target case, fixed it and kept the defect in the record; the regression tests for it are in the current source. The full account of that run, with every denominator, the human-labelled set, the render measurement and what the run cannot show, is on verifier benchmark, September 11, 2026.

If you want the reading rules in more depth, how to verify a backlink still exists and backlink missing but the page is live walk through complete and incomplete observations with worked examples.

Read the meter before a bill exists

Every queued check reserves one unit. The unit is consumed only when its observation is saved, including an unknown or an unavailable source. A check that fails for good, or is cancelled, releases its unit. get_usage reports those three totals separately: reserved, consumed and released. Folding reserved into consumed would overstate what happened, so the service refuses to.

The same call returns a check_budget block naming the enforced monthly ceiling and what remains of it, so your agent can size a watch list against a number you can see. Payment collection does not exist in this build: there is no checkout, and no price on this site can be charged. Hosted access is invitation-only; who can use the service today, what the scopes permit and how long each kind of record is kept are on the access and data page.

Leaving is a file copy

The ledger that declares what you expect and want from each source page is a plain JSON Lines file in your own repository. Cloud sync mirrors that file and never writes back into it. Your prospects, your outreach history and your combined CRM were never uploaded, because the service has no place to put them. It monitors the URLs you supply and keeps observations about them.

What the cloud does hold, you can take out. export_link_watches pages through every monitored placement with its state, over MCP or the REST route, for local CRM recovery. The local CLI reads a SQLite CRM and previews before writing, naming every status it treated as active. There is no format that only the workspace can read.

Read more about the file itself in keeping a backlink ledger in your repository.

Read the first pilot record: one of our founder’s own sites, run as a pilot workspace, with 359 ledger rows, a first census and its unknowns, and one placement, every count with its denominator and date.

Checks and events continue after the chat closes

This is the one comparison we make against read-only data servers, and it is checkable. A hosted watch carries a cadence and a next-check time. The Worker’s own five-minute schedule dispatches whatever is due, with nobody connected. Changes land in an event feed your agent reads with list_link_events and an opaque cursor, and signed webhooks deliver on their own ten-minute schedule.

The MCP.Directory roundup of SEO servers, marked updated June 2026, describes the category this way: “these servers are almost all read-only. They analyze; they don’t publish, schedule, or alert.” That is their summary on that date. Ahrefs, Semrush, Majestic, Moz, DataForSEO and Search Console are suppliers here, not rivals: their exports come in as rows through the import formats. The read-only SEO MCP server comparison sets the Ahrefs, SE Ranking and ContextBolt servers beside AgentLinkOps on what runs after the chat closes, with each vendor’s published price.

What this does not say: that the service is always up, or that a check is guaranteed to run at a given minute. A schedule in the code is proof that scheduling exists. The status page records which version is deployed and how to check it yourself, and it carries no availability percentage, because nothing measures availability yet.

What this page does not claim

• No ranking effect. A verified placement is a link that exists; nothing here predicts what a search engine does with it.
• No verified email addresses. Published contact routes are extracted from a saved complete page; deliverability is never checked or implied, and the service sends nothing.
• No live discovery. Requests for new supplier discovery and new competitor inventories stop before persistence in this build with PROVIDER_NOT_CONFIGURED. Imports and comparison of inventories you already hold work today.
• No tool count. The registered backlink tools is generated from the registry at build time; a number typed here would drift.
• No open signup. Hosted access is invitation-only, and reading the public brief creates no account and starts no monitoring.

Ask your agent to prove it

If you already have an invited account, paste this into your agent. It asks only for reads; it creates nothing and starts no checks.

The four calls in that prompt are the same four the agent brief gives an agent that has to explain this product to a person: dated evidence, unknown kept apart from lost, a readable meter, and a schedule that outlives the session.

How this page was checked

Written September 15, 2026 against the repository at commit 9e7aa69. Each product statement quotes a row of the DP-0023 claims ledger (W-01, W-02, W-06, W-07, W-08, W-09, M-04, M-06, B-01 to B-04, A-01 to A-03, A-10 and P-01 to P-06), and each ledger row names the source file and line or the dated acceptance record behind it. The competitor sentences are rows C-01 to C-03: public statements fetched on September 15, 2026, quoted with their own dates. The deployed version behind the hosted calls on this page, and the exact requests that verify it, are on the status page.

A changed source file voids a claim until it is rechecked. If a sentence here no longer matches the product, the ledger is where the correction starts.