How AI agents help us run NetProjects

We have built and run our own websites since 2013, including GreekMythology.com and Airportia.com, our flight-tracking site. For most of that time "a small team runs large sites" meant long days and a lot of manual checking. This year it has come to mean something different: AI agents do much of the routine work under a few plain rules (one job each, drafts by default, changes we can undo), and the people on the team decide what happens next.

This is a plain account of how it works and what we've learned. There are no growth charts: we have a rule against quoting numbers we haven't measured, and it applies here too.

One agent, one job

Each agent has a name, a written description and a single area it owns; we run about 30 of them on Grok Bot. There is a Chief of Staff that coordinates the others and keeps the standing rules. There is a personal assistant for my diary and drafts. There are agents for search (SEO), advertising, revenue reporting and security on our content and data sites, an agent for daily statistics, one for invoicing, one for the office, and a Token Officer whose only job is to notice when other agents are wasting money.

Keeping the jobs narrow was the most useful decision we made. A general assistant that "helps with everything" drifts. An agent that owns search on one site builds the right context and knows when to stay quiet. When a job grows too big, we split it.

A runner, a coordinator, and a weekly huddle

Recurring work (a Monday check across the fleet, a Friday health check of our machines, reminders) lives on one lightweight agent we call Fleet Ops. Its chat is short and holds nothing but routines. The Chief of Staff coordinates but owns no routines of its own, so its context stays small and focused.

Every Monday the fleet check reads what each agent did that week and reports only what needs a person: decisions, blockers, broken routines. It never messages the agents, because every message wakes one and costs a paid turn. Then the Chief of Staff runs a 15-minute huddle with me: what changed in the business, this week's priorities, what annoyed me about the bots, what it has wrong, and what to start or stop. The answers go straight back into the standing rules.

Drafts first, people decide

Agents draft; people send. No agent sends an email, posts on social media or publishes a page unless a standing rule for that specific job allows it. Everything else arrives as a draft for a person to edit and approve. It is slower than letting the bots loose, and it is why we trust them with real work.

Facts get the same care. Agents never invent metrics: a missing figure is written as "unknown". Every link must be a full URL a person can check in one tap. People decide what goes live, and every production change can be rolled back without relying on the AI.

Code goes through pull requests

Day-to-day development happens in Cursor. For larger pieces of work, Cursor's cloud agents work on a branch and open a pull request on GitHub. The automated tests and preview deploys must pass, and a person on our team reviews the change before anything is merged.

Two lessons. The Grok Bot agents are best at business and admin work and Cursor is best at code, so business agents now write a clear brief and hand code work to Cursor rather than driving it themselves. And before a change, we often ask the coding agent to list its assumptions, mark each as verified or guessed, and wait for a person to check the list. It catches wrong guesses before they become wrong code.

Treat usage like a budget

AI agents are not free, and the bill grows in ways that aren't obvious at first. Three things drive most of it: long chats (every turn re-reads the whole conversation), agents messaging each other (each message is a paid turn for the agent that receives it), and browser automation (screenshots are the most expensive way to look at anything).

So we have rules. A connector or a small script comes before the browser. Routines stay silent unless something changed or broke. If a routine only asks "did anything change?", a script checks first and wakes the agent only when something moved. Every run ends with a three-line footer (did, skipped, failed), so a routine that quietly does nothing gets noticed. Long chats are retired: the agent writes a handover file and a fresh copy starts from it. Once a week the Chief of Staff proposes trims to the routines, and nothing changes until I agree.

Cheap work on our own hardware

Not every job needs a frontier model. Classifying records, extracting fields from scraped pages and first-pass rewrites of social posts go to open models (Qwen and Gemma) running on a MacBook, which the agents reach over a private network. The agents check that it is awake first and fall back to the cloud if it isn't. A person still checks anything that will be published.

Skills, written down once

When an agent works out how to do something well, such as babysitting a pull request until it is ready to ship, checking a page in a real browser, or keeping browser tabs under control, we write it up as a skill: a short markdown file with the steps and the traps. Every agent can read the shared library, so the second agent to face a problem doesn't start from scratch.

When a project outgrows the fleet

