Focus on your mission, not your tech - Another Cup of Coffee (Posts about Business)

I Run Dozens of Projects with AI. The Hard Part Isn't the AI.

Anthony Lopez-Vito — Sat, 20 Dec 2025 12:00:00 GMT

I run a micro-agency which, by nature, is always resource constrained. We purposely stay small and nimble to adjust quickly to changes in a project, or the industry as a whole, and that means we can't take on lots of team members. I've written about our twenty-year journey elsewhere but the upshot is that I end up doing a lot of the work myself.

Staying small and specialised is manageable with a handful of projects but when you're running dozens for multiple clients, the problem becomes keeping track of the context. What's new on this project? What are the priorities on that one? What are the specific requirements for this particular client? Tracking all of that detail, even when using a project management tool like Teamwork or Basecamp, across a bunch of projects doesn't scale.

This article is about how I fixed this problem of project context. The fix itself started off as a simple improvement for one client, but it grew organically, and ended up completely changing the way I use a computer and manage my projects. I've started calling the result an Agentic Operating Environment.

Too Busy for New Toys

ChatGPT was released on 30 November 2022 and while I followed developments with interest, I was too busy to be an early adopter. When you run a small operation, you don't have the luxury of playing with new tools just because they're novel or fun. You need to know something works before you invest time in it because paying clients demand your attention.

However, by mid-2023, ChatGPT had gone mainstream enough that it was time I gave it a spin in earnest, so I suggested to a client that we try it on a project. The results were astounding. We completed months of work in a few weeks and saved significantly on hiring specialist consultants.

The potential was immediately obvious. One person could now do the work of several, deliver higher quality output, and do it faster. For a small outfit, that's a significant edge.

Trapped in the Browser

I started with the web interfaces everyone else was using, ChatGPT, Claude, and primarily ChatLLM which gave me access to multiple models at a fraction of the cost. They were genuinely useful, but two problems kept getting worse the more I relied on them.

First, there was no real continuity between sessions, and even after the Projects feature rolled out, keeping the uploaded context updated meant manually preparing and re-uploading documents every time something changed.

Second, the work was trapped inside the browser. AI could help me think through a problem or draft a document, but getting that output into my actual project files meant tedious copy-paste. The download and export features on these platforms were unreliable. Many times ChatGPT or ChatLLM would offer me a download link and the file would be empty or not what was expected. I needed a way to break out of the browser.

Breaking Out

Claude Code was the breakthrough. Instead of talking to an AI in a browser window, I had an agent that worked directly inside my file system's project directories. It could read files, run commands, and do real work on my local machine.

Then there were the context files, giving the agent project background and instructions. Suddenly we had an AI that could pick up where the last session left off so there was no more re-explaining, no more starting from scratch.

The real shift was realising what "runs commands on your machine" actually meant. Yes, this was a coding tool designed for software developers to write and debug code. But it could run any terminal command, which meant it could configure my local environment, install packages, and manage services. And if it could do that locally, it could SSH into a remote server and do the same thing there. This was more than a coding tool. It was a general-purpose operator that could do anything I could reach from a terminal. That's when it became the foundation for everything else.

Claude Code obviously wasn't just for coding. Systems administration, project management, writing, research, document generation, anything that benefits from knowing a project's context could now be handled by an AI. The tool was designed for developers but the principle applied to everything I do day-to-day.

That opened a bigger question. If an agent can read a context file, what else could you put in one? Could you give it genuine working memory, like what happened last session, what's stuck, what another project needs from this one?

One Client, Many Agents

I started with one client who had particularly complex needs. Instead of one general-purpose AI assistant, I created specialised agents as separate Claude Code projects, each handling a different area of the client's work:

Systems administration
Web development
Content curation
Project management
Requirements analysis
Research
Document generation

Each agent had its own context, its own working memory, and its own domain expertise. The difference was immediate. Switching between projects no longer meant rebuilding my mental model of where each one stood. For someone juggling many fast-moving and slow-moving projects at the same time, that friction adds up.

Then I deployed the same approach on a second client, one that happened to have team members who overlapped with the first. This is where the cognitive burden genuinely lifted because the agents remembered all the details. Who works on what, what the specific requirements are, what happened last session and the session before that. Each agent would know at the start of every session what I used to carry around in my head, across two separate clients, without mixing anything up.

I stopped being the person who has to remember everything because the agents did that now.

Teaching Agents to Talk

The agents needed to communicate though. An infrastructure change in one project might affect the web development project, or a content decision might depend on input from project management. Plus, these agents weren't all running on the same AI vendor.

