The Two-Agent Workflow: How I Use a Coding AI and a Browser AI Together to Build WordPress Sites

Most developers I talk to are using one AI tool at a time. They have Claude Code or Cursor or Copilot in their editor, or they have ChatGPT open in a browser tab, and they switch between the two depending on what they need. I did that for a while too. Then I stumbled into a pattern that changed how I work: running two AI agents simultaneously, in parallel, each doing what it's best at.

One agent lives in my local VS Code instance. It's Claude Code — the terminal-based coding agent that can read, write, and execute code on my machine. The other agent lives in my Chrome browser. It's a web-based Claude agent that can see and interact with anything I can see in a browser tab — WordPress admin panels, live websites, Google Analytics dashboards, Replit projects, whatever I have open.

Neither agent knows the other exists. I'm the bridge between them. And that limitation is actually what makes the workflow powerful.

Why Two Agents Instead of One

The local coding agent is extraordinary at what it does. It can read your entire project directory, grep through thousands of files, run shell commands, execute tests, and make precise code changes across multiple files in a single pass. When I need to refactor a WordPress theme's template hierarchy, or debug why a custom post type isn't registering properly, or write a new shortcode from scratch, Claude Code handles it faster than I could manually.

But it can't see a website. It can't look at the WordPress admin panel and tell me whether a plugin's settings are configured correctly. It can't visually verify that the CSS changes it just made actually look right on mobile. It can't navigate to Google Search Console and check whether a page is indexed. It has no browser, no eyes, no way to interact with the visual, click-driven world where most of my non-coding work happens.

The browser agent is the opposite. It can see everything I see in Chrome. It can click buttons, fill out forms, read page content, take screenshots, and navigate between tabs. When I need to configure a WordPress plugin, create a custom post type through the admin interface, check analytics data, review how a page renders on the live site, or manage content in the visual editor — the browser agent handles it. But it can't touch my local filesystem. It can't run shell commands. It can't execute code outside of a browser console.

Each agent is powerful in its own domain and completely blind in the other's. Together, with me as the coordinator, they cover almost everything.

The Local Agent: Claude Code with Hooks, Subagents, and Skills

Claude Code isn't just a chatbot that writes code. It has a configuration system that makes it behave more like a managed development environment. The .claude/ folder in a project directory holds all of this configuration, and it's worth understanding what's in there because it's central to why the two-agent pattern works the way it does.

The CLAUDE.md file is the project's memory. It contains instructions that Claude Code reads at the start of every session — coding conventions, project structure notes, deployment procedures, things I don't want to repeat every time I open a terminal. For a WordPress project, my CLAUDE.md might specify that the theme uses a specific naming convention for template parts, that custom CSS goes in a particular file rather than the theme's main stylesheet, or that the client's staging environment lives at a specific URL. Every time Claude Code starts working, it reads this file first and follows those rules without being asked.

Hooks let you run code automatically at specific points in Claude Code's workflow. A pre-commit hook might run linting before any code gets committed. A post-edit hook might trigger a build step after files are modified. These aren't just convenience features — they enforce consistency. When Claude Code edits a PHP file in a WordPress theme, a hook can automatically run PHP CodeSniffer to catch WordPress coding standards violations before I even see the change. The agent doesn't just write code; the hooks ensure the code meets the project's standards every time.

Subagents are specialized agents that Claude Code can delegate to for specific tasks. If I have a complex project with both a WordPress theme and a custom plugin, I might configure subagents where one understands the theme's template structure and another understands the plugin's architecture. The main agent coordinates, but the subagents bring focused expertise. It's like having junior developers who each know one part of the codebase extremely well.

Skills are reusable capabilities you can teach Claude Code — essentially saved procedures for common tasks. I have skills for things like setting up a new WordPress child theme, scaffolding a custom Gutenberg block, or preparing files for SFTP deployment. Instead of explaining the process every time, I invoke the skill and Claude Code follows the documented steps.

These features — CLAUDE.md, hooks, subagents, and skills — are what elevate Claude Code from a chat assistant to something closer to a configured development environment. And they're the reason the local agent is so effective at its job.

The Browser Agent: What It Actually Does

The browser agent's job is everything that happens inside Chrome. For WordPress development specifically, that covers a lot of ground.

