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

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.

Building an Operating Environment for AI Agents

Anthony Lopez-Vito — Thu, 15 May 2025 13:20:00 GMT

Over the past twenty years I've managed server infrastructure, built WordPress sites, handled data migrations and put together architecture specs for clients across multiple organisations. If you juggle multiple clients you'll know the feeling. Every project has its own context, its own history, its own set of things that need to happen next. Even when you use some sort of project management tool, a lot of the details still need to live in your head. Furthermore, every time you switch between projects, you need to reframe your mindspace to recall where a particular project is in that particular moment in time.

I've now unexpectedly solved this problem by building a coordination system that lets AI agents work across projects, clients, and organisations. It wasn't something I set out to build and instead, it just sort of happened organically as I began incorporating agentic coding tools into my everyday workflow. I've started calling it an Agentic Operating Environment, or AOE. Essentially, it's a set of file-based conventions that give AI agents persistent memory and a way to coordinate across projects and vendors.

The Problem That Crept Up on Me

I was already using AI seriously across my projects for a range of different tasks like writing code, research and troubleshooting, drafting client documentation, and processing data. The problem was continuity. Every new conversation started from scratch and I'd spend the first ten minutes of every session re-explaining what the problem or project was about, what had been done, and what needed to happen next. I'd have to prepare and manually upload files to give context. Switch to a different AI tool and the whole thing started from zero. This is fine for a one-off task, but it was a real hassle for working on a dozen active projects across multiple clients.

Then context files appeared with Claude Code introducing a file the agent reads at the start of every session, giving it project background and instructions. Other tools followed with their own versions and suddenly agents could pick up where the last one left off. I remember thinking this changes everything.

Most people were writing code with these tools but I was now starting to run my business through them. For that purpose, knowing about one project at a time wasn't nearly enough. I needed agents that understood what was happening across projects: what's blocked, who's waiting on what, which client deliverable depends on which internal task finishing first.

This problem opened up a bigger question. If an agent can read a context file, what else could you put in it? Could you give it genuine working memory, like what happened last session, what's blocked, what another project needs from this one? Also, what if one agent's work needed to inform a different project? Could you pass that context along without me being the human messenger as was needed in the web versions?

What I ended up with is a few things that work together::

Working memory and project context so agents know what happened last time and
understand the project
A memo system so they can talk across projects
Vendor-neutral conventions so I'm not locked to one AI provider
Specialised agents each handling a different area of work
Utility agents that manage the environment itself: a coordinator for cross-project visibility, a sysadmin for machine configuration, a configurator that scaffolds new projects
A factory that deploys new agent environments from templates

The individual pieces aren't complicated. Getting them to work together reliably across dozens of projects is where the time went, and what emerged is an architecture that looks fundamentally different from how most people structure their AI assistants.

It Doesn't Look Like Much

New AOE deployment for our website manager

It doesn't look revolutionary. It's a terminal interface that's been used since the earliest days of computing. But what's happening in that conversation is that I described what a project needed in plain English and an agent built the entire working environment: context files, state tracking, communication channels, vendor-specific instructions. No commands to remember, no forms to fill in, no setup wizard, just a description of the outcome I wanted.

This is what I mean by "operating environment". It's not an operating system that manages hardware and device drivers, but something that sits above all of that. Where your OS gives you a graphical or command line interface to the computer (windows, menus, mouse clicks, command parameters to remember), this gives you a natural language one. You just describe what you need in plain English and an agent works out how to get it done.

What surprised me is how little custom code this requires. Tools like Claude Code, Codex, and Gemini CLI already ship with everything you need to get started. They read and write files, run shell commands, search codebases, and follow instructions from context files. I'm not stitching together third-party tools and hoping they still work next month. Instead, the foundation rests on core features that the vendors build and maintain.

The hard part is more the conventions than the tooling. For example, what goes in each file, how to draw boundaries between projects, how to keep agents following the rules session after session. That's where the time went.