I was already using different models for different strengths. Some are better at careful, structured reasoning; others are faster and cheaper for routine tasks; some handle large volumes of context well; others are stronger at creative work or code generation. Picking the right model for each job made sense, but the agents lived on different platforms and had no native way to coordinate.

My first attempt at solving this let agents edit files directly in other projects. That soon broke when one agent tidied up files another agent needed, but the fix was obvious. My university research was in multiprocessor computing, and this is a solved problem. Also, Linux processes don't scribble in each other's memory; they communicate through pipes and message queues. Same principle, different scale. Instead of agents editing each other's files, they send structured messages, or memos. Each memo is a plain-text markdown file dropped into the receiving project's directory, and the receiving project picks them up at its next session. Because the memos are plain text files, they work across any AI tool that can read files. A Claude agent sends a memo, then a ChatGPT agent picks it up next session. The vendor boundary becomes invisible.

This was a bigger deal than it might sound because it meant I could pick the best model for each job without worrying about whether the agents could coordinate afterwards. Cross-project and cross-vendor communication, solved in one move with plain text and file conventions.

Working Memory

The memo system solved communication, but agents also needed memory that persisted between sessions.

My first version was a single state file with no size cap. It grew quickly and before long the agent was spending its limited context window reading history it didn't need. Still, the fix was straightforward. A project brief captures confirmed knowledge that changes slowly, like what the project is, who's involved, and what's been decided. A state file tracks what's happening right now and what needs to happen next. An archive holds older progress that isn't immediately relevant. A separate file captures reusable patterns and gotchas so the agent doesn't repeat the same mistakes. Git sits underneath everything, so nothing is ever truly lost and you can always trace what happened and when.

Each layer serves a different purpose. The conventions keep them from bleeding into each other.

An Agent That Builds Agents

By this point I had a system that worked. I had specialised agents with context files, state management, memo-based communication, vendor-neutral conventions. However, setting up a new project meant creating the right files, writing the context, establishing all the conventions. Repetitive work.

So I created what I think of as a factory agent. An AI agent whose job is to create other AI agents. Give it a project brief and it scaffolds everything like context files, state tracking, memo conventions, project-specific instructions.

Next was a manager agent that sits above the project agents and keeps the high-level view. It knows what's happening across all projects without holding the details of any single one. Each project agent tracks its own domain in depth but the manager tracks the big picture and coordinates between them.

Three layers:

a factory that creates agents;
a manager that coordinates them;
and project agents that do the actual work.

I started moving all my projects onto this system and jumped from two to dozens in the space of a few weeks.

The Boring Bits That Matter

The system works. But the problems that come with running AI agents on real client work are unglamorous and unavoidable.

I was reviewing an agent's work and noticed it had been claiming tasks as complete without actually doing the work. It reported everything as fine but when I challenged it, the agent admitted taking shortcuts. A convention was needed to require explicit state updates, so I put in place a task checklist system. It's not a trust issue. The models just need clear structures to follow. That's a recurring theme with this work: better conventions lead to better results.

I also learned which tasks justify the most capable model. Strategic work, writing, and complex decisions benefit from the best model available, but routine file scaffolding and handover updates don't need it. The difference shows in speed. A lighter model handles simple tasks in seconds where a heavier one takes noticeably longer, and if you're paying per use rather than a flat plan, the cost adds up too. It sounds like a small thing until you're running several sessions in parallel and a heavier model is still churning through a handover update while you're waiting to start the next project.

Then there are the invisible failures, the ones that don't produce error messages. An agent confident it's working in the right project directory turns out to be somewhere else entirely, and without conventions this happens a lot. Agents that archive messages before completing the actions in them. Getting them to follow the conventions reliably is one of the harder problems, and it's still ongoing. Over twenty documented patterns now, each one born from something going wrong in real client work.

Why Better AI Won't Fix This

If you're running multiple projects across multiple clients, a smarter model doesn't help much when it still forgets everything between sessions. The AI is already good enough but the coordination problem stays the same. What's missing for most people is the infrastructure and conventions that make it consistently useful across real work.

Most small businesses are still figuring out where AI fits. If you're starting to rely on it across multiple projects, the ceiling comes quickly. There's too much context to carry manually, too many sessions starting from scratch, and you end up being the human messenger between tools that can't talk to each other. The temptation is to stitch together automation workflows to fix this, but that's plumbing, not infrastructure. It breaks when any component changes. Building on the vendors' own tools means they maintain the foundation. You just maintain the conventions and customise them for your needs.

