Your AI Agent Does Not Need “the Internet.” It Needs a Retrieval Plan.

The ticket that causes the problem

The requirement usually arrives as one line: give the assistant web access so it can answer questions about current products. Everyone nods, because it sounds like a technical task with a technical answer. It is not. It is a product brief with five holes in it, and whoever implements it will quietly fill them in — usually with defaults nobody reviewed.

You can see the holes in the bug reports that follow. “It cited a blog post from three years ago.” Nobody specified freshness. “It quoted a competitor's marketing page as if it were our documentation.” Nobody specified scope. “It answered even though the page didn't say.” Nobody specified what to do when the evidence runs out.

Three tasks that are too loose to implement

• “Research this company.” Research what about it? A ten-line profile and a due-diligence brief share a verb and nothing else.
• “Check what competitors are doing.” Over what window, across which pages, and what counts as a change worth reporting?
• “Find the current pricing.” Current as of when, from which page, and in which currency — and what should happen when pricing is “contact us”?

Each of these can be implemented. Each will be implemented differently by two engineers on the same team, and neither implementation will be wrong in a way you can point at.

The plan

objective: >  Decide whether our entry tier is priced above the visible market  for teams of 5-20 seats. sources:  allow:    - pricing pages on the five named vendor domains    - vendor documentation for seat and usage definitions  deny:    - review aggregators, forums, resellers    - archived or cached copies scope:  start_urls: [ "<vendor>/pricing" ]  max_pages_per_domain: 4  follow: [ "/pricing/*", "/plans/*" ] freshness:  max_age_days: 14  on_stale: refetch, then report age with the value output:  shape: records  fields: [ vendor, tier, monthly_price, currency, seats_included, source_url, excerpt ]  nulls_allowed: true escalation:  thin_evidence: return the record with nulls and a note; do not infer  conflict: return both values with their sources  interaction_required: flag for human review

The product decision hiding inside the technical decision

Every field above looks like configuration and is actually policy. Freshness is a claim about how wrong you are willing to be. Scope is a claim about whose information you are willing to repeat. The escalation rule is a claim about what your product does when it does not know — and that is the single most visible quality signal a web-enabled feature has.

Left unspecified, these get decided by whoever writes the prompt, on the afternoon they write it. That is not a criticism of engineers; it is what happens when a product question is delivered as a tooling request.

What to do this week

1. 01Take the web-enabled task your team argues about most and write the six fields for it.
2. 02Show the filled plan to the person who files the quality complaints and let them edit the freshness and escalation lines.
3. 03Log the plan alongside each run, so a bad output can be traced to the specification rather than to a vibe.