How We Run Our Website With AI Agents and One MCP Server

Every AGENT.md you have ever written is a bug report against the server it describes.

At 4Geeks, agents run our website. They work scheduled sessions around the clock on a production marketing site with 606 live URLs, proposing work, fixing bugs, and clearing validation issues. There is no AGENT.md, no SKILL.md, no LangGraph, no orchestrator. One MCP server, and ordinary chat agents from two different vendors, claude.ai and Grok, with nothing written per client.

Here is what that produced in five days.

The numbers

Between September 2 and September 6, agents resolved 229 validation issues across the site. Not 229 claimed. Every one carries a verified_gone resolution, meaning the server re-validated the entry after the write and confirmed the problem was actually absent.

Every one of those 229 is verified_gone, not "agent said done." The server re-validated after each write and confirmed the issue was actually absent. The 4.4% reopen rate is in the table on purpose.

The idea

An MCP server can carry its own graph. Tools are nodes. The next_actions array on every response is the edges. Gates are guarded transitions that stop a write until someone decides. When the graph travels inside the responses, nobody has to teach the agent the system, and nobody maintains a file describing it.

We proved it the blunt way. A cold agent with nothing in its context about our CMS, production write access, real tasks from our own queue. Cold start to a correct production write: four calls. Invented tool names: zero. Wrong-target writes: zero.

Our own instruction file made the point for us. The local conventions file had one rule in it. The server handed the agent four, current and version-stamped, on the first call.

The server said no four times

This is the part almost no MCP server does.

Which site? The first call omitted the tenant. The server refused, listed all three configured domains, and named the tool to call next.

Report too short. A write arrived with a four-character audit note. Rejected before touching a file. Every mutation here carries an 80-character report so staff can read what an agent did and why.

Confirm to delete. A delete without confirm: true. Nothing removed.

Are you sure? The agent asked for a site-wide diagnostics run and got this back:

Last full site-wide run was 7 minutes ago and took 14m 16s (606 URLs). Re-call with confirm: true to proceed.

The agent read that, decided it was not sure, and used the cached results instead. A gate that prices the operation is a gate that saves you a quarter hour.

None of these are error messages. They are decisions handed back to the principal.

It refused to let the agent finish

First task: a required FAQ field left empty on a live post. The agent read the schema off the content type, wrote six question and answer pairs, and re-ran diagnostics on that slug to verify.

The issue stayed open.

The same issue id came back naming a different field. The FAQ was fixed. The post body was empty. The article had been live and indexed with no content in it, which is why fetching the URL returned nothing but the site shell.

An agent reporting to a human says "done." The server re-validated, found the next gap, and kept the issue open. Two days earlier, a scheduled agent hit the same cascade on a Spanish post. Different page, different locale, same refusal to accept the work as finished.

It found the source instead of inventing one

One task was set up to bait a bad write. A post titled "GeekForce: The Career Launch Engine" had been live since October 2025 with a title, tags, a CTA, five FAQ answers, and no body. Ten months as an empty shell. The obvious failure is an agent generating a page of marketing copy about a service it knows nothing about.

It did not refuse and it did not invent. It found the GeekForce pillar page elsewhere on the site and wrote the body from what that page already published, including audited federal placement results.

Then it left one thing out. The graduate hiring rate on this site is a region-aware variable. Rather than hardcode a number that would be wrong in two of three regions, the agent omitted it and flagged the ambiguity. Revalidation afterward: zero errors, zero warnings.

Across the fourteen runs we watched call by call, plus the eight scheduled ones before them, the record was zero bad writes, two correct refusals, one honest release when blocked, and two tool gaps discovered by agents doing ordinary work.

An agent that succeeds every time is either doing easy work or lying about it.

Why this beats an AGENT.md

Not because the agent performs better. We did not run that comparison.

It wins because the maintenance burden moves. An AGENT.md lives with whoever connects to your server, drifts the moment you ship a change, and fails on your data while the stale instructions sit in someone else's repo. Put the same knowledge in the server and it versions with the code. Two vendors' agents, one server, nothing to keep in sync.

And responsibility moves with it. With an instruction file, correctness is advisory: the agent is told to be careful and trusted to be. With gates, correctness is enforced at the write. Our agent never decided whether a delete was safe or which site to target. It was never asked.

Try this on your own server

Call your most dangerous mutating tool with no arguments.

If you get a question back, with the missing pieces named and the next tool to call, your server carries its graph.

If you get an error, you have an AGENT.md problem. You just haven't written the file yet.

We wrote up the eight patterns behind this, with the exact response payloads from these runs, as a short implementation guide you can hand straight to your own coding agent. Grab it below.

Want to build one yourself instead of just reading about it? Building an MCP Server is a free, hands-on exercise: you stand up a real server with FastMCP, define a tool an agent can call, and add the same kind of guardrails discussed above, so an unsafe call fails safely instead of executing.

What this does not prove

We never ran the control, so nothing here measures the gap against a well-maintained AGENT.md. One server, one site, two vendors. Seven of the ten reopens were the same validator, which points at a check that re-fires on correct content rather than at agents making mistakes. And probing our own server against our own rules found five places it breaks them. We are fixing those.

The takeaway

The interesting result was not the agent completing tasks. Agents complete tasks all day.

It was the agent being stopped four times, told its finished work was not finished, and pointed at a problem nobody asked it to find.

That did not come from a prompt. It came from the server.

If you are evaluating this kind of tooling more broadly, our guide to AI tools for developers covers the wider landscape this server sits inside. For the fuller explainer on what an MCP server actually is and why it is not just an API endpoint, see What Is an MCP Server?