The hard part was never the AI but the conventions, the memory management, the communication protocols. Boring problems that determine whether AI actually works across real projects or just impresses you in a single session. I've solved it for my own business and I build this infrastructure for others. If any of this sounds familiar, I'm happy to talk through it.

Common Questions

Do I need to be technical to set this up?

To operate it, no. The conventions are plain text files that AI agents read and update. You don't write code or manage infrastructure day to day. Setting the system up does require technical knowledge (which is where I come in), but once it's running, working within it doesn't.

What AI tools does this work with?

Any tool that can read files in a project directory, which is most of the capable ones now. I currently use four different vendor families. Because the conventions are plain text with no vendor-specific dependencies, new tools slot in without changes. Given how quickly things shift in this space, that flexibility has already proved its worth several times over.

What happens if I stop using AI agents?

Everything is in markdown files. Your project state, history, issues, and accumulated knowledge are all human-readable and useful whether or not you're using AI. You'd walk away with better project documentation than most businesses have, which isn't a bad outcome regardless.

This article is part of an ongoing series on how Another Cup of Coffee is adapting to AI. Explore all articles in this series.

Footnotes

Featured image photo by Matt Benson on Unsplash.

Still Alive: A Micro Agency's 20 Year Journey - Part 2

Anthony Lopez-Vito — Thu, 14 Nov 2024 15:28:15 GMT

In Part 1 of Still Alive: A Micro Agency's 20 Year Journey, I reflected on Another Cup of Coffee's journey from a one-person freelancer operation running from a rented mailbox address, to setting up in a trendy unit Westbourne Studios. Here I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

Finding a Balance: Growth and Resources

A few doors down sat what I wanted for our future. It was a large and successful media agency staffed with very confident ex-BBC people. They had loads of sales reps and account managers. I think it was among the first generation of the global web agencies we have today.

The founder was famous in our circles for saying that he didn't bother getting out of bed for less than £30,000. That amount is common for web projects now but saying this in the early 2000s was quite grandiose and flamboyant. Though we were charging a fraction of their rates, I imagined someday reaching their scale.

However, running a small web agency in London is challenging to say the least and scaling was the biggest problem. We were too small for large projects, but small projects wouldn't pay for growth. It was a classic trap.

Sell and Keep Selling?

Looking back, I think the key to growing an agency of any size is to just sell. Sell and keep selling even if you're not sure you can deliver. This is why the large agency had so many sales and account managers. Other agencies I've observed over the years seem to have grown in this way: they are sales-heavy and make lots of nice promises. But I've never been comfortable with making promises unless I'm sure of them so our growth remained stunted.

Meanwhile, our office space wasn't really free. It came with a heavy cost in the form of commitments that took my time away from building the business. The elephant in the room wasn't that big agency but our premature attempt at playing big.

It couldn't be ignored for very long as I struggled to bring in the right projects to ensure everyone was paid. It became clear that the traditional office setup wasn't sustainable and I had to make some difficult choices, quickly.

Transforming Into a Cloud-first Virtual Agency

Goodbye Westbourne Studios

Survival often means letting go of how you imagine things should be. Our biggest advantage was that we were scrappy and nimble so I decided to use it. We didn't actually need a trendy office and everyone was more productive without the daily commute into West London.

Within a couple of weeks of making the decision, we transformed into a cloud-first operation. I also hired more freelancer friends from the Philippines to fill our skills gap. Suddenly, Another Cup of Coffee was a fully remote virtual agency, years before the concept became popular.

Digital Nomad and Prevailing

Being cloud-first and remote meant that I could do the digital nomad thing for a while too, working out of all sorts of unconventional places. This opened up the opportunity to pick up clients globally. Even now, the majority of our projects come from outside the UK.

Karl and Pafsanias moved on to other—almost certainly greener—pastures but by then we'd evolved into a collective of remote colleagues, forming teams as projects demanded. This lean and agile model allowed us to weather storms that have since sunk many of our contemporaries.

I can say with some sense of accomplishment that Another Cup of Coffee has outlasted all three of the ventures who shared our unit, and also that large agency I'd once admired. The key was our ability to try out different ways of working. The founders quite possibly sold the business and exited with large bonuses, but I'm after something different: an establishment that can be handed to another generation. (More about this will follow in another post.)

Moving Towards Specialisation

