We built a restaurant directory site called KPopEats. The premise was simple: a curated guide to Korean restaurants across cities, with listings, categories, dish pages, and search. WordPress felt like the natural choice. It powers a third of the web, has a mature content model, and comes with WP-CLI, REST APIs, and a plugin ecosystem that looked like it would save time.
We also wanted to keep humans in the loop. The idea was that agents would handle the heavy lifting through WordPress APIs while a human editor would review, approve, and curate. It sounded like the right balance of automation and oversight. It was not.
What We Built
KPopEats ran on a $5 AWS Lightsail instance with Apache, PHP 8.2, MariaDB, and WordPress 6.9. We deployed a custom theme with custom taxonomies for restaurant categories, cities, dish types, cooking methods, and proteins. We used Outscraper to pull restaurant data, then agents cleaned, categorized, and imported it through a mix of WP-CLI commands, PHP scripts, and WordPress REST API calls.
The multi-agent setup was thorough. A heartbeat process checked task status every five minutes. Agents locked tasks, posted checkpoints, and followed a multi-agent testing protocol that required sign-offs before anything shipped. There were operational playbooks, deployment checklists, and a failure review process. On paper, it was disciplined.
Where It Started to Crack
The first problem was deployment. GitHub Actions CI/CD was broken from the start because the SSH key secret was never configured. We fell back to manual SCP transfers, which meant every theme update, every plugin fix, every small CSS change required an SSH session and a file copy. That is not a workflow agents can own end to end.
The second problem was content operations. Driving WordPress through WP-CLI and REST APIs from agents meant translating every content decision into a command or API call. Create a post. Set taxonomies. Upload media. Attach media to post. Update post meta. Each step was technically possible but practically fragile. A PHP warning in wp-config.php, a duplicate constant definition, a missing JavaScript file reference all of these surfaced as agent-facing errors that required human debugging of WordPress internals.
The third problem was the human-in-the-loop model itself. We wanted human editors to review agent output. But the output was WP-CLI logs and API responses, not a draft in a CMS interface. The human review step became a bottleneck because the review surface was hostile to human judgment. Editors do not want to verify taxonomy assignments by reading JSON payloads.
The Realization
Somewhere between fixing another PHP warning and re-running a failed import script, the question became unavoidable: why are we doing it this way? We had agents capable of writing code, managing infrastructure, and coordinating complex workflows. Why were we routing them through WordPress as a middleman?
The answer we kept arriving at was that WordPress makes sense when the content management workflow is human-first. A human opens the admin, writes a post, assigns categories, previews, publishes. That is the workflow WordPress optimizes for. When agents become the primary operators, that workflow becomes overhead. The admin UI is irrelevant. The plugin ecosystem adds complexity agents have to route around. The PHP theme layer is a translation step between what the agent wants and what the system does.
What We Should Have Done
If the site is agent-operated, the site should be agent-native. That means a codebase the agents own completely: a Next.js frontend with markdown content, deployed through GitHub Actions, with no CMS layer in between. The agents write content as files, commit to Git, and the CI/CD pipeline ships it. No WP-CLI. No REST API translation. No PHP warnings to debug.
This is exactly how we built vibrilliant.com. Content lives as TypeScript and markdown in a Git repo. Agents commit changes. GitHub Actions deploys. The human review step happens in pull requests, which is a surface humans actually understand. The workflow is simpler, faster, and more reliable.
Lessons
Choose your architecture based on who operates it. WordPress is excellent for human-first content workflows. It is painful when agents are the primary operators. The extra layers do not add capability for agents. They add translation overhead and failure surface.
Human-in-the-loop only works if the loop is human-readable. Reviewing JSON API responses is not human-in-the-loop. It is human-as-debugger. Pull request review, on the other hand, is a review surface designed for human judgment. Match the review surface to the reviewer.
Complexity must earn its place. A $5 Lightsail instance running WordPress, PHP, MariaDB, Apache, custom themes, and a plugin stack is a lot of moving parts for a directory site. When agents have to debug WordPress internals instead of building product features, the complexity is not earning its place.
Abandoning a project is not failure. KPopEats taught us more about agent architecture than any successful deployment would have. We learned that agents should own their deployment pipeline, that content workflows should match the operator, and that the simplest stack that can do the job is usually the right one. Those lessons directly shaped how we build everything now.
Where KPopEats Is Now
The site is currently offline. We paused active development when it became clear the WordPress-through-agents model was not the right fit. The directory data, custom taxonomies, and theme work are archived and intact. There is a real chance we resurrect it as an agent-operated business — not a site agents help maintain, but a product agents run end to end, from content generation to customer outreach to revenue management. If that happens, it will be built agent-native from day one. No CMS middleman. No translation layers. Just agents, a codebase, and a pipeline.