This is the third article in the “Leading A Team that’s Part Machine” series. You can read the introduction here and the second article about what constitutes a true agent here. In this article, I will cover the work I assigned to my agents, their costs and my decision to explore local AI.
Work-wise, my goals for a team of agents fell into two categories: The first was personal, the second commercial.
- Personal:
- Learn about AI by spinning up my own team of agents, doing real work and seeing how it impacts project management
- Managing my to-do items across my full-time job, side projects and writing calendar
- Task automation to reduce the time I spend on admin and other repetitive tasks
- Research: given a topic, product name, article, or email, I wanted an agent to go off and thoroughly research it producing a report of background information, fact checks, competitor products and insights about usefulness and future direction.
- Document drafting: using my writing style, draft articles and documents I could then check, extend and complete to streamline my writing progress
- Visualize my work backlog: take my favorite elements of kanban boards, cumulative flow diagrams, lists and charts to build a comprehensive work tracking system that updates as I complete work
- Commercial:
- WordPress development: I maintain some websites built on WordPress. Previously I paid for custom development to achieve functionality not available through configuration and plugins. I wanted agents to do this development work for me.
- Image and video creation: one website, PMillustrated.com, is image and video heavy with an ongoing need for new on-brand content. The 2026 ECO update alone required 324 new website assets, images, quizzes, infographics, audio and video clips, generated and tracked end to end by the agent team.
- PMP Exam style question drafting: I have been a volunteer PMP question writer for over 20 years, and there is quite an involved process in crafting good questions. Current frontier models (the highest-grade ChatGPT, Claude and Gemini versions) cannot reliably produce them that meet the 35 audit requirements. When asking these models why they repeatedly failed, and how to fix it, they recommended agent orchestration. So, having one agent plan the question set, another devise the scenario, another write plausible distractors, another audit against the review criteria, etc.
Using the OpenClaw environment that I described in articles 1 and 2 (with its inherent security concerns), I had it create a work management system accessible through a browser. This development was a good place to start because:
- The tools and data are hosted locally so there are fewer security concerns
- Being a project management and visualization geek, building Kanban boards, backlogs, and progress trackers is more fun than doing real work
- AI has what is known as a “Jagged Frontier,” meaning while it still struggles and makes mistakes in many fields, in other fields it excels. Coding is its strongest field.
Quickly, I had a retro-looking, Windows 95-themed, fully functional backlog tool, Kanban board, risk and impediments log, and project library.
(Main agent control team room with access to backlog, kanban board, etc)
My one main agent, who I called “Ned” spawned and oversaw a team of specialized sub-agents Cody (for coding), Viz (for visualizing and creating images), Lexi (for writing) and Verity (for fact checking and research).
(The agent team. As agents work, their avatar animates in the virtual team room view, so I can see when they are active.)
Each agent has its own Identity.md and Soul.md editable markdown files that contains its personality and inner monolog of driving behavior, a Memory.md file that preserves instructions and previous learnings. My writing agent, Lexi, maintains a detailed Writing_Style.md file with over 20 pages of writing style do’s and don’ts.
These persistent, user and machine editable files, allow the agents to get better over time. They contribute to the head, memory, and learning loops of a real agent that we covered in the robot body analogy of article 2.
Because popular web-based AI tools like ChatGPT, Claude, Gemini, etc serve millions of customers, they limit the amount of storage assigned to each user. Even “Saved Chats” and “Project” features use lossy compression and cannot be personalized as much as agents for storing information in local markdown files.
As a result of my 20+ pages of writing instructions to Lexi, finally I am getting decent results. Previously, Claude (the best writing AI tool I had found) would start reintroducing old writing issues when I had given it 20+ new style violations to remember and avoid.
The API Costs
While I was impressed with my agents’ coding and writing skills, I was not thrilled by their appetite for API tokens. Despite paying a monthly subscription for ChatGPT, Claude and Gemini, these providers (no longer) allow agents to use their services as part of these plans.
Since agents work 24/7 and self-manage multi-step workflows, early agent systems were quickly consuming a disproportionate amount of AI computing. In response, the main AI providers switched to API token billing for agents. So, your agent’s gateway, which runs on your local machine, needs to be connected to an AI service, typically on a pay-as-you-go API token basis.
One of the personal assistant use cases I described earlier was for Ned to act as a research assistant. Ned has his own Gmail account that he monitors, and if I send him an email with “Research:” in the subject line, he will go off and do the background fact checking, find counterclaims analysis, future forecast, etc. and package it all up in a nice report saved to my project library available in my team room.
This could be researching the specs of a new car and creating comparison tables, verifying a software vendor claim, or researching a topic I would like to write about. So, if someone sends me an email, or I find an article online, I just forward it to Ned to research and within an hour I have a well-rounded report on the topic.
Likewise, Ned monitors topics I am interested in on Reddit, Quora, LinkedIn, news feeds and prepares a Morning Report tailored to my interests with links to read more. This is great in theory, or when someone else is paying for the API tokens, but it adds up quite quickly.
(Agents consume AI API Tokens from AI vendors to perform work)
The email monitoring, research, and scheduled tasks all consume tokens. Agents that work while you are sleeping are cool until you realize that they are also spending your money while you are sleeping. Agents get smarter as you add more examples and instructions to their memory markdown files, but these larger files take more tokens to read and run each turn. Your agent team improves over time; they also cost you more to run as they get smarter.
The most powerful models cost more than less capable models. Also, if you don’t specify clear exit criteria for tasks, the “try another way” and “do web research and figure it out” nature that makes agents genuinely more like teammates rather than a single-try chatbot can spin, burning tokens because you accidentally asked it to do something impossible.
I tried to stick to a $100 monthly budget for token spend and only topped up balances in $20 increments to limit runaway exposure. But when I was starting and building out my toolset, I was closer to $200 and $250 in monthly spend.
This and my self-confessed cost-conscious personality led me down a rabbit hole of API cost tracking, model optimization and eventually local AI compute experimentation.
How Much Did That Cost?
Before I saw sense, I would see my daily API spend and ask Ned where all the money went? He could trace back where the tokens were spent, and we could put dollar figures against every item in the backlog we had worked on. We switched off overnight monitoring of emails since I was unlikely to be sending any, and instead he started work 1 hour before me to create my morning briefing.
As a project manager, this was quite interesting. Like tracking the burn rate for a team, I could ask agents to estimate their work effort, approve viable development, assign budgets for tasks and track progress and spend. Over-budget assignments turned red on dashboards; under-budget items are green.
(The Agent Cost Tracker dashboard, showing API token costs per backlog item)
Regular retrospectives uncovered estimation omissions, learning loops retained improvements and the agents got better at estimating. I eventually extracted myself from much of the retrospective loop and told the agents to investigate and improve their estimation, recording lessons learned in the project library. This Recursive Self Improvement (RSI) is something agents, unlike human team members, are happy to perform and very good at.
However, just like on real projects, none of this estimation and tracking was free. It all consumed API tokens in itself. These were tokens that could have been used for real work (#NoEstimates anybody?) So, I could give up my spend tracking with colour-coded graphs of infrastructure build-out vs product delivery expenditure? Or, just maybe, I could print my own API tokens?
Fueling Your Agents
Agent harnesses need to be connected to a Large Language Model (LLM) to function. This could be a paid service or a local LLM running on your own machine. The “Large” portion of an LLM needs a lot of CPU and fast memory to load and run. This has led to the global chip and memory shortages of recent years, with major cost increases.
The latest, most capable models are too large to run locally for individuals. They contain trillions of parameters, and I could not expect to run these locally, yet smaller models can still do useful work, and if I could offload this work to local AI, I could cut down on costs.
Also, this whole “Managing a Team of Agents” was in large part a hands-on course in AI for myself, so why not try running AI locally? In truth, I had three motivations.
- Avoid paying for as many API tokens as I could.
- Explore secure AI, where your documents and queries never leave your machine.
- Use cleaner energy. AI data centers use vast amounts of water and energy from a variety of clean and dirty energy sources. My home power is hydroelectric and solar.
(I realize this was more of a thought experiment than sustainability action. Buying a new machine to run on clean energy might well consume more dirty energy and precious resources than just buying tokens for an existing AI datacenter.)
However, I was tired of my agent team’s incessant API token consumption. Also, I frequently see text from my books show up in AI results, but I never consented to their ingestion nor was compensated for their use. So, I liked the idea of downloading Ollama, an open-source LLM serving tool, and trying to run AI locally. That part was quite easy; getting useful results out of it was not so easy.
The 16GB Failure: Hitting the VRAM Wall
I started where most people do, with a standard consumer desktop video card with 16GB of VRAM. In theory, 16GB sounds like plenty of horsepower. In practice for Agentic AI, it was largely useless.
To run an AI model locally at any usable speed, the entire model must fit inside the graphics card’s dedicated memory (VRAM). With only 16GB, it was severely choked. I was forced to use heavily compressed 8-billion-parameter models. While an 8B model is fine for a quick chat or summarizing a short email, it lacks the deep reasoning required for multi-step agent workflows.
When Ned tried to cross-reference a long Reddit thread, analyze future forecasts, and build a structured report using an 8B model, he completely lost the plot. The “context window”, the model’s short-term memory, would fill up instantly, causing the system to crash with an “Out of Memory” error, or overflow into my computer’s standard system RAM. The moment it overflowed, token generation speeds dropped from a brisk jog to a painful crawl of one word per second.
AI Appliances
So, I did some research (well, Ned did some research), and I found out about a relatively new class of hardware called a full-stack local AI appliance, specifically an ASUS Ascent GX10. Rather than a massive, power-hungry server rack, the GX10 condenses that same enterprise architecture into a compact, book-sized chassis designed to sit quietly on your desk.
Powered by NVIDIA’s GB10 Grace Blackwell Superchip, it delivers up to 1 petaFLOP of AI compute and has 128GB of high-speed unified memory. Because it uses a unified architecture, the CPU and the Blackwell GPU share the same physical memory pool, which is key to running large models.
The setup was much smoother than installing Linux on my Windows machine. The GX10 comes pre-loaded with an enterprise NVIDIA DGX software stack that natively supports Ollama. Within a day, I went from struggling with text fragments to running massive, very-capable 200-billion-parameter models on my desk.
A New Creative Process
Access to 128GB of memory changed capabilities, expanding my local setup far beyond basic text generation:
- Advanced Writing & Reasoning: I can now load simplified (quantized) versions of flagship models. Ned finally has the cognitive “brain size” to track complex instructions, remember his memory markdown files, and write nuanced, deeply researched reports without breaking character or forgetting the prompt.
- Local Image Creation: Instead of feeding tokens to Midjourney or DALL-E, the GX10 runs heavy Stable Diffusion and Flux pipelines locally. I can generate high-resolution images for my websites, on-theme in seconds.
- On-Device Video Generation: The large memory pool allows me to experiment with open-weights text-to-video and video-to-video models. What used to require a massive cloud server render farm now processes inside a box that draws less power than a microwave.
(One of the tracker screens Ned built and maintained, showing the 324 new 2026 ECO assets required for a website update and tracked to completion against a fixed target date.)
Best of all, the experiment successfully validated my core motivations. My relentless API token bills have plummeted to almost zero. Not that I have any secrets, but my toaster oven research projects, articles, and emails that Ned processes never leave the physical machine, giving me data sovereignty and privacy. (People often use similar hardware for setting up AI systems for legal teams and accountants where data privacy is imperative.)
Finally, as the GX10 chugs away running heavy multi-step research workflow while I sleep, I rest easy knowing its 150-watt draw is fueled entirely by solar panels and the local hydro grid. The agents are finally working for me, rather than bleeding my wallet dry. (I try to ignore the $3K purchase cost, telling myself it is a Capex expense I can depreciate against my business.)
Tooling Limitations
While my local AI-powered agents are great for most tasks, they struggle with advanced tooling. They seem very capable with long, multi-step creative processes, once I have mapped them out. They can create realistic-looking videos and produce complex WordPress plugins against large datasets with extremely low error rates.
However, updating and extending my (ever more complex) virtual team room management and agent orchestration system seems beyond them. I get too many errors; too many new feature Z breaks old feature A. Maybe I should persevere with them, but for now I still use the frontier models with their pay-per-use API for my animated team room and agent supervision system.
My spend has reduced significantly, and I can produce all the “real-work” I want without spending API tokens, but my agent viewing portal remains the domain of paid models, as shown in orange below.
(While core work is done by local AI, tooling and orchestration design remains a paid AI API service)
From AI Tool Dispatcher to Agent Orchestrator & Supervisor
In my next article, I will explain what has changed for my work style. From previously bouncing between AI tools, copying and pasting outputs and inputs, to designing agent workflows, orchestration models and supervision systems.
I am still busy, just doing different things now. It would be progress if the tools stayed still and did what they were supposed to. Yet, the agent harnesses are updated frequently, and often an update to add new functionality breaks something else and requires hours of troubleshooting.
GitHub API keys and AI token API keys expire frequently for security purposes and need to be regenerated and re-registered with your agents. Communication interfaces for email, WhatsApp or Telegram change, and how you scraped LinkedIn posts yesterday no longer works today when they change something. My agents catch most of these changes for me and just ask for approval to update their tools, but all those approvals add up. I could tell my agents to self-heal and self-manage, but then you lose control of the files they update and services they connect to, which is a security concern.
However, this is a learning experiment, a deliberate trial of these tools for project management purposefully before they are ready for prime time. Done so you can learn vicariously without the rogue agent loops and security concerns. However, when they work, they frequently show glimpses of transformative power.
“Unreliable Today, Unavoidable Tomorrow: Managing a Team of AI Agents.” That was the name of the session I mentioned last time that I had submitted for the PMI Global Summit to present on my findings.
I am pleased to announce I received the news this week that my session was accepted. So, if you are enjoying this series and attending the Global Summit this October in Detroit, be sure to come see it and say hi.
