Most AI Agents Aren't Actually Agents

Most AI Agents Aren't Actually Agents

Everyone's building "AI agents" right now. The timeline is full of them. Companies are raising millions to ship them. The problem? Most of them aren't actually agents. They're chatbots with API access. That's it. What People Call Agents Here's the pattern I see everywhere:User types a message LLM decides which function to call Function returns some data LLM formats a response DoneThat's not agency. That's function calling with a conversational wrapper. The LLM picks a tool, the tool runs, the result comes back. If it works, great. If it breaks, the conversation dies. If the user needs three things done in sequence, they're manually prompting through each step. This is useful. It's even impressive sometimes. But it's not an agent. What Real Agents Need Real agentic systems operate with autonomy. They handle the messy parts without constant human supervision. That means: Error recovery. When something breaks (and it will), the agent doesn't just apologize and give up. It retries with backoff. It falls back to alternative approaches. It routes around failures without making the user debug what went wrong. State management. The agent needs to remember what it's doing across multiple tool calls. Not just "what did the user ask for?" but "what have I tried, what worked, what's left to do, and what's blocking me right now?" Retry logic. APIs timeout. Rate limits hit. Sometimes data isn't ready yet. A real agent knows when to try again, when to wait, and when to give up. Supervision and checkpointing. For multi-step work, the agent should be able to pause, show you what it's done so far, and resume if something goes sideways. You don't want it to redo 20 steps because step 21 failed. Context persistence. If the system restarts, the agent should be able to pick up where it left off. Not "sorry, you'll need to start over." Graceful degradation. When a preferred tool is unavailable, the agent should try another approach. When data is incomplete, it should work with what it has or ask for the missing pieces. This is infrastructure work. It's not fun. It's not what people demo. But without it, you don't have an agent. You have a chatbot that calls APIs. The Infrastructure Problem The hard part of building agents isn't the LLM. That's the easy part. The hard part is everything around it. You need a task queue that can handle retries. You need a way to checkpoint progress so work doesn't get lost. You need monitoring so you know when an agent is stuck. You need logging so you can debug failures after the fact. You need to handle rate limits from every API your agent touches. You need to deal with inconsistent error responses. You need to decide what to do when a tool returns malformed data or no data at all. You need a way to supervise long-running workflows. You need to surface status updates without spamming the user. You need to decide when to ask for help and when to keep trying. None of this is LLM work. It's systems engineering. What I'm Seeing in Practice I build agents daily. The pattern is always the same. I spend 10% of my time writing prompts and configuring LLM calls. I spend 90% of my time on infrastructure:Handling tool failures Managing state across multiple turns Implementing retry logic Building supervision layers Writing recovery flows for when things go wrongThe prompt is never the problem. The problem is making the system robust enough to actually finish the job. When I look at "AI agent" demos online, I see polished function calling. I don't see error handling. I don't see state management. I don't see retry logic. That's fine for demos. It's not fine for production. The Real Opportunity If most "AI agents" are just chatbots with API access, there's a huge opportunity for anyone willing to build the infrastructure. The companies that win won't be the ones with the best prompts. They'll be the ones with the most resilient execution layers. They'll build systems that:Recover from failures without human intervention Maintain state across sessions and restarts Coordinate multi-step workflows reliably Degrade gracefully when things break Surface meaningful status without overwhelming usersThis is less glamorous than training models or writing clever prompts. But it's what separates working agents from chatbots. LinksOpenClaw - agent infrastructure I'm actively building with LangGraph documentation - one approach to stateful agent workflows Modal - infrastructure for long-running agent workloadsBuilding agents that actually work means caring more about the infrastructure than the LLM. The wrapper matters more than the model. Most people aren't ready for that conversation yet.

The Best Tools I Use Aren't AI Tools

The Best Tools I Use Aren't AI Tools

