My team of AI agents burned through my whole usage quota in 2 days. One webmaster agent doing the same job leaves me enough for 2 to 3 more projects.
I learned this running the website and shop of Sogas Mascaró, a family cava winery. I had an SEO agent, a store agent and a couple more, and they spent their time passing information to each other in chat. Things fell through the cracks, like the DNS changes for a site migration and the blog calendar. So I replaced the team with one agent and one job title: webmaster. I picked that title on purpose: I started as a web designer, then worked as a webmaster before becoming a software engineer, so I know what the job covers and which responsibilities to hand over.
This guide shows you how to set one up: the role, the tools, the memory, the routines and the approvals. It also covers the few cases where a second agent is actually worth it. If you want the architecture side (subagents, skills, context windows), I covered it in single agent vs multi-agent.
The problem: agents that talk too much
A multi-agent setup splits work the way an org chart does. An SEO agent, a store agent, a content agent, maybe a coordinator on top. Each one has its own instructions and its own view of the project.
The trouble starts at the boundaries. In my multi-agent setup, two things kept getting lost: the DNS changes needed for a website migration, and the blog post calendar. Neither belonged neatly to one agent, so they lived in the chat between agents, and that's where they went missing.
Every handoff is a summary, and every summary loses something. The agent receiving it doesn't know what was left out, so it guesses. Two agents guessing differently about the same work is how you end up with inconsistent results and a long chat log that nobody, human or agent, wants to read.
A single agent doesn't have that problem. It knows about the migration and the calendar because it's the one handling both.
Multi-agent handoffs lose the DNS migration and the blog calendar; one webmaster owns both.
My case: Sogas Mascaró
Sogas Mascaró is a family cava and wine winery, and it's where I noticed this. I tried a multi-agent setup with an SEO agent, a store-management agent and something else. In the end, the most efficient option was simply to create one webmaster agent that takes care of everything, the way any employee with enough responsibility would at a mid-sized company.
It runs on Grok Bot. The one number I have is about usage. With the multi-agent setup, my whole Grok Bot usage quota was gone in 2 days. With a single agent, there's enough quota left over for 2 to 3 more projects.
With several agents the Grok Bot quota was gone in 2 days; with one, enough left for 2 to 3 more projects.
I think the same idea applies, in some way, to coding agents like Claude Code or Codex when you run them semi-autonomously: one agent that owns the work may do better than several handing it around. That's my view, not a proven result.
What the research says
My experience isn't unusual. The teams building the most serious agents have written about the same trade-off.
Cognition, "Don't Build Multi-Agents" (June 2025). Walden Yan argues that splitting a task across agents is "very fragile", and sets out two principles: "Share context, and share full agent traces, not just individual messages" and "Actions carry implicit decisions, and conflicting decisions carry bad results." His conclusion at the time: running multiple agents in collaboration "only results in fragile systems. The decision-making ends up being too dispersed and context isn't able to be shared thoroughly enough between the agents." The simplest way to follow both principles, he writes, is "a single-threaded linear agent". (source)
Cognition, "Multi-Agents: What's Actually Working" (April 2026). Ten months later, Cognition does run multi-agent systems in production, but a narrow kind. The through-line: "multi-agent systems work best today when writes stay single-threaded and the additional agents contribute intelligence rather than actions." One example is a review agent that checks code written by their coding agent. On PRs written by Devin, Devin Review "catches an average of 2 bugs per PR, of which roughly 58% are severe". They call unstructured swarms of agents negotiating with each other "mostly a distraction". (source)
Anthropic, "How we built our multi-agent research system" (June 2025). This is the strongest case for multiple agents, and it's about research. A lead agent (Claude Opus 4) with Claude Sonnet 4 subagents "outperformed single-agent Claude Opus 4 by 90.2% on our internal research eval". The cost: agents "typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats." Anthropic also says domains "that require all agents to share the same context or involve many dependencies between agents are not a good fit for multi-agent systems today". One of the failure modes they saw early on was agents "distracting each other with excessive updates". (source)
Put together: several agents help when the work splits into independent, read-only pieces. Running a website is the opposite. Everything touches everything else.
How to set up one AI webmaster agent
This is the order I'd follow. I'll use my webmaster agent for Sogas Mascaró as the example at each step.
Role, tools and Notion memory. The Sogas Mascaró webmaster setup, steps 1 to 4.
Weekday routines and approvals. The Sogas Mascaró webmaster setup, steps 5 and 6.
1. Write the role like a job description
Don't start with prompts. Start with the job post you'd write if you were hiring a person.
- Title: webmaster for your site.
- Mission: one sentence on what success looks like. Mine is simple: make the website and the shop sell more.
- Who they report to: you. Say how you want updates. Mine only alerts me when something matters.
A human-sounding role works better than a list of rules because the agent can reason from it. "What would a good webmaster do here?" is a question it can answer. "Which of my 40 rules applies?" often isn't.
2. List the responsibilities
Write down what the role owns, in plain language. This is roughly what my webmaster owns:
- Website: a Next.js site on Vercel. Changes go on a branch through a cloud coding agent and get grouped into one PR a week, because every build costs money. It merges only with green CI and after reviewing the preview, then checks production.
- Shop: it improves 10 WooCommerce product pages a day, with verified copy, the official image and FAQs.
- SEO: keywords, categories, meta tags, schema, llms.txt, performance and indexing.
- Content: an editorial calendar split by funnel stage (TOFU, MOFU, BOFU), built from search research.
- SEM: Google Ads and Merchant Center.
- Monitoring: key pages, sitemap, cart and checkout, deploys, orders and conversion tracking, every day.
If you can't write a responsibility in one line, it's probably two responsibilities, or it's not clear enough yet.
3. Give it the tools for that job, and no more
Connect the agent to what a person in that role would actually use. Each tool should match a responsibility from step 2. Every extra tool is something the agent can pick by mistake. Mine has:
- GitHub plus a cloud coding agent, and Vercel.
- The WordPress/WooCommerce REST API.
- Google Search Console (API and browser), Bing Webmaster Tools, GA4, Google Ads and Merchant Center.
- Notion for the SEO plan, the blog calendar, a product-page database and a change log with a baseline for each experiment.
- Its own browser for anything without an API, like requesting indexing.
- Web search, to check product data against official sources.
4. Give it a memory
A person keeps notes. Your agent should too. Pick one place where it writes down decisions, conventions and the state of ongoing work. For my webmaster that's Notion: the SEO plan, the calendar, and a change log where every experiment has a baseline, so we can tell later whether it worked.
The rule I'd follow: if you'd be annoyed to explain it twice, it goes in memory. The agent reads it before it acts and updates it after.
5. Set routines
Most of a webmaster's work is recurring. Turn it into scheduled routines instead of waiting for you to ask. My webmaster's week looks like this:
- Every day: product pages and monitoring.
- Monday: Search Console and Bing review, including keywords close to page 1.
- Tuesday and Friday: blog posts.
- Wednesday: Google Ads and Merchant Center.
- Thursday: landing pages and refreshing old posts.
- Friday: backlinks. It does the free listings itself and prepares outreach drafts for me.
- The 15th of each month: a technical audit.
A routine with nothing to report should stay quiet. An agent that messages you every day to say "all good" trains you to stop reading.
6. Set limits and approvals
This is the part people skip, and it's the one that matters most. Write down what the agent can do alone, what needs your OK and what it never does. For my webmaster:
- Alone: publishing a blog post, if it passes the brand rules and the link check. If it doesn't, it stays as a draft.
- Needs my OK: prices, stock or product names; any Ads change that affects spend; anything on the server or DNS.
- Never: sending emails or messages as me, or paying for anything.
A good employee knows where their authority ends. Your agent should have it written down.
When multiple agents do make sense
One agent per project is my default, not a law. There are two cases where I'd add more.
Parallel, read-only research. If the job is "find every competitor page that ranks for these 50 terms and summarise them", the pieces are independent and nobody writes anything. That's the shape Anthropic's research system is built for. You pay for it in tokens, so it has to be worth it.
Reviewers who don't write. A second agent that checks the first one's work before it goes live: reads the draft, looks for wrong facts, broken links or claims you can't back up. It reports back, and the webmaster decides what to change. That's Cognition's pattern: one writer, other agents contributing intelligence.
What I'd avoid is two agents that both make changes to the same site. That's where the conflicting decisions come from.
If you need several bots, use Notion as shared memory
Sometimes you do end up with more than one agent: different projects, different people, or a researcher feeding a writer. My rule for that case: don't let them coordinate through chat. Give them a shared memory instead. That's what I do: I already use Notion as the shared memory between my bots.
One writer per Notion section; the other agents only read from a single source of truth.
Anthropic describes a similar idea: subagents store their work in external systems and pass "lightweight references" back, to avoid a "game of telephone".
What I'd recommend:
- One source of truth. A Notion page or database per project with the things every agent needs: goals, current priorities, decisions, conventions, what's off-limits.
- One owner per section. Each page or database has exactly one agent that writes to it. Everyone else reads. If the researcher owns "Keyword research", the webmaster reads it but never edits it.
- Write decisions, not conversations. "Product page X targets keyword Y, decided 5 Nov" is useful. A transcript of how two agents got there isn't.
- Link, don't copy. An agent that needs context gets a link to the page, not a pasted summary that goes stale.
Checklist
- [ ] One agent per project, with a job title a person would recognise.
- [ ] A mission and a reporting line written down.
- [ ] Responsibilities listed, one line each.
- [ ] Only the tools those responsibilities need.
- [ ] One memory place the agent reads before acting and updates after.
- [ ] Recurring work set up as routines that stay quiet when there's nothing to say.
- [ ] A written list of what it can do alone, what needs approval, and what it must never do.
- [ ] Extra agents only for parallel read-only research or for reviewing, never as a second writer.
- [ ] If there are several bots, a shared Notion source of truth with one writer per section.
FAQ
Is one AI agent enough to run a website?
For a small business site or shop, in my experience, yes. One agent with a clear role, the right tools, memory and approval rules can cover SEO, content, orders and site health. It's the setup that worked best for me at Sogas Mascaró, and it left Grok Bot quota for 2 to 3 more projects where the multi-agent version used it all up in 2 days.
What is an AI webmaster agent?
An AI agent with the role a human webmaster would have: it owns the site end to end, from SEO and content to the store and technical health, and reports to you. The difference from a generic chatbot is ownership. It has responsibilities, tools, memory and limits, not just a prompt.
When should I use more than one agent?
When the work splits into independent pieces that don't change anything, like parallel research, or when you want a reviewer that checks the main agent's output without editing it. Both Cognition and Anthropic describe these as the cases that work.
Can Notion work as memory for AI agents?
Yes, it's what I use between my bots. A Notion page or database can hold the decisions and context every agent needs. The key is ownership: one agent writes each section, the others only read.
Do I need to code to set this up?
No. You don't need to code to set up an agent like this. That said, knowing programming and SEO, and having real-world experience, always helps.
About the author
I'm Joan Comadran, an AI engineer and full-stack developer in Barcelona. I build web and AI apps, agents and tools fast, and I like problems where the right answer is less machinery, not more. If you want a hand setting up an agent like this for your project, here's how I work.
Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.
Top comments (0)