AI visibility tools vs agencies: who owns ongoing corrections?
Agencies own strategy, tools own diagnosis. Who rewrites your product pages after every release? A responsibility table for seven AI visibility jobs, and a real correction test with its limits.
- Written by
- Arun Bhalla (opens in a new tab)
- Published on
- Read time
- 15 min
ContextQA, an EkLine customer, reports that over one quarter "ChatGPT alone pulled more pages from ContextQA's documentation than every human visitor combined." For an API or developer-tool company, the docs are where assistants learn what your product does. When those pages fall behind a release, the assistant can keep repeating the old facts.
Your visibility dashboard, or your agency's monthly report, says AI assistants describe your product wrongly or recommend a competitor. The report names the problem. None of the agency or tool pages we read says who re-corrects your product facts after the next release.
Our recommendation is to split the work. Let an agency own strategy and off-site coverage if you need them. Let a tool, or EkLine's buyer-question report, own diagnosis. Put corrections next to your code, merged pull requests, tickets and release history, with a person approving each change. EkLine does that job: it drafts corrections from your product sources and ships them through your own docs review.
TL;DR
- AI visibility breaks into seven jobs: diagnosis, source freshness, corrections, drafting, review, publication and retesting. Each one needs a named owner.
- Leading tools now draft, refresh and publish content with an approval step, and agencies own strategy and off-site work. None of the pages we read assigns an owner for re-correcting product facts after each release.
- For a developer-tool company, that job belongs next to the code. EkLine drafts the fix from your repos, merged pull requests, tickets and release history, and your team approves it.
- Publishing a page does not always move answers. Of the two buyer questions EkLine published posts for in its own test, one moved on one engine and the other did not move at all.
- A person still approves every change, publishes marketing pages, picks the questions, owns off-site work and starts every rerun.
Why corrections are the job that repeats
Assistants reach your pages only through the public web, by searching and fetching them. EkLine's buyer-question guide says a fix "can change their answers only once it is live on your public site." A strategy deck or an audit happens once. Your product changes with every release, and the page an assistant cited last month can be wrong this month.
That makes accuracy on your own pages a recurring cost, and it lands on the pages developers and agents read most. Socure used EkLine to break long integration guides into sections agents can parse, and EkLine's reviews help keep its API reference correct as fields and SDKs change. Its case study reports that "AI assistants now generate code that aligns with Socure's actual API surface." The upkeep runs at volume: in seven weeks, Socure's one technical writer merged 348 documentation updates.
Seven jobs, three owners
The table below compares three ways to staff the work: an agency, an internal team with a visibility tool, and EkLine (our product) working with your team. Each cell names who does the work. The agency and tool cells come from those companies' own public pages, read in November 2026. Where a page says nothing about a job, the cell says so.
- Diagnosis: finding which answers are wrong, and why.
- Source freshness: keeping the pages assistants read current after each release.
- Corrections: fixing a wrong product fact on a page you own.
- Drafting: writing new content, such as a comparison or a post.
- Review: checking facts before anything ships.
- Publication: getting the change live.
- Retesting: asking the same questions again to see what moved.
| Job | Agency | Internal team with a visibility tool | EkLine with your team |
|---|---|---|---|
| Diagnosis | The agency audits and watches prompts. Omnius lists an LLM visibility audit and prompt monitoring. | Your marketer reads the tool's dashboard and decides what the data means. | The buyer-question report shows which answers fail, who was recommended instead, and which pages the assistants cited. |
| Source freshness | Your team. The agency pages we read do not list this work. | Whoever you assign. The checklists we read name no owner. | EkLine reviews pull requests into your default branch as they open and comments when it finds docs impact. Your team merges the docs change. |
| Corrections | Your team. The agency pages we read do not list this work. | Someone on your team edits the page by hand. | EkLine's Docs Agent checks the problem is real and improves an existing page where it can. You review the change and raise the pull request. |
| Drafting | Agency writers. Draft.dev offers engineer-reviewed posts, tutorials and comparison pages. | Your marketer, or the tool's agents drafting from your brand kit and knowledge base. | EkLine's Marketing Agent drafts posts and comparisons from your repos, merged pull requests, release tags and closed tickets. |
| Review | The agency's editors, then whoever signs off on your side. | A person on your team, in the tool's approval step. | For blog posts and drafts that name your product, EkLine checks every claim against its sources first. Your team reviews the pull request, help-center edit or draft. |
| Publication | Your team publishes on your site. The agency places coverage on other sites. | The tool publishes to your CMS after approval, or serves agents an approved version of your site. | Docs ship when your team merges. Help-center edits publish when you approve. You publish marketing posts yourself. |
| Retesting | The agency, in its reports. No agency page we read states a cadence. | The tool asks the prompts again on its schedule, or someone re-checks by hand. | Someone on your team reruns the questions, and EkLine compares the new report with the baseline. |
The gap sits in two rows: source freshness and corrections, the two jobs that come back after every release.
What tools and agencies already do well
Tools now do much more than report. Profound Agents run research, writing and publishing in one cycle, with an approval step before anything publishes. Profound's CMS nodes can queue drafts for human review in WordPress and Sanity. AirOps agents research, create, publish, review, monitor and refresh content, and pause for a reviewer to edit or approve. AirOps' own refresh guide agrees that "AI can draft updates, but it should not publish them unreviewed."
Other tools take different routes. Scrunch AXP "serves an AI-optimized mirror of your website to AI retrieval agents," and that content must be approved before it goes live. Semrush Enterprise gives teams shared briefs and scoring before publishing. Ahrefs Brand Radar tracks brand mentions across AI answers and points to citation and content gaps.
Maintouch says it can "Keep drafts technically accurate with your docs and API as ground truth," with human sign-off before work publishes to your CMS or docs. So grounding drafts in docs is not unique to EkLine. What EkLine adds is a trigger in your code repository: it reviews pull requests into your default branch for docs impact as they open, so a correction can start from the change that caused it.
Agencies bring strategy, placement on other sites, and content reviewed by engineers. Draft.dev sells engineer-reviewed posts and comparison pages, with plans from $9K a month and a three-month minimum. Directive argues that a tool like Profound "still requires a strategic individual to parse through the data." AuthorityTech, which sells earned coverage, recommends an agency for that work and warns that placement does not buy a citation.
An internal team may need neither. Studio1's guide has you run prompts by hand, from a spreadsheet, in the apps your customers use. One founder built a tracker with scheduled runs. If your product changes rarely and a handful of questions matter, a spreadsheet and a person who owns it can be enough.
Profound's Agents page says workflows "pull from your brand kit, tone guidelines, and knowledge base," and it does not mention product docs, code, Git, pull requests or release notes. AirOps grounds its agents in brand kits and knowledge bases. None of the agency pages we read lists product-documentation corrections. Studio1 tells you to fix your docs, pricing page and changelog first, and names no owner. A spreadsheet flags a wrong answer, and someone still has to rewrite the page after the next release.
EkLine drafts corrections from code, merged pull requests, tickets and release history, reviews pull requests into your default branch for docs impact, and ships them through your docs repository's own review. For a tool-by-tool look at Profound and EkLine, see Profound alternative for developer tool companies.
How EkLine runs a correction
The steps below follow EkLine's guide to winning a buyer question you are losing. Each one ends with a person deciding.
- Read the buyer-question report. It shows which answers fail, which competitors the assistants recommended instead, and which pages they cited.
- Click Fix in docs for a wrong product fact. That starts a Docs Agent session with the failed answers, the pages the assistants cited, and the report's suggested fix, as the fix guide describes. The agent reads your content first to check that the problem is real. It improves an existing page where it can. You accept or reject its changes in the editor and click Raise PR. Your team then reviews and merges the pull request as usual, in your docs repository on GitHub or GitLab.
- Click Draft in Marketing for content outside your docs, such as a comparison or a post. The Marketing Agent reads your repos, merged pull requests, changelog files, release tags, and closed tickets in Jira or Linear. Before you see a blog post, or any draft that names your product, EkLine checks every claim and marks it sourced, unsourced, contradicted or overstated. It does not publish to a CMS; you publish the post on your site yourself.
- Approve help-center fixes in place. For a Confluence or Pylon knowledge base, there is no pull request: "Your approval publishes the edits to the source instead," per the knowledge-base guide.
- Let code changes trigger docs checks. To prevent documentation drift, EkLine reviews pull requests into your default branch as they open and comments when it finds docs impact, so the docs fix can ship with the release.
- Run the same questions again. The first run is your baseline, and EkLine compares each later report with it. Judge the change by the question's passed count across runs.
The customer proof covers the correction work itself. At P0 Security, an engineering-led team with no dedicated writer at the time, "In 6 months, engineers reclaimed 150+ hours of product development time by reviewing documentation instead of writing it." At ContextQA, over the same quarter, "50% of the pages those systems ingest most are ones EkLine wrote or corrected." Its case study adds that when you ask an assistant how to set up ContextQA's MCP server, it returns the steps EkLine corrected.
None of these case studies measures AI-answer share. They show corrections getting written, merged and read by assistants.
A real correction, with its limits
EkLine tracks its own set of buyer questions. One question it was losing: "What are the best alternatives to Profound for a developer tool company?" EkLine published a post that answers it between two runs. A second post, on why ChatGPT still recommends an API endpoint you removed, went live in the same window for the question "Our docs fall behind every release, and ChatGPT keeps telling developers to use an endpoint we removed..."
| Measure | Baseline run (Oct 19, 2026) | Rerun (Oct 29, 2026) |
|---|---|---|
| Both posts live | No | Yes, since Oct 27, 2026 |
| Profound-alternative question, all four engines | 0 of 40 answers passed | 10 of 40 answers passed |
| Same question, Perplexity | 0 of 10 | 10 of 10, each citing the post |
| Same question, ChatGPT, Claude and Gemini | 0 of 10 each | 0 of 10 each |
| Removed-endpoint question, all four engines | 0 of 40 | 0 of 40 |
| Share of answers recommending EkLine, on the 10 questions that do not name it | ChatGPT 10%, Claude 0%, Perplexity 0%, Gemini 4% | ChatGPT 17%, Claude 7%, Perplexity 30%, Gemini 2% |
The first question moved from 0% to 25% of answers passing, which moves it from a losing question to a split one. Every pass came from Perplexity, and in all 10 of those answers Perplexity cited the new post. ChatGPT, Claude and Gemini did not move on that question.
The citations tie those passes to the post, but they do not prove the post caused them. In the same rerun, Perplexity also went from 0 to 10 of 10 on two other questions that no new post was written for. Answers vary between runs, so the post may not be the whole reason.
The second question did not move at all. The later report says assistants "credit its advice to Stripe and OpenAI because EkLine only appears in a short section at the end." The page answered the question, and the assistants gave Stripe and OpenAI the credit.
EkLine ran this test on its own product, with one baseline and one rerun. The assistants search the live web, and EkLine's own docs warn that answers vary from run to run even when nothing on your side changed. No one, EkLine included, can promise that a published fix changes an answer.
The work that still needs a person
EkLine drafts and checks, and your team decides. These jobs stay with a person whichever owner you pick:
- Approving every change. A docs fix ships when your team merges the pull request, a help-center edit when you approve it. EkLine's docs say of its claim checks that "your review is still the last check."
- Publishing marketing pages. The Marketing Agent does not publish to your CMS, so someone puts the post live.
- Choosing which questions matter. You confirm and reword the buyer questions so they sound like your buyers.
- Owning off-site and earned coverage. Reviews, press, community threads and third-party roundups are outside EkLine. For a wrong third-party page, AuthorityTech suggests you "request a factual correction from its publisher."
- Starting reruns. Nothing reruns the questions on a schedule. Any member of your organization can start one, after the fix is live.
If your wrong answers come mostly from other people's sites, EkLine is the wrong first purchase. Start with an agency or your own outreach.
How to choose
You need strategy and earned coverage
Hire an agency for positioning and placement on other sites. Before you sign, ask it who rewrites your product pages after each release. On the agency pages we read, that work is not listed, so plan an owner for it on your side.
You have a marketer and a tracker, but no one fixes product pages
Keep the tracker for watching answers, or use the buyer-question report for diagnosis. Add an owner for corrections. With EkLine, the Docs Agent drafts the fix as a pull request and an engineer reviews it, the same way P0 Security's engineers moved from writing docs to reviewing them.
Your product ships weekly and wrong answers come from stale docs
Put corrections next to the code. EkLine reviews pull requests into your default branch for docs impact as they open, so the docs change can ship with the release. Then run the same questions again once the change is live, and compare with the baseline.
FAQ
Buy a tool for repeatable measurement and for drafting marketing content with an approval step. Hire an agency for strategy and earned coverage on other sites. On the pages we read, neither assigns someone to re-correct product facts after each release. Name that owner separately: a person on your team, or EkLine drafting the fix while your team approves it.
Sometimes, and only after the page is live, because assistants reach your pages through the public web. In EkLine's own test, after a new post went live, Perplexity passed 10 of 10 answers on one question, each citing the post, while ChatGPT, Claude and Gemini stayed at 0 of 10. A second post moved nothing. Update the page, then ask the same questions again and judge by the passed count across runs.
Yes, for diagnosis, corrections and retesting, as long as someone owns each job. A spreadsheet of prompts covers diagnosis for a small set of questions. The job that needs a named owner is rewriting product pages after every release. EkLine drafts those fixes, so your engineers review instead of write. Earned coverage on other sites is where an agency fits.
No source we read backs a timeline with data. A fix can only change answers once it is live, and answers vary between runs. In EkLine's own test, the rerun two days after the post went live showed Perplexity citing it, while three other engines did not change. Directive says GEO agency partnerships "require a 6-to-12-month engagement."
Next step
Find out which buyer questions you lose today and which pages the assistants read to answer them. Run the free AI report, your first buyer-question report. EkLine asks 15 buyer questions on ChatGPT, Claude, Perplexity and Gemini, 10 times each, and shows where the answers go wrong.
Sources
- ContextQA case study
- Socure case study
- P0 Security case study
- Win a buyer question you are losing
- Turn a gap into a fix
- Track results over time
- Marketing Agent
- How claims stay accurate
- Manage a Confluence or Pylon knowledge base
- Prevent documentation drift
- Profound alternative for developer tool companies: what to choose
- Why ChatGPT still recommends the API endpoint you removed
- Profound Agents
- Profound CMS and Slack integrations
- AirOps platform
- AirOps content refresh guide
- How Scrunch AXP serves content to AI agents
- Semrush for Enterprise unifies content optimization
- Ahrefs Brand Radar
- Maintouch for dev tools
- Draft.dev
- Omnius ChatGPT SEO agency
- Directive: AI visibility tools vs. GEO expertise
- AuthorityTech: AI visibility tools vs. an agency in 2026
- Studio1: How to measure your devtools visibility in AI answers
- How I track whether ChatGPT, Claude and Perplexity recommend my product
