# Hello, DEV Community! 👋 The Agent That Cannot Approve Its Own Fix: Building SearchPilot with Switch

_By the SearchPilot team: Ali Shan, Aisha P and Tumusiime Stephen. Built for the Flip the Switch hackathon.
_
Code and setup: https://github.com/qxcore404-cloud/seo-audit-to-fix

An SEO audit ends with a list. A missing meta description. An empty title. A page marked noindex by accident. Then the real work starts: someone has to read each finding, decide what the fix should be, edit the page, and check that the edit worked.

We built SearchPilot to connect those steps, and we set ourselves one rule before writing any code: the agent can prepare a change, but only a person can approve it.

What happens when you ask for a fix

A teammate asks the agent in Switch to audit a page. Here is the path from there:

Audit. SearchPilot checks six things: page title, meta description, H1, image alt text, canonical URL and noindex. It returns the evidence for each finding and a SearchPilot score.
Preview. For page titles and meta descriptions, the agent prepares the exact change and shows the current text next to the proposed text. Nothing has been written.
Approval. A person approves or declines with an approval token. The agent has no way to do this for itself.
Apply. An approved change goes to a controlled demo page, never to the website that was scanned.
Verify. SearchPilot re-audits the demo page and saves the result in a fix history, including rejected fixes.

The score is our own measure. It is not a Google score and it does not predict rankings. A passing check shows that a tag is present, not that the words in it are any good, and we would rather say so than hide it.

How Switch and Codex fit together

We used OpenAI Codex as our coding assistant, and it also became the agent. We built a small MCP server that exposes four SearchPilot tools:

Tool **What it does
**audit_website Reads a public page and returns findings and a score
create_fix_preview Prepares a title or meta description change, without writing it
verify_demo_fix Re-audits the demo page after a change
get_fix_history Returns applied and rejected fixes

We registered that server with Codex, then added a Codex-powered agent in Switch Console and invited it into a Switch room. From there, the agent can inspect a website and prepare a fix using real project tools.

Look at what is not in that table. There is no approval tool. Approval is a separate backend endpoint that requires a human token. That was the point of the whole design.

*The lesson we did not expect: capabilities beat instructions
*
It is easy to tell an agent "never change anything without approval." That is a request, and requests depend on the agent following them. Removing the capability is different. The agent cannot approve a fix because no tool exists that lets it try.

The same thinking shaped the rest of the system. We kept the write target to one checked-in demo file, so every preview is exact and every verification means something. We blocked private and local addresses on public page fetches. Building an agent turned out to be less about giving it tools and more about deciding what it may do, what needs a human, and how every action can be checked afterwards.

*What got in the way
*
Wiring this up meant understanding how four pieces work together: the local backend, the MCP server, the Codex provider and the Switch-managed agent. We spent real time troubleshooting backend connectivity and approval-token handling during testing. Each of those problems was small once found, and the fix history and the explicit token made it easy to see what had and had not happened.

We also learned our own system's edges. Pending previews live in memory, so they disappear when the backend restarts. After a restart, you have to create a new preview. We documented that in our demo workflow instead of hiding it.

One more point on Switch itself. Its docs do not say how a custom agent can publish third-party functions through the registration tools field, and they do not define the values of message_exchange or connection_model. Rather than guess at an undocumented API, we used the documented route: a Codex agent with an MCP server. A worked example of the custom path would help the next team.

What we liked
Codex sped up the build. It helped us build, understand and improve different parts of the project.
MCP was a practical bridge. It gave us a clean way to expose backend functions to an agent without giving it more than we intended.
Switch Console made the agent usable. Having a Codex-powered agent in a room let us explore how an agent works with real project tools, not just talk about it.
Human control stayed intact. The agent inspects and prepares. A person decides.
Where it stands, honestly
Fixes cover page titles and meta descriptions only, on a demo site.
Approval is a shared local token, not individual identity. This is a hackathon demo, not a multi-user service.
Some sites time out during an audit. One site we tried returned a 504, and we recorded it as a timeout, not as a successful audit.
The audit reads raw HTML only. Page scripts are not run.
Our manual and API testing was done on Kali Linux. Windows and mobile browsers are untested, and we have not yet tried the idea with real freelancers or small teams.
What we would build next

Extend fixes to the other four checks. Tie approval to an identified reviewer and one exact preview, so a token is no longer the only proof. Then put SearchPilot in front of freelancers and small teams who maintain websites and see whether an approve-before-apply flow is something they actually want.

Switch gave us a place to explore an agent workflow where AI tools, MCP integrations and human oversight work together on a real task. The most useful thing we took from it is simple: let the agent do the legwork, and keep the decision with a person.