One project grew big enough to need its own agents, so we spun it out to a separate account and fleet. Agents on different accounts can't message each other, so they coordinate through a private GitHub repository: shared rules live in files, and messages are GitHub issues labelled for the account they're meant for, closed by the recipient when done. No secrets go in the repository; files say where a credential lives, never what it is. It is simple and leaves an audit trail.

A screen on the wall

In the office, the TVs switch on each weekday morning and show live dashboards: real-time site analytics, what the fleet is doing and what the coding agents are working on. It sounds like a gimmick, but the whole team can see at a glance whether things are healthy without opening a chat.

A day in practice

On 2 October 2026 we launched netprojects.com, the new home of NetProjects, three days ahead of plan. It replaced internetprojects.com with a single permanent (301) redirect: old pages with an equivalent, such as the terms and privacy pages, go straight to the matching page, and everything else lands on the new homepage. We told Google about the change of address and submitted the new sitemap. The site's automated tests run before each deploy.

The same day, GreekMythology.com, Airportia.com and NetScores.com gained a footer credit, "A NetProjects site · Internet Projects Ltd", and updated About pages. Each change went through a pull request that a person reviewed and merged. Agents did the groundwork: they wrote the internetprojects.com redirect map and opened all of those pull requests.

Two things went wrong. Merging did not start the production builds for Airportia and NetScores on our build server, because those build jobs had never been run. The agent reported the problem rather than guessing at a fix, and I started both builds by hand. Then, after the NetScores deploy, the live site showed a "Failed to fetch dynamically imported module" error, because the CDN was still serving old cached files. A person purged the cache, which fixed it. Neither fix was left to an agent acting alone.

I published the rebrand post on our company LinkedIn page myself. Every production step that day, from merging a pull request to purging a cache, needed a person's yes.

By the numbers (2 October 2026): 14 pull requests merged that day across our netprojects.com, GreekMythology.com, Airportia and NetScores repositories. Our AI bill is a $200-a-month Ultra plan, plus $76.51 of on-demand usage in the current billing cycle (as of 2 October 2026).

What can go wrong

Prompt injection. A web page, an email or another tool's output can hide text written to steer an agent. Our agents treat anything they read as data, not instructions, and they can't send, delete, buy or publish without a person's yes. That gate is the real control. A hidden instruction could still slip into a draft or pull request, which is why reviews check what changed, not just whether it ran.

A routine that looks healthy while doing the wrong thing. A run that finishes is not the same as a run that worked. The Monday fleet check reads what each agent actually did, not just whether it ran, and the huddle goes through it with me.

Review fatigue. With too many drafts, people stop reading them properly. So routines stay silent unless something changed, and every report ends with the same three-line footer: did, skipped, failed.

Early days

Grok Bot is a new product, and September brought the kind of early-days friction you'd expect. This is what we reported to Cursor's support team, in case it helps anyone running a similar setup:

• Activity files on the bots' computer stopped updating after 11 September. Nothing was missing: the full history was in the Grok Bot app, and the files had become old copies after a change to a newer backend. We now treat the app as the record.
• On 17 September, during a disruption posted on Cursor's status page, some cloud-agent launches and routine saves didn't go through. Our own practice: when a launch fails, an agent stops and reports rather than pushing on.
• On 18 September, during a slowdown posted on the status page, some bots were slow to answer, so a person switched one off by hand. Our own practice: we keep an off-switch for an agent's access that we control and that doesn't depend on the agent.
• On 22 September, an automatic update to the bots' computer started while it was idle. It didn't complete, the existing computer and its files were kept, and nothing was lost.

Cursor's support team picked up each report, looked into it on their side, passed the details to the Grok Bot team and kept us updated until each one was explained. We're grateful for how they handled it.

What we'd tell you

• Give each agent one job and a written description.
• Make drafts the default; decide in advance the few things an agent may do alone.
• Never let an agent invent a number. "Unknown" is a fine answer.
• Review usage weekly and trim routines before buying more capacity.
• Write things down: handovers, skills, failure logs.
• Keep a person on the decisions that matter, and make every change reversible.

That's how a small team keeps several long-running sites maintained, for a $200-a-month plan and some on-demand usage. It isn't magic and it isn't finished: it is a set of written-down habits that we adjust every Monday.

Alex Michalas is the founder and director of Internet Projects Ltd, which trades as NetProjects. You can read more about how we use AI at https://netprojects.com/standards/ai.