This started off as a simple improvement for one client but has now completely changed the way I use a computer and manage my projects.

Working Memory

Every project gets a handful of markdown files that serve as the agent's working memory. A project brief (BRIEF.md) captures confirmed knowledge that changes slowly like what the project is, who's involved, what's been decided about scope and technical direction. A state file (STATE.md) tracks what's happening right now and what needs to happen next. An archive (HISTORY.md) holds older progress that isn't immediately relevant. Other files capture reusable patterns (INSIGHTS.md) and whatever domain context the agent needs. The whole lot sits in a git repository, so nothing falls through the cracks and every change is auditable.

Here's what a typical project looks like on disk:

project-root/
├── BRIEF.md           # Confirmed project knowledge
├── CLAUDE.md          # Agent instructions
├── STATE.md           # Working memory
├── HISTORY.md         # Archived progress
├── INSIGHTS.md        # Reusable learnings
├── memos/
│   ├── incoming/      # Unprocessed messages
│   └── archive/       # Completed messages
└── docs/              # Project-specific reference

If any of that sounds abstract, the files map to things you already know:

File	Purpose
BRIEF.md	What the project is, who's involved, key decisions
STATE.md	What's happening now, what's next
HISTORY.md	Archived progress
INSIGHTS.md	Reusable patterns and gotchas
CLAUDE.md	How the agent should behave

It works in layers, with the agent reading STATE.md at the start of a session, doing its work, and updating it when it's done. Here's what a real one looks like. It's anonymised, but the structure is genuine.

## Quick Reference

| Key | Value |
|-----|-------|
| Project Path | ~/Projects/ClientA/web-dev |
| Last Updated | 2025-09-28 |
| Last Agent | Claude Code |
| Current Focus | Header component refactor |

## Current Status

Theme migration 80% complete. Navigation and footer done,
header still needs mobile breakpoints. Blocked on logo
asset from client.

## Recent Progress

### 2025-09-28
- Completed footer template with accessibility fixes
- Agent: Claude Code

### 2025-09-26
- Migrated navigation patterns from legacy theme
- Agent: Gemini CLI

## Next Actions

1. [x] Migrate navigation patterns
2. [x] Rebuild footer template
3. [ ] Refactor header component (blocked: logo asset)
4. [ ] Cross-browser testing

## Handover Notes

Header refactor is ready to go once the client sends the
logo. SVG preferred, PNG fallback. The mobile nav uses a
slide-out pattern, not a dropdown. See docs/nav-spec.md.

Every new session picks up exactly where the last one left off. The agent knows what's done, what's blocked, and why. Older entries get archived periodically to keep the working file lean.

Pick the Right Tool for the Job

