The agentic web has two architectures, not one.

When Google named information agents at I/O 2026, the press treated the announcement as a single category. It is not. The work of "watching the web for you" splits cleanly into two systems with different inputs, different freshness budgets, different failure modes, and different jobs to do.

This is a glossary, written down before the marketing departments water the words down.

The short version

Open-web agents scan the web for a topic. You hand them a question. They roam. Page monitors verify state on a specific URL. You hand them a page. They watch.

Both are needed. Neither replaces the other. The mistake the press has been making is treating them as the same thing because they share a buzzword.

Two instruments, two jobs. Discovery scans the horizon; precision examines one specimen.

What is an open-web agent?

An open-web agent is an AI agent that continuously samples the open web on behalf of a user, synthesizes what it finds, and reports back. The input is a topic, a question, or a persistent interest. The output is a synthesized briefing across many sources.

The current named players in this layer:

• Google Information Agents (rolling out Summer 2026, AI Pro and Ultra subscribers)
• ChatGPT Pulse (live since September 2025, Pro subscribers)
• Exa (developer API, raised a $250M Series C in May 2026)
• Perplexity (subscription-based research surface)

Open-web agents inherit the architecture of search. They crawl, index, retrieve, rank, and summarize. What makes them "agentic" is that the work happens in the background, on a recurring basis, without the user re-typing the query. The freshness budget is wide and shallow: the agent samples a lot of pages, none of them deeply.

Strengths:

• Good when you do not know where the answer lives
• Good at synthesis across many sources
• Good at unstructured topics ("what is happening in fusion energy this week")
• Good at discovery

Limits:

• Cannot reliably watch one specific page at a defensible cadence
• No timestamped audit trail of "what changed and when"
• Visual or structural changes on a single URL fall outside the model
• Hallucinated change reports are a known failure mode

What is a page monitor?

A page monitor is a system that watches one specific URL on a schedule, detects changes, classifies them, and routes an alert. The input is a URL. The output is a change event with a timestamp, a diff, and (if the platform is doing its job) an AI-generated summary of what changed and whether it matters.

The category leader in this layer is Visualping, which has been doing this work since 2017.

Page monitors inherit the architecture of testing and observability, not search. They poll, they diff, they alert. They do not synthesize across sources. They tell you, with audit-grade evidence, that one specific thing changed on one specific page.

Strengths:

• Tight, repeatable cadence on a specific URL (down to one minute on serious plans)
• Visual diffing on JavaScript-rendered pages
• AI classification of whether a change is important enough to alert on
• Timestamped evidence that holds up in a compliance review or a court filing
• Cost per page is roughly constant; cost per topic is unbounded

Limits:

• You have to know which URL matters
• Will not discover a new page on its own
• Cannot synthesize across sources unless you wire multiple monitors together

Side by side

The table is the whole argument. The two columns are different systems. A team that buys one and thinks it bought the other is going to be unhappy.

How they compose

The most important thing to understand about this category is that the two layers compose. They are not in competition. They feed each other.

A practical workflow:

1. Discovery. An open-web agent watches a topic ("competitor pricing changes in enterprise CRM"). It samples the web, finds twelve relevant URLs, and notes which ones look load-bearing.
2. Precision. Those twelve URLs get handed to a page monitor with a five-minute cadence, a visual-diff configuration, and an AI prompt that flags pricing changes specifically.
3. Action. When the page monitor fires a change event, a downstream agent decides what to do. That agent might be a sales agent, a competitive-intelligence agent, or a workflow in a coding tool. The actions are concrete: update the battlecard, alert the deal team, file the change in a ticket.

The discovery layer finds the page. The precision layer verifies the page. The action layer acts. Three jobs. Three systems. One architecture.

Discovery feeds precision feeds action. Three jobs, three systems, one architecture.

This is also the most defensible answer to the question "is Google going to put us out of business?" Google's information agents will sit in the discovery layer. They will not, in any near version, watch your five thousand specific pages every five minutes with visual diffing and timestamped evidence. That is a different system, with different economics, built by different people.

A decision matrix

If you are picking which layer to wire into your own workflow, the question is simple.

• You know the URL that matters → page monitor. A specific competitor's pricing page, a regulator's docket, a tender board, your own deploy. Hand it to a page monitor.
• You know the topic but not the URLs → open-web agent. A general interest in "AI regulation" or "fusion-energy funding announcements." Hand it to an information agent.
• You need a timestamped change record for compliance, legal, or audit → page monitor. Discovery agents cannot give you defensible evidence that a specific page changed at a specific time. Their architecture does not produce that artifact.
• You need synthesis across sources → open-web agent. Monitoring layers are bad at this. They produce events, not narratives.
• You need both → wire them together. Discovery feeds precision feeds action.