Plugin configuration is a big one. WordPress plugins have settings pages, and those settings pages are web interfaces. When I install a caching plugin and need to configure its purge rules, or set up a security plugin's firewall settings, or configure an SEO plugin's schema markup options — those are browser tasks. The browser agent can navigate to the plugin's settings page, read the current configuration, make changes, and save them. It can also read documentation in another tab simultaneously to make sure the settings are correct.

Content management through the WordPress visual editor is another common use case. Creating pages, editing post content, managing custom fields, setting featured images, updating menus — all of this happens in the browser. The agent can work in both the Classic Editor and the Block Editor, clicking through the interface the same way I would.

Visual testing is maybe the most valuable browser task. After the local agent makes CSS or template changes, those files need to get to the server, and then someone needs to look at the site and verify the changes work. The browser agent can navigate to the affected pages, take screenshots, scroll through the layout, check responsive breakpoints, and report back on whether things look correct. It catches problems that code review alone would miss — things like text overflowing a container, images not loading, or interactive elements that technically function but feel broken.

And then there's the wider ecosystem of web tools. Google Analytics for traffic data. Google Search Console for indexing status. Google Ads for campaign management. Perplexity for research. The browser agent can pull data from all of these, synthesize it, and provide recommendations — all within the same session where it's also reviewing the site itself.

The SFTP Problem: Why I'm the Bridge

Here's where the workflow gets honest about its limitations. The local agent edits files on my machine. The WordPress site is on a remote server. Those files need to get from point A to point B, and neither agent can do it alone.

Claude Code can prepare files for deployment. It can stage them, organize them into the right directory structure, even generate SFTP commands. But it doesn't typically have direct SFTP access to a client's production server — and honestly, I wouldn't want it to. Pushing code to production is the one step where I want a human in the loop.

So the handoff looks like this: Claude Code makes the changes and tells me which files were modified. I upload those files via SFTP — usually through an FTP client, sometimes through the command line. Then I tell the browser agent to go check the live site and verify everything looks right.

It's manual. It's a bottleneck. And I've thought about automating it. But for client WordPress sites, where a bad deployment can take down a business's website, that manual step is a feature, not a bug. I review the file list, I upload deliberately, and I verify visually. The two agents make the steps before and after that handoff extremely fast, which means the overall process is still dramatically faster than doing everything manually.

Code Review as a Safety Net

One of the most useful things the browser agent does is review code that the local agent wrote. This sounds redundant — why would one AI review another AI's work? — but in practice it catches real issues.

The local agent works fast. It makes changes across multiple files, refactors functions, adds new features. It's very good at this, but it's operating purely in the world of code. It doesn't know what the site actually looks like. It doesn't know whether the function it just modified is called from a template that's only used on one specific page. It doesn't always catch edge cases that only manifest visually.

The browser agent provides a different perspective. When I paste the local agent's changes into the browser agent's context, or when the browser agent reads the changes through a web-based code editor like the one in Replit, it can review the code with the additional context of having seen the live site. It knows what the homepage looks like. It knows the navigation structure. It's seen the mobile layout. That visual context makes its code review qualitatively different from what you'd get by just running another pass through a linter.

I don't do this for every change. Small CSS tweaks don't need a second opinion. But for structural changes — modifying template files, adding new custom post types, changing how data flows between the theme and a plugin — having the browser agent review the local agent's work has caught issues that would have been bugs in production.

Why the Browser Agent Can't Use .claude/ Features

This is a question I get asked, and it's worth explaining because the answer reveals something important about how these tools actually work.

Claude Code's features — CLAUDE.md, hooks, subagents, skills, MCP plugins — all exist because Claude Code runs as a local process on your machine. It has filesystem access, it can execute shell commands, it can spawn child processes, it can maintain persistent state across sessions. The .claude/ folder is a configuration directory that this local process reads and acts on.

The browser agent is fundamentally different. It runs in a browser. It can read web pages, click buttons, fill forms, and take screenshots. If I navigate the browser agent to a Replit workspace or a web-based VS Code instance and open the .claude/ folder, the agent can read the text content of those files. It can see what's in CLAUDE.md. It can read the hooks configuration. But reading a configuration file and executing the machinery that configuration describes are two completely different things.

The browser agent can't run a pre-commit hook because it can't execute shell commands on the server. It can't spawn a subagent because it doesn't have a process model. It can't invoke a skill because skills are procedures that require filesystem and terminal access. It can read the instructions in CLAUDE.md and try to follow them as guidelines — essentially treating them as a prompt — but that's a far cry from the integrated, enforced behavior that the local Claude Code agent provides.