I use Claude Code, Codex, Gemini CLI, and DeepAgent across different projects, and each has strengths for different types of work (and some genuinely maddening blind spots, but that's a longer conversation). The system doesn't care which one you pick.

Each project carries vendor-specific instruction files like CLAUDE.md for Claude Code, AGENTS.md for Codex, GEMINI.md for Gemini CLI. DeepAgent handles its configuration through its own rules system rather than a markdown file. These files tell the agent how to work in this particular project, covering things like session protocols, coding standards, and how to handle state updates. The content differs per vendor because each tool loads instructions differently, but the conventions they enforce are identical. If I want to switch providers for a project, nothing breaks.

What those instruction files actually enforce is the same core loop. Read STATE.md and check for incoming memos, extract your action list, do the work, update STATE.md with progress and handover notes, commit. Every agent follows this regardless of vendor. The instruction files also cover git conventions (like always use the -C flag, never commit to another project's repo) and cross-project communication rules (send memos, don't edit other projects' files). The format is vendor-specific but the behaviour is nearly identical.

This is a deliberate choice as the AI vendor market is volatile, with pricing changes, shifting capabilities shifts, and new tools appearing constantly. Last year's best option might not be this year's, and if your operation depends on one provider's way of doing things, a pricing change or service outage becomes a showstopper.

Claude API errors? Launch another vendor's model and keep working.

With vendor-neutral conventions, I simply run another vendor's agent and the project keeps running. It's a standard part of my workflow. Also, because the conventions are just files, there's nothing stopping you from running local models if your hardware is powerful enough. The system doesn't care whether the AI is in the cloud or on your own machine.

Cross-project Messaging

The agents needed to communicate across projects just as human team members do. For example, an infrastructure change in one might affect web development in another, or a content decision might depend on input from project management. However, the agents lived in separate project directories with no native way to talk to each other.

Initially I would let agents edit files directly in other projects. This was obviously not workable very early on when an agent tidied up what it thought were stale files that another agent needed. The fix was obvious as 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. Early bulletin board systems worked the same way: post a message to a board, the recipient reads it when they next connect. The principle hasn't changed in decades: send a message, let the receiver deal with it in its own time.

Same principle here. Instead of agents editing each other's files, they send structured messages (I call them memos) into each other's memos/incoming/ directories. The receiving project picks them up at its next session then archives any that have the necessary actions completed. Because the memos are plain text files with naming conventions, they work across any AI tool that can read files. A Claude agent sends a memo, a Gemini agent picks it up, and the vendor boundary becomes invisible.

A sysadmin agent sends a bug to the project's developer agent.

The files are named MEMO-<topic>.md and follow a standard format. Here's one (anonymised) where a web development agent is notifying an infrastructure agent that a deployment is ready:

# Memo: Staging Deployment Ready

**From:** web-dev @ ~/Projects/ClientA/web-dev
**To:** sysadmin @ ~/Projects/ClientA/sysadmin
**Date:** 2026-02-28
**Subject:** Theme migration ready for staging

---

## Purpose

Header refactor is complete. Ready for staging deployment.

## Content

All templates migrated and tested locally. No new
dependencies. The only change to server config is the
new image optimisation path in the nginx rules
(documented in docs/nginx-changes.md).

## Action Required

- [ ] Deploy to staging environment
- [ ] Verify nginx config change
- [ ] Run smoke tests and report back

---

## Completion Notes
<!-- Receiving agent: complete this section before archiving -->

The receiving agent reads the memo at its next session, works through the checkboxes, fills in the completion notes, and archives it. The checkboxes are the accountability mechanism and a memo can't be archived until every action is ticked off. At least, that's how it's supposed to work; in practice, agents occasionally skip steps or archive memos prematurely. Getting them to follow the conventions reliably is one of the harder problems I've had to solve.

Putting Agents to Work

I started with one client who had particularly complex needs. Instead of one general-purpose AI assistant, I created specialised agents, each handling a different area like systems administration, web development, content curation, project management, research, document generation. Each agent has its own working memory and domain expertise.

Then I deployed the same approach on a second client, and the cognitive burden genuinely lifted. The agents remembered every detail 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.

Sitting above the project agents is a coordinator which is a dedicated agent whose job is cross-project visibility. It reads the state of every project (44 at last count, across 14 organisations), tracks what's blocked, routes memos between projects that don't know each other's paths, and maintains a dashboard of the whole operation.

The way it knows what's happening is straightforward because each project is registered in a YAML file:

- name: client-a-web
  path: ~/Projects/ClientA/web-dev
  organization: client-a
  description: WordPress theme development and maintenance
  tags:
    - web
    - wordpress
  dependencies:
    - client-a-infra
  registered: 2026-01-15

A scanner reads STATE.md from every registered project and builds a view of what's active, what's blocked, and what's gone quiet. The mechanism is simple but the visibility it gives you is automatic. No one has to update a dashboard or fill in a status report as the agents' own working files are the source of truth.

An Agent That Builds Agents

When the conventions started working reliably, I wanted a way to replicate them without manually setting up every new project, so I built what amounts to a factory agent. I give the agent a project brief and it scaffolds everything in one step. The output is a complete project directory including: - instruction files for each AI vendor, with session protocols, git conventions, and cross-project communication rules baked in; - a STATE.md with the Quick Reference table and empty sections ready to fill; - a memos directory; - its own README, HISTORY.md, INSIGHTS.md, and whatever domain-specific extras the project type calls for.

Different project types get different scaffolds. A sysadmin project gets server inventory sections and SSH configuration templates. A bookkeeping project gets invoices and reconciliation directories. The conventions are the same across all of them but the domain-specific bits vary. I can point the factory at an existing working project and say "set up a new one like this, but for Client B." It uses the existing project as a reference and adjusts for the new context.

The factory has deployed over forty projects so far, each one inheriting the same coordination conventions. A new project goes from nothing to a working agent environment in one step.

Star vs Mesh

Now that you've seen all the pieces, it's worth stepping back to look at the structure of what emerged because it's not the shape most people build.

Most AI assistant frameworks use a hub-and-spoke topology. Daniel Miessler's PAI is probably the best-known example with one central assistant, one identity, one memory system, and skill modules for different domains. Kenny Liao's personal assistant follows a similar pattern, with domain-specific plugins loaded into a single runtime. The skills are more sophisticated than they look. PAI's chain into each other, and Liao's use progressive context loading. But the structural principle is the same: one hub and everything flows through it.

My system uses a mesh topology. I first came across mesh architectures in the early 2000s while evaluating mesh networking technologies for a Japanese trading house. The concept isn't new, so applying it to AI agent coordination seemed like a natural fit.

Each project is an autonomous node with its own state (STATE.md, HISTORY.md), its own instructions (CLAUDE.md, AGENTS.md, GEMINI.md), and its own agent identity. No single node holds everything, and nothing requires them to sit on the same machine. Projects communicate asynchronously via memos, like Unix processes communicating through pipes.

	Star (PAI)	Mesh (AOE)
Context	One context for everything	Scoped per project; agent only sees what it needs
Boundaries	All domains share memory	Client A's data never enters Client B's context
Failure	Centre goes down, everything stops	One project breaks, others unaffected
Scaling	Gets heavier as you add domains	Adding a project is just adding a node
Vendor	Tied to one agent runtime	Each project picks its own AI vendor
Collaboration	Implicit (shared memory)	Explicit (memos with structured actions)

None of the major agent frameworks frame this as a deliberate choice. Anthropic calls their pattern "orchestrator-workers". LangGraph calls it "supervisor". CrewAI calls it "hierarchical process". They describe what the orchestration does, not what shape it takes. The structural decision goes unnamed, which is probably why it goes unexamined.

The hub model is optimised for one person wearing many hats, like a freelancer who does health tracking, writing, finance, and coding through a single assistant that knows their whole life. My model is optimised for many projects with clear boundaries, where a web development agent for Client A must never see Client B's project data, where cross-project coordination needs to be auditable (every memo is in git), and where different projects might need different AI vendors entirely.

The word "mesh" has started showing up in enterprise AI writing too, but there it means container orchestration, agent registries, policy enforcement. This is infrastructure for managing fleets of agents across an organisation. What I'm describing is much simpler concept of project directories that talk to each other through plain-text files.

It's the same underlying insight as PAI and similar tools. The filesystem is the context system, markdown files are the medium, but there's a key difference. Those systems use the filesystem for context while mine uses it for coordination too. Memos route between projects, state files track handoffs, every change lives in git. The filesystem is both the memory and the message bus.

Where It Stands

That's the full picture. Working memory, memos, vendor-neutral conventions, specialised agents, a factory to set up new projects, and an architectural structure that none of the major frameworks are talking about yet. The building blocks are markdown files, naming conventions, and structured messages. No database (unless you specifically need it for a project), no platform, and no special software. However, the judgement calls about where to draw project boundaries, how to scope agent responsibilities, and how to keep conventions working reliably across a growing number of projects are what took months of trial and error across real client work.

As of writing, there are 44 active projects across 14 organisations. This is real production work involving published websites, live content, architecture specifications, server infrastructure. None of this is proof of concept or theorising.

A few design principles fell out of the process that I think are worth naming:

Vendor-agnostic. Works with any AI that can read markdown. No proprietary formats, no lock-in.
Convention-based. No runtime dependencies, no database, no platform to maintain. It's files and naming conventions and that's it.
Distributed boundaries. Each project is its own island. Client A's working files never enter Client B's context unless you explicitly tell an agent to share something. Cross-project communication goes through memos as standard.
Human-in-the-loop. I approve every consequential action so the agents do the legwork while I make the decisions.

Right now the whole thing is passive infrastructure. I start a session, the agent picks up where the last one left off, then I close the session. The direction is toward semi-automated, where events trigger sessions and memos route themselves. But that's a story for another post.

It's not finished (honestly, I doubt it ever will be as it continues to grow and improve), but it handles real client work across multiple organisations every day. There's more to say about how this compares to other approaches and where it goes next, and I'll get to that.

If you're running multiple projects and spending too much time being the human messenger between them, this approach works. I'm happy to talk through how it might apply to your setup, drop me a line.

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

Why We Keep Using ChatLLM Despite Everything That's Wrong With It

Anthony Lopez-Vito — Mon, 20 Jan 2025 12:45:15 GMT

This article is part of a series on our journey and how we at Another Cup of Coffee are adapting to Artificial Intelligence. Competing in a market dominated by larger agencies means we have to be smart and a little bit scrappy, willing to experiment with new tools and alternative ways of working.

Over the past two years, AI has become a crucial part of our strategy, helping us punch above our weight and deliver more value to our clients. In this post, I take a closer look at a tool that has become central to our workflow: ChatLLM from Abacus.AI.

ChatLLM has been an incredibly useful addition to our toolkit, but it's certainly not without its drawbacks. While Abacus.AI's pricing makes their offering compelling, there are many areas where it falls short, such as in poor documentation, almost no support, and unreliable implementation. Nevertheless, ChatLLM has been a valuable tool, and I'll dive into our experiences with it, covering both the positives and the frustrations.

This post has not been sponsored by Abacus.AI, but if you're interested in ChatLLM, we have a referral link for those who want to give it a try.

How AI Has Changed Our Work

Before I get into ChatLLM specifically, it's worth briefly mentioning how AI has helped our day-to-day work. We've found that with the right AI tools, we can take on projects that would normally need more people, and we spend a lot less time on boring repetitive tasks, such as data cleaning and processing.

The quality of what we deliver has gone up and clients get better value while we continue to keep our pricing competitive. There have been many cases where we've been able to offer insights that used to require bringing in highly-paid specialists.

For example, there have been a number of projects where we've been able to save our clients money by delivering close-to-final draft documentation and reports that required specialist expertise. Instead of immediately hiring costly third-party consultants, clients simply had our AI-generated drafts reviewed by their in-house counsel, significantly reducing professional fees.

We've also cut expenses by using AI assistants to rapidly code custom, single-purpose tools rather than purchasing expensive off-the-shelf software or subscriptions. Those costs can add up significantly, especially for small agencies like ours. Such bespoke utilities to solve specific one-time project challenges could not have been feasible without AI.

Being an early mover into AI integration has given us insight into the massive shifts coming to the workforce and to society in general. We have already started adapting our business and skills to thrive in this new environment so I'm now more confident about Another Cup of Coffee's future.

What We're Using

We've tried loads of AI platforms over the past couple of years. Some stuck around but many others didn't. Aside from ChatLLM, we regularly use a range of other tools including:

October 2025 update: We've replaced a number of tools with Claude Code, which has proven superior.

They all have their specific use-cases but ChatLLM is definitely the one I personally reach for most often.

ChatLLM from Abacus.AI: What's Good and What's Not

What Is It?

As its name implies, ChatLLM is Abacus.AI's chat-based AI platform that gives you access to a bunch of different LLM models through one interface. You pay $10 US Dollars per user per month, and get access to the most popular models like ChatGPT, Claude Sonnet, Gemini and DeepSeek. Models are released so frequently that I haven't bothered to include the version numbers.

Abacus.AI doesn't just give access to multiple models. You get specialised tools like CodeLLM, their AI-assisted VS Code editor, and AI Engineer to help you build custom chatbots and AI agents.

Why We Like It

It's cheap. That's it. $10 a month for all those models is excellent value as we'd be paying over $50-$100 per month if we subscribed our most-used models individually. This means we can use the strengths of the different models rather than trying to make one model do everything.

We use it for all sorts of things: writing first drafts of client proposals; creating documentation or reports; helping debug and improve code; project planning; summarising project progress; and general brainstorming. It's not all great and the low price comes at other costs.

The Annoying Bits

Poor Documentation

The documentation is absolutely terrible, outdated and severely incomplete. Help pages casually reference features and interface elements without any explanation, expecting you to be familiar with their terminology for the various screens and settings. I've wasted so much time trying to figure out basic stuff that should be clearly explained.

No Customer Support

Customer support is also non-existent. I've sent questions about specific features and they go into a black hole. Good luck to you if you encounter problems. I suspect they're putting all their effort in supporting enterprise clients. If you're a small or medium-sized business, this will no doubt make you wonder if this is a solution you can trust with production-grade tasks. Right now, we don't use it for any client-facing solutions and a big reason is lack of customer support.

Terrible Interface

The interface is horrible too. It feels like it was designed by engineers who just bolted on features and stuck them in weird places. Aspects such as their version of the ChatGPT Playground are a complete kludge. You can't expect the kind of seamless interaction with your work that's available on ChatGPT's user interface.

CodeLLM - A Waste of Time?

CodeLLM is Abacus.AI's answer to AI-assisted code editors like CoPilot, Cursor and Windsurf. However, it feels like someone's half-hearted attempt at a side project, thrown together after hours and released, then forgotten. I won't even bother listing its problems and I recommend not wasting your time even trying it. Maybe CodeLLM will get better over time but I really don't see why it's available at all. Stick with the more well-known options.

Unreliable Custom Agents

When this review was first posted in January 2025, I mentioned my love-hate relationship with the custom agent feature. Back then, I found it useful for building agents to handle tasks we do regularly, such as generating documents, manipulating our back-office financial transactions, or providing chat access to local knowledge bases. I also mentioned problems with poor documentation and unexpectedly burning through credits using the AI Engineer feature.

Now I've stopped using it altogether because they've become unreliable. For some reason, previously working agents will hang, producing no output, or spit out an error. I did try contacting Abacus.AI support but there was no response or even acknowledgement that they'd received my message.

Unclear Pricing and Service Limits

You'd think that at $10 per user per month, you'll have a good idea of what you'll be paying. But that's not the case. Each user is allocated 2,000,000 compute points per month. What exactly that means is not at all clear. Here's Abacus.AI's explanation:

"Compute points are NOT TOKENS. They are simply a measure of usage of ChatLLM. With 2M compute points, you will be able to send 50,000+ messages on some LLMs in a month. 1,000,000 (1M) compute points can be as much as 70,000,000 (70M) tokens on some LLMs."

OK, so 50,000+ messages sound a lot and most months we're well within the limit. However, a few times I managed to burn through most of my compute points in a couple of afternoons of using AI Engineer. How? No idea.

New Features (mid-2025)

Abacus.AI has added a few more features to ChatLLM since I originally wrote this post:

DeepAgent: an autonomous agent that can help you with tasks like research, planning or building apps.
Tasks: a scheduling and automation utility designed to run AI-powered actions at certain times, intervals, or triggers.
Apps: no-code and full-code methods for launching apps.
Projects: a feature to organize chats, files, and workflow instructions into folder workspaces.
RouteLLM: a routing mechanism to send your queries to the best underlying language model.

Because of my poor experience with ChatLLM Custom Agents, I really haven't bothered to try out DeepAgent, Tasks or Apps. These new features may be worth some experimentation if I were a reviewer or YouTube AI influencer, but my focus is on getting work done. When you're running a business, you rarely have time to play with new things, and I feel that Abacus.AI wasted my time with Custom Agents.

Projects and RouteLLM are different though. They're built-in improvements to the chat interface and are probably my two most favourite ChatLLM additions so I'll spend a bit of time talking about them.

ChatLLM Projects

This feature is exactly like ChatGPT Projects and there's not much explanation needed here. You can organise chats into folders for easy reference. They're perfect for working on different areas within your business. In some ways, it has replaced ChatLLM's flaky Custom Agents implementation for my needs.

I'll have different 'agents' in project folders where I copy and paste prompts from old chats to get certain types of work done. For example, I'll have projects for proposals, coding tasks and client needs, like contract review or support requests. Each project can have its own custom instructions and files for context. This is perfect if you want to quickly create a task-specific AI without having to mess around with building an actual agent.

RouteLLM

When Abacus.AI first deployed RouteLLM, it was just one model among many alongside GPT, Claude, and Gemini. Now it's the default option. Your chats will go through RouteLLM unless you manually set your model.

It does a fairly good job of routing your chat to the right model but seems to favour OpenAI's GPT-5. This could be for my own use-cases though. It will sometimes inappropriately route queries to Gemini 2.5 Flash, and I suspect this is Abacus.AI trying to reduce their API costs.

But what's really great is the Regenerate using option. If you're not quite happy with a response, or you want to see how a different model will respond, just click the model button underneath. This is a massive time-saver. The alternative would be to switch your session to another model provider or use yet another service like Boxchat or chatplayground.ai.

Is ChatLLM Worth the Price?

Despite all those frustrations, ChatLLM is the AI tool we use most, and this is still the case many months after originally posting this review. The value it provides is just too good to ignore. We've become used to its shortcomings and found ways around its poor interface.

I've been tempted to re-subscribe to ChatGPT or Claude whenever they release a new model but stopped to think: is it worth the extra expense when they'll be available on ChatLLM within days?

If you're a small agency or freelancer and you can put up with some friction in exchange for powerful capabilities at an affordable price, ChatLLM is definitely worth looking at. Just don't think you'll get anywhere near a polished experience or helpful support for your $10.

Being Transparent

I should mention that Abacus.AI is active in advertising through content creators, especially on YouTube. We haven't received anything for this review and I'm simply sharing our experience as paying customers. I genuinely find the tool useful and worth recommending, despite its many problems.

Give It a Try

If you're curious about what ChatLLM might do for your business, I think it's worth trying for the price of a couple of cups of coffee. Use our referral link here. (We'll get $5 if you sign up but they don't say what you'll get. Probably nothing.)

I certainly won't call myself an Abacus.AI fan, but I do think other small agencies and freelancers might benefit greatly from this tool, warts and all. For us, the trade-offs have been worth the price and like any tool, what matters is whether it fits your specific needs and how you work. ChatLLM definitely isn't perfect, but it's been really useful for us so for the price, you'll lose very little to find out if it works for you too.

Try ChatLLM Now

Use our referral link to try ChatLLM.

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.

Secure Your AI Workflow Using Local Tokenisation

Anthony Lopez-Vito — Tue, 12 Nov 2024 13:59:03 GMT

Secure your AI workflow with local tokenisation. PaigeSafe is a lightweight tool perfect for small agencies and freelancers handling sensitive client data in ChatGPT, Claude and other AI tools.

If you've spent any time at all using cloud-based LLMs like ChatGPT or Claude for client work, you've probably had that voice in the back of your head kick in: "Should I really be pasting this into a chat?" I'm sure that moment of hesitation is all too familiar for those who have started to integrate AI into work workflows.

Every day, many of us paste sensitive content into AI tools—client data, business strategies, internal documents—often without really thinking about where that information ends up. That data potentially becomes part of training sets, risking leaks by cropping up in future chats with other users. For freelancers and small agencies handling confidential client work, Large Language Models (LLMs) create a real dilemma. They're too useful to avoid but carefully sanitising content is a real chore.

Enterprises solve this with expensive solutions which are overkill and far too expensive for the rest of us. Those who want to take advantage of LLMs have been left with carefully reading through documents and running manual search and replace for names and numbers. This is tedious, error-prone and still stands a high likelihood of data leaks. Unfortunately, taking unnecessary risks with client data, spending ages on manual anonymisation, or avoiding AI tools altogether when working with sensitive information is no longer a good option to remain competitive.

Introducing the PaigeSafe Document Security Tool

PaigeSafe is a document security tool that helps protect your confidential information when using Large Language Models (LLMs) like ChatGPT and Claude. It uses the process of tokenisation by replacing sensitive data with non-sensitive placeholders. We originally built it as an in-house tool because we faced these exact same challenges. As a small team, we needed something that just worked without the expensive licenses and high learning curve.

PaigeSafe is currently in the prototyping stage to test if there is demand for this type of utility. It offers basic functionality, and the code lacks robust error checking. However, since it is intended to be run locally, there is minimal risk to your documents. All it does is offer a convenient way to search and replace text before you paste or upload sensitive text to LLMs. I regularly use it to sanitise my own documents.

Uses and Limitations

PaigeSafe does not try to offer an enterprise solution for those who need to meet strict compliance regulations. Here's where it fits in the document security landscape:

Perfect for: Freelancers, small agencies, independent developers
Good for: Regular business documents, client communications, project data
Not for: Banking systems, medical records, top-secret government files

PaigeSafe is a lightweight tool that helps you avoid accidentally exposing sensitive information to AI models. If you're handling typical client work like website data, marketing plans, business strategies, and project specs, this solution is for you. It's perfect for those, "I need to run this past ChatGPT but shouldn't share the client's name" moments. Or when you want to analyze customer feedback without exposing individual identities.

If you work for a financial institution, healthcare provider, or government contractor, this solutions of course will not be for you.

Where to Find it

The tool is built using Python and the Streamlit framework but if you use Docker, it can be easily installed by pulling the PaigeSafe image from Docker Hub. For more information, please visit the dedicated site at paigesafe.com.

Remember that it is still very much an early prototype but more useful features will follow. Please send feedback to paigesafe@anothercoffee.net

How to install PaigeSafe

Find out how to install the prototype application by following the instructions on the PaigeSafe website.

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 Workflow)

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

Building an Operating Environment for AI Agents

The Problem That Crept Up on Me

It Doesn't Look Like Much

Working Memory

Pick the Right Tool for the Job

Cross-project Messaging

Putting Agents to Work

An Agent That Builds Agents

Star vs Mesh

Where It Stands

You may also like

Why We Keep Using ChatLLM Despite Everything That's Wrong With It

How AI Has Changed Our Work

What We're Using

ChatLLM from Abacus.AI: What's Good and What's Not

What Is It?

Why We Like It

The Annoying Bits

Poor Documentation

No Customer Support

Terrible Interface

CodeLLM - A Waste of Time?

Unreliable Custom Agents

Unclear Pricing and Service Limits

New Features (mid-2025)

ChatLLM Projects

RouteLLM

Is ChatLLM Worth the Price?

Being Transparent

Give It a Try

You may also like

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

Secure Your AI Workflow Using Local Tokenisation

Introducing the PaigeSafe Document Security Tool

Uses and Limitations

Where to Find it

How to install PaigeSafe

You may also like

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