Skip to content
Computer for AI Agents: What to Check Before You Buy artwork

Computer for AI Agents: What to Check Before You Buy

AI News & Strategy Daily with Nate B. Jones

October 20, 2026

Before buying a bigger computer for AI agents, find out what is consuming the machine you already have. Nate explains how to diagnose memory and storage pressure, give agents a stopping condition, and schedule demanding work around the resources available.

Speakers Nate B. Jones

TopicsBusinessTechnology

Nate B. Jones (0:00)

I'm just gonna say it, you're not the only user of your computer anymore. If you run agents all day, they're probably using it more than you are. Now, I know what you're thinking, my Mac's getting old, I need a bigger one. You might also be watching because you're pricing a Mac Mini, or a Mac Studio, or maybe there's an NVIDIA machine you're comparing. Here's the problem, a faster chip and more memory will not stop the agent load that you're driving from growing and growing and growing. Your agents open browsers, they start service, they write files, they leave a lot of it behind on the machine when the job is done.

Basically, you have a messy roommate, and nobody set the house rules, so we have to set them together here. Let's do it. And don't worry, I wrote those roommate house rules down for you. There's a guide on Subzac that goes with this video with three prompts you can hand straight to your agent. One to find what is eating your machine, one to clean up only what you approve, and one to design a really regular checkup so that your memory load and all of the stuff that makes your computer slow doesn't creep back. The link is in the description below, and if you're connected to Nate's MCP, your agent can actually just pull those prompts right now, straight from the library and get to work. You don't even have to go to the Subzac, you can just hit the MCP. So by the end of this video, you're going to know which computer fits your agent workloads, how to get more useful work from the machine that you have on your desk right now, and how to make sure that your agent-human setup, your roommate arrangements are reliable as you add more agent jobs. There are going to be four principles I use to connect these decisions. Let's start off with a doctor check up on your Mac. If you're on your Mac and you open up Activity Monitor and you click Memory, you can actually literally see the memory pressure graph while the work you care about is running with agents. And it comes in colors, right? Green means it's doing okay, yellow and red mean the machine is struggling. Mine are often in yellow and red, to be honest. Look at which applications are using memory. A high number in the RAM used bar doesn't tell you you need another computer per se, but it sure does tell you you need to look at your system.

Then, if you're still doing your checkup, look at storage next. Look at system settings, general and storage, and RAM is the working space for what you're doing. So storage is going to hold your files, it's going to hold your software. Mac OS can use storage for swap memory, which temporarily holds memory contents, like a credit card hold, so the two don't get in the way. But fundamentally, you need to think about how you allocate that memory so that you are not essentially trying to build on top of a bunch of agent holds across a bunch of harnesses. And that's one of the things I see, like when you have cloud in Chrome, and you have a bunch of working memory in another browser, I use Zen, when you have a bunch of working memory in Codex, and a bunch in Cloud, and then you have another AI tool, maybe it's a transcription tool, all of it adds up, it's memory pressure. Now, this is something the labs have paid attention to. Tebow at OpenAI recently shipped a Codex improvement that reduces how much memory Codex uses. That's definitely been a problem. But these point fixes from the labs are not enough, especially if, like most of us, you're running multiple harnesses. I know a lot of folks in the community here are running local models like Quen, they're running models like Cloud, they're running Codex.

We have to have a system that works with all of them. And that's what this is about. This brings us to the first principle. You got to know where the work happens. Suppose you ask OpenAI's Codex or Anthropix's Cloud Code to build a little website for you. Very typical ask, right? The model might be answering from a data center, but that doesn't mean there's not pressure on your system. Your computer is still running the development server, the browser that checks the website, the build tools, all of that is local, and you feel it, right? If you give another agent a different project at the same time, it's going to start from a different set of tools and it's all going to hit your local compute. I felt this when I was using Claude to build Blender videos at the same time as I was having my codecs do other work. Like it just chews on your memory. And so if you're getting memory warnings, include the local tools you have in your diagnosis and expect local tools to be your principal path to resolution. It doesn't mean you have to stop your agent work. We're not saying that, but you have to think about how you do it and you have to get into the details. You want to make sure that you're not just buying a graphics card you think will be a point solution to this problem. As I keep saying, you can buy your way into more capacity, but you can't buy your way out of the problem because agents are going to keep getting more capable. So bottom line, treat the memory problem as local and something you have to resolve with your agents before you add more. If you're running a model locally, you have to think through the compute requirements for that model. And if you're running a mix setup, which I think in practice a lot of people are, you have to understand by looking at the settings I just described, what is hitting your memory from a particular application? When is Quen hitting your memory locally versus when are Codex and Cloud hitting your memory? You should be able to see that. Let's go back to our website story. Imagine the agent finishes the website and you move along, but the development server and the browser, they're still open in the background. What people don't realize is your human attention has moved on, but those tools are still using passive resources. They still have that credit card hold on your memory. The project has dependencies, it has build files taking up your storage.

22 more minutes of transcript below

Thousands of transcripts fetched by people building searchable podcast archives

Fetch the whole transcript

The demo key returns a sample episode in full, no card needed:

request
curl -H "x-api-key: pt_demo" \
  https://spoken.md/transcripts/1000651996090

Markdown with the speakers named, for your notes, your knowledge base, or anything that makes HTTP calls.

From $0.10 per transcript. No subscription. Credits never expire. Prices exclude VAT, added at checkout for EU customers. Not what you expected? Email us within 14 days with 20 or fewer credits used and we refund the pack in full.

Using your own key:

request
curl -H "x-api-key: YOUR_KEY" \
  https://spoken.md/transcripts/1000797293772