How I work with AI agents

I believe one person working with AI agents can build a unicorn. My turning point in working with agents was Claude Opus 4.5.

Agents in my working day

My agents manage my schedule.

When I want to know where a project stands, I ask in Telegram. An agent replies with the details for that project, whichever one I asked about.

The harness around the model

I build with Claude Code. What lets me hand agents real work is the harness around the model:

• Project instructions. Each repository has a CLAUDE.md file that tells the agent how to work there: how to run the project and which documentation to follow before touching related code.
• Skills. These are reusable standards the agent loads when a task calls for them. One holds my writing rules, so posts like this one avoid the habits that make text read as machine-made. Another runs an SEO, GEO and AEO audit of a website.
• An MCP server for every system. I build an MCP server for each system I run, so any agent can connect to it. When a system has an API, I build the MCP server on top of that API. That is how my agents reach tools such as a content system and read-only analytics.
• Parallel agents. I split long tasks across several agents that work at the same time and report back when they finish.
• Checks. The agent verifies its own work with builds, screenshots, speed tests and requests to the live site before it tells me something is done.

Me

I ask in Telegram and keep the decisions.

Telegram

Agents in Claude Code

They manage my schedule and answer about any project.

• CLAUDE.md
• Skills
• Parallel agents
• Checks

MCP

• Content systemMCP serverAPI
• Analytics, read-onlyMCP serverAPI
• Every other systemMCP serverAPI

How agents can carry a product

For any new product, I think agents can do most of the work at every stage while I keep the decisions.

AgentsMe

Stage	Agents	Me
Research	Read and summarise	Pick the problem
Requirements	Write the spec	Answer and cut scope
Design	Prototype in code	Judge look and feel
Development	Build, test, deploy	Review risky parts
Testing and release	Check and release
Customer support	Answer questions
Operations	Watch the numbers

• Research. Agents read competitors’ websites, documentation, forums and reviews, and come back with a summary that links to its sources. I decide which problem is worth solving.
• Requirements. Agents turn notes and conversations into a written spec with scope, edge cases and open questions. I answer the questions and cut the scope.
• Design. Agents produce mockups and working prototypes in code, and change them in minutes after feedback. I judge whether it looks and feels right.
• Development. Agents write the code and the tests, run the build, fix what fails and deploy. I review the parts that carry risk.
• Testing and release. Agents open the product in a browser, take screenshots at phone and desktop sizes, run performance checks and confirm the release on the live site.
• Customer support. Agents answer common questions from the documentation and the product’s own data, and pass the rest to a person with the context already written up. Repeated questions become new documentation.
• Operations. Agents watch the numbers, flag what changes and write the weekly summary.

A real example: this website

This site was built that way. In one working session in Claude Code, an agent:

• put Joseph Wright of Derby’s The Alchemist in Search of the Philosopher’s Stone behind the pixel field on the home page, so the mouse, scrolling and slow drifting windows uncover it
• filled the SABIR wordmark with the same painting and rebuilt the portrait frame as animated pixel squares
• wrote the drafts of the other blog posts in a parallel agent, using only facts from each product’s website
• ran an SEO audit, then added structured data, a questions section and a summary file for AI assistants
• installed Google Analytics and raised the mobile PageSpeed score from 99 to 100
• pushed each change and checked it on the live site

My part was taste and decisions. I chose the painting after trying a Caravaggio first, turned down a glowing effect on the wordmark, picked the colour theme and decided when each change went live.

Where it still breaks

Agents make mistakes, and the same session had three.

The agent reported that the portrait file used in the structured data was missing. It was there; the agent’s file search had skipped JPEG files. It then found the file in the project, confirmed it on the live site and corrected itself.

A design change looked broken in the browser because the local development server was still serving old code. The agent measured what the browser had received, found the stale files and restarted the server.

The agent built a glow around the wordmark that I didn’t like, so I asked it to take the glow out.

The agent’s own checks caught the first two mistakes before anything reached the live site. I caught the third by looking at the page.

What I would pass on

Five things I would tell anyone who wants to work this way:

1. Write the instructions down first. Give every repository a CLAUDE.md that says how to run the project and which documentation to read. Otherwise you repeat the same explanations in every session.
2. Put an MCP server in front of every system. If the system has an API, build the MCP server on top of it, so any agent can reach it the same way. Start with read-only access where you can, as I do with analytics.
3. Turn your standards into skills. If you keep correcting the same thing, such as writing style or SEO, write the rule once as a skill and let the agent load it when the task needs it.
4. Make the agent show its checks. Ask for the build result, the screenshots, the speed score and the live URL before you accept that work is done. In the session above, those checks caught two of the three mistakes.
5. Keep the decisions that need taste and judgement. Let agents research, draft, build and test. Pick the problem, judge the result and decide what ships yourself.