I spend a lot of time in AI tools. It's part of my job. But the truth is, most of my actual work happens in tools that have nothing to do with AI. The Boring Stack Here's what I use every single day: VSCode for writing. Google Sheets for tracking. Git for version control. Terminal for everything else. No AI. No fancy automation. Just basic tools that do one thing well. When I need to draft something, I open VSCode. When I need to track data, I open Sheets. When something breaks, I check Git. AI tools are great for specific tasks. Claude helps me think through problems. ChatGPT speeds up research. But they're supplements, not replacements. Why Basic Tools Win They're fast. They're reliable. They don't break when the API goes down. They don't require a monthly subscription or a complex setup. They just work. Most work still needs basic infrastructure. You still need a place to write. You still need a way to organize data. You still need version control. AI can help with some of those tasks. But it can't replace the fundamental infrastructure. The AI Hype Problem Everyone wants to talk about AI workflows and AI-first companies. But the reality is that most work still happens in text editors and spreadsheets. If you're building something, don't assume AI will solve everything. Start with the basic tools that work. Add AI where it actually helps. If you're choosing tools, prioritize reliability over novelty. The boring stack exists for a reason. The Bottom Line AI is useful. But it's not the foundation. The foundation is still text files, spreadsheets, and version control. Build on that. Everything else is optional. For more thoughts on building with practical tools, check out my other posts. And if you're looking for workflow automation that actually works, take a look at Process Street.

The Money Is in the Boring Problems

The Money Is in the Boring Problems

The Money Is in the Boring Problems I spent this week building SafeRounds, a free restaurant temperature logging tool. It's not going to get me on Product Hunt's front page. Nobody's going to write a thinkpiece about it. It doesn't use the latest LLM to generate anything. It's just a simple web form where restaurant staff can log fridge temps, freezer temps, and hot hold temps twice a day. That's it. But here's the thing: restaurant owners actually need this. Health inspectors require it. Failing to maintain proper logs can shut you down. And right now, most restaurants are either using paper clipboards (that get lost) or clunky spreadsheets that don't enforce the rules. I see so many people building with AI chasing interesting problems. Translation tools. Creative writing assistants. Novel interfaces for information retrieval. All cool. All technically impressive. But when I look at what actually converts, it's the boring stuff. The compliance checklists. The required documentation. The forms you have to fill out to stay legal. Why? Because these aren't nice-to-haves. They're must-haves. You don't shop around for temperature logs because you're excited about innovation. You need them because the alternative is failing your health inspection. That's a different kind of market. Lower browse time. Higher intent. Immediate utility. And the boring niches are still wide open. Nobody's racing to build better HACCP documentation tools. There's no VC-funded startup disrupting restaurant compliance logs. It's not sexy enough. Which means if you actually solve the problem well, you win by default. I'm planning to build a few more of these. Not because they'll get me followers. Because they'll solve real problems for real businesses. And that compounds differently than viral content. The next one is LogChef — a recipe costing calculator for commercial kitchens. Also boring. Also needed. If you're building something right now, consider this: what's the most boring version of your idea that someone would actually pay for? Start there. Learn more about building small useful tools on my blog, or check out Process Street's approach to workflow automation.

AI Doesn't Replace Process, It Makes Bad Process Fail Faster

AI Doesn't Replace Process, It Makes Bad Process Fail Faster

