Substantive update: October 19, 2026. This guide replaces unsupported productivity percentages with a concrete workflow and evaluation checklist.
A chatbot can explain why a web page might be missing from search. An AI agent can inspect the page, read a permitted report, choose a follow-up check, and produce evidence. Whether it should also edit the website is a separate decision about access and verification.
The useful question is: which steps need judgment, and which can run as ordinary code? Start there before choosing an agent framework or buying another tool.
Chatbot, Workflow, or Agent?
| Pattern | Who chooses the next step? | Example | What to verify |
|---|---|---|---|
| Chatbot | The user directs each exchange | Explain a canonical tag from a pasted HTML fragment | The answer matches the supplied evidence |
| Fixed workflow | Application code follows a known sequence | Fetch three URLs, parse their metadata, return failed checks | Parsing, status handling, and the expected URLs |
| Agent | The model chooses from permitted actions after observing results | Investigate why a page is excluded, then inspect the relevant response or report | Tool boundaries, evidence, stopping rules, and the final conclusion |
This distinction follows the architectural vocabulary in Anthropic's Building effective agents, published in 2024. It is a design reference, not a claim about the current features of every product. A chat interface can front any of these patterns.
Work Through One Bounded Example
Suppose you maintain a developer blog and want to investigate three important pages. The deliverable is a short report identifying response errors, missing or conflicting canonical tags, and checks that still need Search Console access.
A repeatable fetch-and-parse stage belongs in code. An agent becomes useful when the result changes the investigation: one page redirects, another returns an error, and a third looks correct but is excluded in Google's stored index.
Give the system a task brief before it starts. This example describes requirements; it is not an SDK configuration file:
{
"task": "Audit three supplied website URLs",
"inputs": ["exact URL list", "expected canonical for each page"],
"allowed_actions": ["read supplied pages", "read authorized reports"],
"approval_required": ["edit files", "deploy", "request indexing"],
"output": "Per-URL findings with status, canonical, and evidence date",
"stop_when": ["every URL has a result", "required access is unavailable"],
"limits": {"maximum_requests": 12, "maximum_minutes": 10}
}Those limits are illustrative. Choose a budget that fits your own workload, then enforce it in the application rather than relying on the model to remember it.
Observe the Result Before Choosing Another Action
| Observation | Useful next step | Unsupported conclusion |
|---|---|---|
| A URL returns an error | Check the final URL and relevant server logs | The article needs more keywords |
| Raw HTML contains a correct canonical | Compare it with the authorized index inspection | Google has already selected that canonical |
| A live test can fetch the page | Record current availability and inspect the stored index state separately | The page has been reindexed |
| A local fix passes checks | Prepare a reviewable change and verify the deployment when authorized | Production is fixed |
For the website-specific checks, use the SEO fundamentals audit. Google's URL Inspection documentation explains the distinction between indexed information and a live test.
Keep Tool Access Separate From Tool Selection
An agent deciding that a deployment would help does not grant it permission to deploy. Give read operations and write operations different application-level permissions. Validate the arguments before executing either one.
For this audit, the fetch tool can accept only supplied website origins and a bounded number of requests. It should return the status, final URL, relevant headers, and raw metadata. Report readers should receive access only to the intended property. Credentials belong in the execution layer, not in prompts or saved findings.
A write stage can prepare a patch for review. Publishing that patch is a distinct operation with its own authorization and verification. This separation also makes a failed run easier to understand: you can see what was observed, what was proposed, and what actually changed.
The tools, permissions, and MCP guide develops those boundaries further. For a broader reading path, visit AI coding agents.
Test Failure Cases Before Increasing Autonomy
A polished demonstration usually shows the successful path. A useful pilot also includes cases where the system should stop, report uncertainty, or avoid a write.
- Missing access: a report requires login. The agent identifies the missing source and stops the dependent check.
- Conflicting evidence: current HTML and the stored index disagree. The report preserves both dates instead of silently choosing one.
- Unexpected redirect: the destination leaves the allowed origins. The runtime enforces the boundary.
- Incomplete execution: one page times out. The output marks it unresolved rather than inventing a result.
- Insufficient evidence: a suggested cause cannot be established. The report states the observation and the next check needed.
Record completion rate, incorrect conclusions, blocked actions, elapsed time, and review effort. Compare the agent with the fixed workflow on the same cases. A more flexible system earns its place when that flexibility produces useful results at an acceptable total cost.
The benchmark methodology guide explains why the same task set and success rule matter when comparing systems.
A Practical Starting Point
Choose one workflow whose success you can inspect. Define its inputs, allowed actions, failure cases, and output. Automate the predictable steps first, then add model-directed decisions where the evidence requires them.
Before expanding access, review actual runs: did the system preserve uncertainty, use the right source, stop at the boundary, and produce an artifact someone could verify? Those observations tell you more than a general claim that agents make every team faster.