What Jarvis actually gets wrong (and why I'm not fixing it yet)

Personal · 2026-08-14

I sat down to write something useful about Jarvis this week, and my first instinct was to write about all the things it's brilliant at. Because it is, genuinely, brilliant at some stuff. But that felt like marketing, and this blog isn't really the place for that, so instead I want to talk about where it falls over. Feels more honest. More useful too, probably.

Quick context: Jarvis is the voice on the front of my fleet of Claude agents. I talk, it works out what I want, and either does it or hands it to the agent that owns it. Most of the time that works. But there's a specific failure mode I keep hitting, and I think it's worth talking about because it says something about building tools for real work rather than demo work.

Here's the thing: Jarvis is great when the task is bounded. Clear input, clear output, done. Where it struggles is judgment calls. Is this a new task or one I already gave it? Did I mean all five of those, or just the first one? Is the job actually finished?

A real example. When I ask Jarvis to get Claude to do something, two things happen. The job goes into a queue for a Claude Code session to pick up, and the same words get captured as a to-do. When the job got done, only the queue side was closed. The to-do stayed open. So a few days later the list still said the work was outstanding, and I'd ask for it again. I found three of those phantoms sitting there at once. Nothing crashed. Nothing errored. It just quietly believed two different things.

That's not a bug exactly. It's pattern matching doing its best without the one piece of context that mattered. And I think a lot of people building with AI hit this same wall and don't talk about it, because admitting your system has a ceiling feels like admitting weakness. I don't think it is. I think it's just true.

Anyway, the fix isn't more automation. That's the bit I keep having to remind myself of. My first reaction, every time, is to write another instruction into the prompt. Be careful with duplicates. Double check before you say it's saved. But a prompt is a suggestion, and the model follows it until it doesn't. What's actually worked is taking the decision away from it.

So the rule now is reversibility, not confidence. Can I undo this in one step? Then Jarvis just does it and tells me, and "undo that" puts it back. Moving a few items between lists, asking an agent to go and look something up, fine, no questions. Anything that writes code gets a hard gate: if the change touches secrets, the database, dependencies or the deploy pipeline, it stops and asks me. And closing a queued job now closes the to-do it created in the same step, in code, not because the model remembered to.

There's a trade-off there and I want to be upfront about it. It means Jarvis is less impressive in a demo. It asks me things a slicker assistant would guess. When someone asks "can it just handle X", the honest answer is sometimes no, it'll ask first. That's a hard thing to say when you're excited about what you're building. But the alternative, a tool that confidently gets things wrong, is worse. I'd rather it asked.

I guess the bigger lesson, if there is one, is that the interesting problems in building this stuff aren't really technical. They're about deciding what you're comfortable being wrong about, and making sure the system can't be wrong about the rest. Jarvis will get better at judgment calls eventually. Probably. For now I'd rather it knows what it doesn't know, and hands that bit back to me.

Feels like a small thing to admit in a blog post. But I think it's the whole game, honestly.