I asked AI to check what our website says about us
Before relaunching base22.com, I gave AI agents read-only access to our records back to 2009 and one job: check what our website says about us. Here's what survived, and how we rebuilt the site so agents could help run it.

One line on our old website said a client's portal had cut help-desk calls by more than half. It was specific and it was flattering. It was also untraceable.
Before we relaunched base22.com, I gave AI agents read-only access to our records and one job: check everything our website says about us. They traced that line through ten years of our own documents. In 2015 it appeared in a conference submission as a benefit the project anticipated. By 2017 our standard project write-up said the client had realized it, still without a number. By the time it reached our website, it read "50%+".
Nobody lied. We copied it until it sounded true. It's gone now, along with every other claim we couldn't prove.
That fact-check is the part of our website rebuild I'm proudest of, and it was only possible because of how we rebuilt the site.
A website software couldn't read
Since 2019 we had rebuilt our site twice on WordPress, each time with a new theme and a new page builder. Both times the real problem survived: the content was the layout. 133 of our 136 pages were page-builder compositions, and more than 700 widgets inside them only worked while one particular theme stayed installed.
A person can live with that. An AI agent can't. It can't safely change a sentence that's tangled up with styling and plugin markup, and it can't check a claim it can't reliably find.
Nine weeks, built with agents
So we started over on Payload CMS and Next.js, and we built it the way we now build software: AI coding agents wrote most of the code, and our engineers reviewed every change before it shipped. Nine weeks after the first commit, on September 30, base22.com switched over.
Every piece of content is now a structured record instead of a layout. A case study has a challenge, an approach and an impact; an insight has a body, authors and topics. English and Spanish are two languages of one record, not two copies that drift apart. That structure is what lets an agent work on the site safely, and it made the site faster for everyone else too. Measured on the same content the day before launch (median of 15 pages):
Old site | New site | |
|---|---|---|
Mobile performance (Lighthouse) | 72 | 93 |
Largest Contentful Paint, mobile | 6.5 s | 3.1 s |
Page weight | 1,434 KB | 313 KB |
JavaScript | 696 KB | 136 KB |
Accessibility (Lighthouse) | 85 | 100 on every page measured |
Third-party code before consent | 312 KB | none |
Accessibility isn't a score we hit once. Every change now runs an automated WCAG 2.2 AA check, and a change that fails can't ship. We also carried over every URL the old site had, with 3,032 redirects that are tested on every change, so the links people built to us over the years still land on the right page.
Checking ourselves
The rebuild gave the agents a site they could read. The fact-check gave them a reason to read it.
They got read-only access to the records that could prove or disprove what we said: our operations platform, which holds our logged work back to 2009; our proposal archive; project wikis; and archived copies of our earlier websites. They could read everything and change nothing. Then they cross-checked 134 past engagements across 22 clients against the work we had actually logged:
What the record showed | Engagements |
|---|---|
The date on file was confirmed | 28 |
The date on file overlapped the logged work | 35 |
A missing date was filled in | 52 |
The date on file was wrong and was corrected | 13 |
No evidence either way | 6 |
Then they went through every headline figure on the old site. The help-desk number wasn't the only one that didn't survive.
What replaced those figures is less flashy and more useful: numbers with a date and a source. A public program's results are credited to that program. A client's award is presented as the client's, earned with our help. If you ask us where a number came from, we can show you the record. And nothing the agents found went live until a person had signed off on it.
Launch day
The agents didn't stop at launch. A few hours after we went live, one of them was reading the server logs and found errors nobody on our team had noticed. It traced them to images missing from 12 articles, and found the cause: a step in the content migration had deleted duplicate image records that those articles still pointed to. It checked every broken image against the original post, repaired the articles and shipped a code fix the same afternoon, with a report of what broke, why, and what it changed.
That's the setup I trust with our public face. Agents work with an editor's permissions, never an administrator's. Every change they make is versioned and can be rolled back, and it passes the same checks as anyone else's. Anything that says something new about us, whether a claim, a figure or an image description, is approved by a person before it goes live.
If you're planning your own migration
You don't need to switch platforms to start. Whether you run HCL DX, Liferay, Contentful or Payload, three things carry over:
- Separate content from layout. Agents can safely work on fields, not on page-builder markup.
- Give agents roles, not keys. An editor's permissions, never an administrator's, and every change versioned.
- Point AI at your records before your readers. Read-only access to real data turns AI from a copywriter into a fact-checker.
Next, we're taking this further and bringing authoring to where our people already work. I'll write about that soon.
If you're weighing a platform migration, or wondering what your own website would say under a fact-check, Schedule a call.
Topics
- AI & data
- Inside Base22
About the author
Rafael Trujillo
Executive Officer