What this means for builders

If you are building on top of AI coding agents, the architecture matters more than the buzzword.

Anyone who has spent a weekend with Claude Code, OpenAI Codex, or Google Antigravity has hit the same wall. You ask the coding agent to "watch this dashboard and ping me when the build status changes." The agent reasons well. The agent writes code well. The agent has nowhere to put the actual watching.

It needs a monitoring primitive it can call.

Visualping is that primitive. The Visualping MCP is in public beta and works as a custom connector in both Claude and ChatGPT. The full walkthrough lives in the developer cornerstone for this series.

Wire Visualping into your AI agent in four clicks.

In Claude: Settings → Connectors → Add custom connector → paste https://visualping.io/mcp/sse. In ChatGPT: Apps → gear icon → Create app → paste https://visualping.io/mcp/sse.

The REST API is on every plan, including Free, for webhook and code-first patterns. The Personal plan ($10/month) is the realistic entry point for an individual developer.

Once the connector is wired, the architecture from the earlier section becomes a concrete pipeline. The coding agent asks the open-web agent for candidate URLs. The coding agent asks Visualping to watch them. Visualping returns verified change events. The coding agent takes action.

A snapshot from the precision layer

A quick sample of what page monitors do at scale, so the architecture is grounded in something concrete.

In a same-day snapshot of active Visualping monitors on May 24, 2026, 52,452 monitors ran on a five-minute-or-faster cadence. Tender boards, regulatory dockets, SEC filings, status pages, competitive pricing pages.

In a sample of 53,607 user-written alert conditions, the largest clusters are: price drops (1,171), inventory availability (948), registration openings (748), and tender/RFP monitoring (690). Specific, named, scheduled outcomes.

Open-web agents do not produce data that looks like this. They produce summaries. The two systems generate fundamentally different artifacts, and that is the simplest test for which one you actually need.

Frequently asked

Is an open-web agent the same thing as an AI search engine?

No. An AI search engine answers a question on demand. An open-web agent runs in the background, on a recurring schedule, and surfaces changes or updates without the user asking each time. ChatGPT answering "what is the latest on fusion energy" is search. ChatGPT Pulse sending a daily fusion-energy briefing is an open-web agent.

Is a page monitor the same thing as a web scraper?

No. A web scraper extracts data on demand. A page monitor watches a page over time, detects changes, and alerts. Scrapers are stateless; monitors are stateful. A scraper can be the engine inside a monitor, but the monitor is the system that does the watching, classification, and alerting.

Why can't an open-web agent just monitor specific pages?

It can sample them. It cannot reliably watch them at a tight cadence with a defensible audit trail. The architecture is built to sample many sources broadly, not to watch one source deeply. Trying to make a discovery agent into a precision monitor is the same kind of mistake as trying to make a search engine into a database. Both are possible at small scale; neither is the right tool past that point.

What is the difference between an information agent and a monitoring agent?

"Information agent" is the consumer name Google gave to the discovery layer at I/O 2026. "Monitoring agent" is a category-adjacent term sometimes used for the precision layer. The cleaner distinction is the architectural one: discovery versus precision. Both are agents. Both run continuously. They do different work.

Do open-web agents replace SEO?

No. They change which audience is reading your site. The third audience now is AI agents acting on behalf of users, which is a separate discipline called agent search optimization. Open-web agents are how that audience finds you. Page monitors are how a different audience (you, watching your competitor) keeps up with them.

What does "monitoring primitive" mean?

A monitoring primitive is the lowest-level building block for any agent that needs to know when web state changes. It exposes a small interface: create a monitor on a URL, get a webhook when something changes, read recent change events by ID. Higher-level agents call it the same way browsers call TLS or databases call an index. The Visualping MCP and REST API are both shaped this way.

Closing

Two architectures. Two jobs. One stack.

The press will keep collapsing them into "AI search" for another year or two. The teams that get ahead are the ones that learned the vocabulary now: discovery and precision, open-web agents and page monitors, synthesis and verification. The category Google named at I/O 2026 has a substrate. Naming it is the first step in being able to build on it.

Eric Do Couto is Head of Marketing at Visualping. He writes about the architecture of monitoring, AI agents, and the slow business of category formation.