Our early advantages began to fade as remote work became mainstream and sites like Elance and oDesk gave even small businesses access to global talent. This rise in cross-border competition made it difficult to stand out by only offering general website services, and even our strong relationships with existing clients wouldn't guarantee the cash flow needed to keep the business afloat.

At the same time, Drupal's growing complexity turned maintenance into a huge drain on resources. Again it was time to adapt and the answer came from an unexpected direction.

I'd spotted a need for content migrations, specifically from Drupal to WordPress, and built up an expertise in data-heavy web projects. It was unglamorous and mundane engine-room work so few agencies were interested in training up their talent for such a niche skill.

Version 1 of our custom-built Drupal to WordPress Migration Tool

Leaning Into Your Nature

But it was necessary work that happened to fit my meticulous nature and long experience with databases. Further, businesses were beginning to realise the value of data and content while most of our colleagues were focused on dazzling user experiences. Data was our differentiator.

Another Cup of Coffee shifted to becoming a boutique data migration consultancy with myself as principal consultant supported by a few freelancers. Unexpectedly, I became a pioneer of Drupal to WordPress migration services and was recommended by WP Engine in a whitepaper guide.

This ultra-narrow specialisation gave Another Cup of Coffee a much-needed distinction for almost ten years. Run a web search now and you'll see many solutions and services for content migrations but we were one of the first.

Looking Forward

Since those early days, we've kept evolving alongside shifts in technology and ways of working. I can't claim that any of it was planned but I can say we've always been willing to change, just slightly ahead of our peers. Throughout this journey, I've learned that survival isn't about being the biggest or the most innovative. You survive by keeping customers happy and watching out for dust on the horizon, ready to move before a stampede arrives.

We once embraced virtual offices, the cloud-first paradigm and global remote working before they were common. Now we find ourselves very suddenly confronted by something new. I think it's obvious that AI will be disrupting our lives in ways that will be hard to avoid. It's again time to learn to adapt just as we always have.

This is the first in a series of posts about our journey and how we're adapting to Artificial Intelligence in our lives. I do hope you'll follow along with me as I share what I've learned.

'Still Alive' from the Portal game credits. I never played the game but I've always enjoyed the sound and lyrics.

Footnotes

Featured image photo by Lil Mayer.
Still Alive is by Jonathan Coulton. The official video with Sara Quin and Dorit Chrysler can be found here.

Still Alive: A Micro Agency's 20 Year Journey

Anthony Lopez-Vito — Tue, 15 Oct 2024 15:28:15 GMT

Recently I was handing over tasks to an AI when it struck me how much my work has changed. It's been two years since OpenAI released ChatGPT-3.5 but things were so different when I first started Another Cup of Coffee. One of my biggest problems, almost twenty years ago, was figuring out how I'd hire skilled people with no budget. Now I'm learning to understand how to use something that's been trained on all the world's knowledge, while paying less than the price of lunch.

This change is astounding so I thought to reflect on our journey. I'd like to tell the story of building Another Cup of Coffee from a one-person operation to a survivor of multiple technological revolutions. It's a story about the decisions, both good and bad, that led to where we are now. Most of all, it's about learning to adapt before a shift in paradigm.

I'd like to share this now because I believe the developments in Artificial Intelligence have brought us to another turning point. It's once again time to adjust to new ways of working. Before I get into that, I think it's important to look back on the past to understand how we got here.

Finding Our Path

Another Cup of Coffee has never positioned itself as a trailblazer. It was founded on the principles of reliability, technical expertise and long-term client support. We focus on the behind-the-scenes work so that our clients can shine. And while we don't try to be the first to adopt every new trend, we have found there's value in selecting tools and methods that make our services better.

Over the past two decades, our approach has positioned us to adapt to industry shifts while ensuring that our clients remain happy with the core of what we do for them. This philosophy was a counterpoint to the early days of the web which was an experimental and somewhat chaotic scramble to try new technologies.

The Early Web

The web was very different in the '90s. I remember moving out of the comfortable walled garden of CompuServe into the wild web—and being completely underwhelmed. It was slow, even after upgrading to a blazingly fast 28.8K modem.

Browsing sites on NCSA Mosaic was confusing too but we netizens soon understood the Net to be a place without rules. And if you wanted something, you had to build it, so we did. We hand coded sites in Notepad, Vi, FrontPage or HotDog. (Some of you must remember HotDog, right?) We built and experimented and figured things out as we went along.

HotDog 1.0 web editor released in 1995