This asymmetry is actually the core insight of the two-agent workflow. You don't need one tool that does everything. You need two tools that each do their part well, and a human who knows when to use which one. The local agent gets the full power of configured, hook-enforced, skill-enhanced coding. The browser agent gets the full power of visual interaction with web interfaces. Together they cover the gap.

A Real Session: Custom Post Type for a Client Portfolio

Let me walk through an actual session to make this concrete. A client wants a portfolio section added to their WordPress site — custom post type, archive page, single template, filterable by category.

I start in my local VS Code terminal with Claude Code. I tell it to scaffold a custom post type called 'portfolio' with category taxonomy support, register it in the theme's functions.php, and create template files for the archive and single views. Claude Code reads my CLAUDE.md, which specifies this client's naming conventions and directory structure. It creates the files, follows the conventions, and runs the PHP linting hook automatically. Total time: about two minutes.

Now I need those files on the server. I review the file list Claude Code gives me — functions.php was modified, and three new template files were created. I upload them via SFTP. Takes about thirty seconds.

I switch to the browser agent. I ask it to navigate to the client's WordPress admin, verify the new post type appears in the sidebar, create a test portfolio entry with a title, featured image, and category, then navigate to the archive page on the front end and check the layout. The browser agent does all of this, takes screenshots at each step, and reports that the archive page is rendering but the grid layout is breaking on mobile — the cards are overlapping instead of stacking.

I go back to Claude Code with that information. I tell it the archive template's grid is breaking on mobile and describe what the browser agent saw. Claude Code checks the CSS, finds the media query issue, and fixes it. I upload the updated stylesheet via SFTP.

Back to the browser agent. I ask it to hard-refresh the archive page and check mobile again. It confirms the grid now stacks correctly. I ask it to also check the single portfolio template while it's there. Everything looks good.

The whole process — scaffolding, deployment, visual testing, bug fix, re-deployment, final verification — took maybe fifteen minutes. Without the two-agent setup, I'd estimate that at forty-five minutes to an hour, mostly because the visual testing and WordPress admin configuration would have been entirely manual.

When This Workflow Shines

This pattern is most valuable when a project involves both code changes and web interface interaction in the same session. WordPress development is a perfect fit because the platform straddles both worlds — there's always code (themes, plugins, functions) and there's always a web interface (admin panel, visual editor, settings pages).

It's also valuable when you need rapid iteration cycles. Make a change, deploy, check visually, adjust, redeploy, check again. Each cycle is fast because the agents handle the slow parts — writing code, navigating admin panels, taking screenshots — while I handle the critical parts: reviewing changes, deploying to production, making judgment calls.

And it's surprisingly useful for maintenance work. When a client reports that something looks wrong, I can have the browser agent check the live site and describe the issue in detail, then give that description to the local agent for diagnosis and fix. The browser agent becomes my eyes, the local agent becomes my hands, and I'm the brain deciding what to do.

Getting Started with This Workflow

If you want to try the two-agent approach, you don't need anything exotic. You need Claude Code installed locally (it runs in your terminal through VS Code or any terminal emulator), and you need access to a browser-based AI agent — Claude's web interface with the computer use feature, or a similar tool that can interact with browser tabs.

Set up a .claude/ folder in your project with at least a CLAUDE.md file that describes your project's conventions. Even a basic one that lists the directory structure and coding standards will make the local agent significantly more effective. Add hooks gradually as you notice repetitive quality checks you want automated.

For the browser agent, organize your Chrome tabs into groups by client or project. Keep the WordPress admin, the live site, and any relevant tools (analytics, search console) in the same group. The faster you can context-switch between these tabs, the more natural the workflow feels.

The learning curve isn't in the tools themselves — it's in learning what to delegate to which agent. That intuition builds fast. After a few sessions, you'll instinctively know that 'change the CSS' is a local agent job and 'check if the contact form plugin is configured correctly' is a browser agent job. The gray area in the middle is where you, the developer, add the most value.

If you're looking for a developer who uses modern AI workflows to build and maintain your business's website, I'd love to talk about your project.

Learn more about my WordPress development services in Baltimore or get started with a free consultation.

Building a website for a small business? I also build professional WordPress and Webflow sites for small businesses, starting at $1,000. If you or someone you know needs a site, check out my services or get in touch.