agentlinkopsA first pilot record: about 1,651 sends, one placement, five links
One pilot workspace, September 2026: 359 ledger rows, 49 hosted watches, a first census with its unknowns, and one placement that grew to five links.
This is the first record we can publish, and it comes with a disclosure. The site in it is one of our founder's own sites, a legal-information publisher, run as a pilot workspace. We operate that site and we build this product, so read what follows as an operator's record and never as a customer testimonial. Every number below comes from that site's own operations record, dated September 13 and 14, 2026, and each one keeps its denominator. The record draws no line from any link to any ranking. No message in this story was sent by AgentLinkOps; the site's outreach ran through its own tools, and the hosted service only checked pages it was given.
What the site had before the pilot
The site had been building links for months with an agent doing the research and a person approving each send. By September 2026 its outreach records held about 1,651 link-lane sends. Its local ledger, a plain JSON Lines file in the site's repository, held 359 entries: 52 placements the site's CRM believed were live, and 307 opportunities it still wanted.
A first local check on September 13, 2026 at 02:11 UTC ran the desktop verifier over all 359 entries. It found 13 present, 291 absent, 51 unknown and 4 source pages unavailable. Most of the absences belong to the 307 wanted rows, where no placement existed yet, so absence there is the expected reading. The ordinary question sat with the 52 rows the CRM called live: which were still there, which had gone, and which could nobody tell from a static fetch?
What moved to hosted checks
On September 13, 2026 the site connected its agent to the hosted service through an MCP client with OAuth, read the workspace and its limits, checked that no project existed, and created one. Before any watch existed, a script wrote a row-level decision for all 359 entries and hashed the ledger and its observations, so the record could show afterwards that nothing local had changed.
| Ledger slice | Count of 359 | Where it lives |
|---|---|---|
| Expected placements, CRM live | 52 | 49 hosted watches plus the local ledger |
| Of which shortener sources | 3 | Local only. A shortener redirects to the target, so a source fetch cannot show an independently placed link |
| Wanted opportunities | 307 | Local only. There is no placement to verify yet |
The 307 prospects never left the site's repository. The hosted service holds the 49 supplied source and target pairs and its own observations about them. Each watch carries the local ledger id as local_reference, so hosted results join back to ledger rows without matching URL strings. That mattered: the service stores source URLs in normalized form, and two of the 49 rows would have misjoined on an exact string match.
Five watches went first, chosen for variety: one locally present, one locally absent and three unknown for different reasons. The hosted verifier returned the same state and the same reason as the local verifier for all five. Then the remaining 44 followed. Re-issuing an identical monitor_link call returned the same watch with created: false and no new observation, and re-running the plan against a fresh watch export proposed zero new watches.
The first census, and how to read it
Between 18:46 and 18:50 UTC on September 13, 2026, the 49 watches had their first observations.
| Hosted state | Count of 49 | Note from the record |
|---|---|---|
| Present | 9 | Includes one page the local verifier could not fetch. Two vantages beat one |
| Suspected missing, absent with complete evidence | 14 | The local verifier had 17 absences, minus 4 the hosted fetch could not reach |
| Unknown | 25 | Robots disallowed 10, HTTP 403 5, render required 4, crawl delay 5, robots file not plain text 1 |
| Source unavailable | 1 | A 404, matching the local result |
Half the watches came back unknown. The record's own reading rule is the one to copy: "an unknown is not an absence and not evidence of loss." The 25 unknowns are the placements where a static fetch cannot speak: profile pages behind robots rules, hosts that answer 403 to automation, pages that need a browser. Static presence for the other nine says nothing about whether a human reader sees the link. The walkthrough and the methodology page describe the same states from the product side.
The 14 suspected-missing watches each got one confirmation retry about 30 minutes later. A second complete absence moved a watch to confirmed missing and returned it to its weekly cadence. The meter recorded that retry: consumption moved from 49 to 64 checks, roughly one extra check per state change, then stopped. By September 14, 2026 at 00:20 UTC the census over 54 watches read 11 present, 14 confirmed missing, 28 unknown and 1 source unavailable.
The two verifiers disagreed only on whether a fetch was possible, never on what a fetched page contained. Four pages the local machine could read came back 403 or crawl-delayed from the hosted fetch. One page the local machine could not read, the hosted fetch read and found the link present. One page the local verifier read as absent, the hosted fetch marked unknown because its robots file was not plain text. The site's rule for this went into its checklist: treat the two as two vantages, join them by ledger id, and never let either side's unknown overwrite the other's finding. The guide to a missing link on a live page works through the same distinction.
The one placement, and what it became
The outreach cross-check found something the monitoring had missed. Across about 1,651 link-lane sends, the site's records showed exactly one earned placement: a state legal-resources page that had replied once and linked, first seen on August 11, 2026. Nothing was monitoring it.
A live fetch on September 13, 2026 found the placement had grown. The page carried five dofollow links to five different pages of the site, as bare-URL anchors with tracking parameters on every href. The site added five expected entries to its ledger with path scope, so that a change to the query string would not read as a loss, and the local check found 5 of 5 present. Five hosted watches followed on a weekly cadence with the same join discipline, bringing the workspace to 54 watches.
At close-out on September 14, three of the five had first observations, all present with full occurrence evidence. The last two were still queued, because the worker spaces repeated fetches of the same host with growing politeness delays. Each watch's next_check_at of September 21, 2026 was the backstop, and the record says so rather than calling the two pending checks done.
That is the whole result: one publisher, one reply, five links, five ledger rows, five watches, and a dated evidence record for each. The record draws no line from those links to any search result, and neither does this page. The post on reading search trends beside placement dates explains why one link is never credited.
What it cost, in units the site could read
The hosted meter for September 2026 showed 64 checks consumed by the end of the first day: 49 first observations and 15 confirmation retries. Reserved and released were reported as their own totals. At weekly cadence the record sized the steady state at about 210 checks a month for 49 watches, plus one confirmation check per state change.
Here is the one friction that the record calls a product problem, and how it closed. On September 13 the workspace call reported a monthly check limit of 3,500 while the usage call reported a plan allowance of 300 checks with a hard stop, and the smaller number looked binding. Mid-session the workspace ceiling was raised to 30,000 while the allowance stayed at 300. At about 00:10 UTC on September 14, 2026 a deployment changed the answer: the usage call began returning a check_budget block naming the workspace monthly limit of 30,000 as the enforced ceiling, with plan_allowance_enforced: false and a note that plan allowances are used only for billing estimates. The sizing question went away; 54 weekly watches came to roughly 232 checks a month against 30,000. No payment was collected, because payment collection does not exist in this build. The access and data page and the usage reference carry the same budget semantics today.
What went wrong, in the record's words
- One watch appeared unaddressable by id for an afternoon. The cause was a single dropped character in a hand-copied id. The service refused to alias the mistyped id to a real watch, which is the correct behavior, and the lesson went into the site's checklist: never retype opaque ids between calls.
- Source URLs are stored normalized. Joining on the ledger id instead of the URL string solved it, and the product side took a documentation note.
- The standalone CLI needed a scoped API credential that no customer path minted at the time. The site ran hosted operations through the MCP client until a September 14 release added the credential flow.
- Project creation had no idempotency parameter, so the guard was procedural: list projects first, reuse by name and domain. The record notes it as an operator item.
What this record does not show
- No ranking effect. Every count above is a link that exists, or an attempt that could not conclude. Nothing here predicts what a search engine does with a placement.
- No sending. About 1,651 sends is the site's own outreach count from its own tools, quoted for the denominator. AgentLinkOps sent none of them and does not evaluate that campaign.
- No rendered visibility. Static presence in complete HTML says nothing about what a reader sees after scripts run.
- No completed set. Two of the five placement watches had no first observation at close-out. The record keeps them as pending, and so does this page.
- No sample. One site, one operator who also builds the product, and one publisher. That is why the site and the publisher stay unnamed here, and why this page makes no general claim from them.
How this record was checked
Written September 15, 2026 from the site's operations record: the results summary and friction log dated September 13, 2026 and updated September 14, 2026, held by AgentLinkOps as the operator record and not published. Every count above quotes a line of that record with its denominator. The product statements about unknown, the confirmation window, the three usage totals, the local ledger and the budget block quote rows W-06, W-08, P-03, P-05, A-03 and A-14 of the public claims ledger behind what your agent can prove. The status page names the deployed version behind the hosted calls. Keeping the ledger itself is covered in keeping a backlink ledger in your repository, and the check routine in how to verify a backlink still exists.
Sources
- What your agent can prove to you · AgentLinkOps · 2026-09-15
- How AgentLinkOps works, step by step · AgentLinkOps · 2026-09-15
- Access limits and data handling · AgentLinkOps · 2026-09-15
- Get usage · AgentLinkOps documentation · 2026-09-15
- Service status and deployed version · AgentLinkOps · 2026-09-15