I've spent this week deep in compliance tools. Not the sexy kind. Temperature logs. Checklists. Daily operational stuff. The kind of work most people ignore until something breaks. And that's exactly why it has been useful. Working on these tools keeps forcing the same lesson back into my face: AI does not replace process. It makes bad process fail faster. That sounds negative, but I don't mean it as a dunk on AI. I'm bullish on AI. I use agents every day. I think the upside is real and probably bigger than most people think. But the pattern is pretty clear. If your workflow is fuzzy, AI doesn't magically make it solid. It just lets you execute the fuzzy thing at higher speed. If your handoffs are sloppy, you get sloppier handoffs faster. If your checks are weak, you get confident-looking mistakes at scale. And if your process is actually good, AI becomes a multiplier. That's why I keep getting pulled toward compliance and operations work. These are not trendy categories. Nobody is bragging at dinner about fridge temperature logs. But they are full of repeated decisions, recurring checks, and boring little failure points that cost real money when they get missed. That is prime territory for AI and automation. Not because the problem is glamorous. Because the structure is already there. In a good workflow, the steps are known. The order matters. The exceptions matter. The audit trail matters. A person can do it. A system can verify it. Then AI can slot in and help with the parts that benefit from speed, judgment, or synthesis. That is a way better setup than asking a model to improvise your business from scratch. I think a lot of the hype misses this. People want AI to be the whole system. Most of the time it works better as a layer inside a system. That's one reason I still think workflow software matters so much. If you care about reliable execution, you need the underlying process to be explicit. You need steps. Ownership. Rules. Triggers. A record of what happened. That is what tools like Process Street are good at. The funny part is this sounds less exciting than "AI will replace work." But in practice it's more useful. The real win is not replacing all human effort with one magic model. The real win is taking a messy recurring task, making the path explicit, then using AI to remove friction from the parts that should not require so much human attention. That's also why I like building in boring niches. The constraints are clearer. The customer pain is more concrete. And the difference between a good workflow and a bad one shows up fast. I wrote earlier about why I started writing online. Part of it is this: I want to document what actually holds up when you stop talking in abstractions and start building real things. McKinsey has been beating this drum from the enterprise angle for a while. Their point is basically that companies get more value from AI when they redesign workflows around it instead of sprinkling AI on top of broken operations. That's not hype. That's just how implementation works. You can read one example of that argument in their report on the state of AI. So yeah, I'm still excited about AI. I just trust it more when the boring workflow stuff is handled first. That is where the leverage is.

Why I Switched to Astro

Why I Switched to Astro

I migrated my personal blog from Next.js to Astro yesterday. The whole thing took about three hours. Setup, content migration, design customization, deployment. Done. That speed surprised me. Framework migrations are supposed to be painful. This one wasn't. The Problem with Next.js for a Blog Next.js is a great framework. I'd use it again for a web app. But for a blog, it was overkill. Every time I wanted to write a post, I was editing a TypeScript file, adding an entry to an array in a library module, making sure the build config was happy. For what? To show someone some paragraphs of text. It felt like driving a semi truck to the grocery store. Technically works. Completely unnecessary. The other issue was JavaScript. Next.js ships a JavaScript bundle to the browser even for pages that don't need interactivity. My blog posts are static text and images. There's no reason to download and parse a React runtime just to read an article. Why Astro Astro is built specifically for content-heavy sites. Blogs, docs, marketing pages. The kind of sites where most of the content is just text. The key difference: Astro ships zero JavaScript by default. Your pages are static HTML. If you need interactivity on part of a page, you can add a React or Svelte component and only that component gets JavaScript. Astro calls this "islands architecture." The rest of the page stays static. For a blog, this is exactly right. My posts don't need JavaScript. My compliance tools do, and Astro handles both cases cleanly. What the Migration Looked Like The content model is what sold me. Blog posts in Astro are markdown files in a folder. Each file has some frontmatter at the top for the title, date, tags, and image. That's it. Compare that to my Next.js setup where posts lived in a TypeScript array inside a library file. Going from that to plain markdown felt like going from enterprise software to a notebook. Here's what three hours got me:Repo setup with the Bookworm Light theme All existing posts migrated to markdown files Design customized to match my style Deployed to Vercel with auto-deploy from GitHub Build time under 10 secondsThe deploy setup is dead simple. Push to GitHub. Vercel picks it up. Site is live. I added a three-line vercel.json and it worked on the first try. What I'd Tell Someone Considering It If your site is primarily content, text and images, Astro is probably the best framework available right now. It's fast, the developer experience is clean, and the ecosystem has matured a lot. If you're building a SaaS dashboard or something with heavy interactivity, stick with Next.js or SvelteKit. That's not what Astro is for. The honest truth is that most personal blogs and marketing sites don't need a full React framework. They need fast HTML delivery and a simple way to manage content. Astro does exactly that. According to recent framework comparisons, Astro consistently delivers stronger Core Web Vitals and Lighthouse scores for content sites. That matches my experience. My site loads instantly now. The Takeaway Sometimes the best upgrade is removing complexity, not adding it. My site is faster, my workflow is simpler, and writing a new post is now just creating a markdown file. That's worth three hours.