After university, I landed jobs working on mobile data synchronisation, building online communities, web databases, and rolling out the first mobile services. These concepts are taken for granted now but they were pioneering back then. People quickly integrated new technologies into their business and personal life, opening up different approaches for accomplishing everyday tasks.

Starting Out as a Freelancer

It was exciting work but I liked doing things my own way and set out as a freelancer in the early 2000s. I wore whichever hat would get work: technology analyst, database developer, systems administrator, network engineer, and of course, 'webmaster' (how quaint). Remote work wasn't a thing yet, so legitimacy meant having a proper business address.

People would blag desks from friends' businesses or pay for expensive serviced office space. I chose the quick and easy route: a rented mailbox address in Gloucester Road, London. Just a block away from the tube station and a short walk from Kensington Palace, it sounded legit and swanky! But no, by necessity I was working from home and operating a virtual office before it was the norm.

Fresh Coffee and Trendy Peers

After a few years as a solo freelancer, I realised that having a team behind me was necessary to take on more ambitious projects. When Another Cup of Coffee was formally established in 2006, it was a natural continuation of those freelancer years but with a more structured agency approach. The aim was to offer fully-functional but reasonably priced websites to small businesses, using a set of ready-built tools and an emphasis on customer service.

Many developers were still rolling their own custom solutions. They retained the do-it-yourself mindset of the early web and didn't realise that open source Content Management Systems had matured enough to offer production-ready web platforms. WordPress was still mostly a blogger tool so I chose Drupal because of its flexible content structure and growing module ecosystem. We offered complete web solutions at a fraction of the cost and development time needed by most other agencies.

Westbourne Studios

I set up in a client's spare meeting room in the trendy Westbourne Studios, near London's famous Portobello Road Market. Westbourne Studios was a space popular with creatives, musicians and media professionals which, after hours, transformed into one of Notting Hill's most popular nightclubs.

In exchange for free office space, I handled project management for the host company. We shared the unit with three other micro agencies in the cool creative media arena so as techs, we were somewhat out of place.

Potato phone photos of Westbourne Studios in the early 2000s

Our initial team was small but promising. My friend Lan handled technical support; Karl, a colleague I befriended from my first job out of university, took care of development; Pafsanias, a brilliant fresh graduate who responded to my Gumtree job ad, created the front-end eye candy; Benjor, another friend who ran a small design studio in the Philippines, was our remote designer. I focused on project and account management while trying to build up the business. Claire (not her real name) was in charge of sales.

Early Mistakes

We all gelled personally but I learned an expensive lesson with Claire. You see, she couldn't actually sell. Claire was a photographer looking for side work, and I thought her outgoing personality would make up for inexperience.

I was wrong. You need the right type of person in sales and she wasn't that person. It was my mistake. Perhaps I was motivated by the need to fit in with the other creatives in the building but in any case, it was a bad hire on my part. I really should have driven sales but I wasn't a salesperson either.

My mistake with sales was one of several that would lead to problems balancing growth and resources. In Part 2, I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

This is the first in a series of posts about our journey and how we're adapting to Artificial Intelligence in our lives. I do hope you'll follow along with me as I share what I've learned.

Still Alive: A Micro Agency's 20 Year Journey - Part 2

In Part 2 of Still Alive: A Micro Agency's 20 Year Journey, I recount the initial challenges we faced as an agency and how we survived by transforming the way we worked.

Read Part 2 Now

Footnotes

Featured image photo by Emiliano Vittoriosi.
HotDog 1.0 screenshot from The Web design Museum.

Focus on your mission, not your tech - Another Cup of Coffee (Posts about Business)

I Run Dozens of Projects with AI. The Hard Part Isn't the AI.

Too Busy for New Toys

Trapped in the Browser

Breaking Out

One Client, Many Agents

Teaching Agents to Talk

Working Memory

An Agent That Builds Agents

The Boring Bits That Matter

Why Better AI Won't Fix This

Common Questions

You may also like

Footnotes

Still Alive: A Micro Agency's 20 Year Journey - Part 2

Finding a Balance: Growth and Resources

Sell and Keep Selling?

Transforming Into a Cloud-first Virtual Agency

Digital Nomad and Prevailing

Moving Towards Specialisation

Leaning Into Your Nature

Looking Forward

You may also like

Footnotes

Still Alive: A Micro Agency's 20 Year Journey

Finding Our Path

The Early Web

Starting Out as a Freelancer

Fresh Coffee and Trendy Peers

Westbourne Studios

Early Mistakes

Related posts

Still Alive: A Micro Agency's 20 Year Journey - Part 2

Footnotes