Outrings
AI agents and automation

What data does an AI agent need before recommending website changes?

The minimum an agent must have in hand before its advice is worth acting on — and what each missing piece causes it to get wrong.

4 min read
Short answer

Five things: the current state as measured rather than assumed, the evidence behind each finding, the cost of each fix, an explicit account of what was not checked, and a way to verify afterwards. Missing the first produces advice for a site that is not yours. Missing the fourth produces confident advice about areas nobody examined.

Why generic advice fails specifically

An agent without measurement gives the advice that is right for the average site: add a CSP, compress images, write meta descriptions, improve alt text. Some of it will already be done. Some will not apply. One item might be genuinely urgent and will be buried at position six because nothing in the input said it mattered more here than anywhere else.

The advice is not wrong so much as unaddressed. It was written for a site, not for your site.

The five inputs

1. Current state, measured

What is actually configured right now — headers present and their values, certificate expiry, DNS records, crawler rules as resolved rather than as written. Without this the agent cannot tell you what to change, only what people generally change.

2. Evidence per finding

The observation the verdict came from. This does two jobs: it lets the agent explain why rather than asserting, and it lets you check the claim without re-running anything. "No CSP header" is a verdict; "no Content-Security-Policy in the response headers" is an observation you can confirm in a browser devtools panel in five seconds.

3. The cost of each fix

Severity alone produces bad prioritisation. A critical issue that takes three weeks and a moderate one that takes four minutes should not be ordered by severity — most people should do the four-minute one first. An agent needs effort alongside impact, or it will hand you a list sorted by anxiety.

4. What was not checked

The field that stops "here is what to fix" being read as "here is everything wrong". Without it, an agent that examined SEO will imply your security is fine, and a user will act on that implication. Explicit coverage boundaries are what make an agent's silence safe.

5. A way to verify afterwards

A recommendation you cannot check is a suggestion. The agent should be able to re-measure after a change and confirm the specific thing moved, which also catches the common case where a fix was applied to staging, or to the wrong host, or silently reverted by a CDN.

What each missing piece looks like in practice

MissingSymptom in the advice
Measured stateRecommends things already done; misses the one thing actually broken
EvidenceCannot answer "how do you know?"; you must re-verify everything by hand
EffortA list sorted by severity where item one takes a month and item nine takes a minute
CoverageConfident silence about entire areas nobody looked at
VerificationNo way to tell a real fix from a change that did not take effect
If you only add one of the five, add coverage. It is the cheapest to supply and it converts an agent from something that implies completeness into something that states its own limits — which is the difference between advice you can act on and advice you have to double-check.

A concrete ordering

With all five present, a good agent will produce something closer to this than to a generic checklist:

  1. Name what is measurably wrong, with the observation attached.
  2. Order by points recovered per unit of effort, not by severity alone.
  3. State plainly what was not examined and what that means for the advice.
  4. Make the change.
  5. Re-measure and confirm the specific finding cleared, rather than assuming it did.

Step five catches more real problems than most people expect — configuration changes fail silently far more often than they fail loudly.

What our audit reports about this

Every item below is measured directly, not inferred. Run it against your own site and the result names the exact rule or header responsible.

  • The current state of every check, measured directly, with the raw observation attached to each verdict.
  • An effort estimate alongside severity on every finding, and a ranked list computed from points recovered per unit of effort.
  • A notCovered array and a separate undetermined bucket on every response.
  • A changes endpoint that re-measures and reports what moved since the last snapshot, so a fix can be confirmed rather than assumed.

For agents and scripts, the same measurement is at /api/v1/summary?url=yoursite.com — see the API documentation.

Related questions

Is severity not enough to prioritise?

It is half the input. A critical finding requiring an architectural change and a moderate one requiring a single header line should not be ordered by severity, because most people will complete the second and abandon the first. Ranking by points recovered per unit of effort produces a list people actually finish.

How does an agent know the effort?

It has to be supplied — a model estimating effort from a finding title is guessing. Outrings returns an explicit effort band on every finding, derived from what the fix involves rather than from how bad it sounds.

What if the agent recommends something that breaks the site?

This is why evidence matters. A recommendation with the observation attached can be evaluated before it is applied — you can see that the header is genuinely absent rather than trusting that it is. Advice without evidence has to be taken on faith or verified from scratch.

How do I verify a fix landed?

Re-measure. The /changes endpoint compares against the previous snapshot and reports which findings cleared, which appeared, and how each category moved — so you find out that a CDN stripped your new header before a user does.

Read next

All 100 guides · How every check works · API for agents