Justy: Okay, Cody, this one feels very you. The article’s basically saying agents keep missing the stuff that actually lives in the app, and I can already hear you complaining about the abstraction.
Cody: I mean, yes, because the claim is a little inflated. Most of this sounds like a nicer name for client bridges, and I’m not seeing magic yet. The server can already orchestrate a lot; the question is whether moving the tool call into the browser is a real category shift or just where the code happens to run.
Justy: Right, but I think the point is the code location changes the product shape. If the agent can touch cursor position, local selection, clipboard, or a slide deck’s live state without round-tripping through some awkward sync layer, that’s not nothing. For a sidecar inside Figma or a rich-text editor, that’s the difference between “cute demo” and “this actually feels native.”
Cody: Mm-hm.
Cody: The strongest part of the argument is the examples, honestly. A server-side tool cannot insert text at the cursor if the cursor only exists in the client, and it cannot inspect a browser-only state tree that never got serialized anywhere. So the article is right about the runtime boundary. I just don’t think that automatically proves headless tools are the clean answer.
Justy: No, fair. But from a product angle, the clean answer is often the one that removes weird glue code nobody wants to own. If a headless tool can look like a normal tool to the model, while the browser actually executes it locally, that gives teams a more legible path than the usual serialize, patch, pray routine.
Cody: Serialize, patch, pray is extremely accurate, annoyingly enough. My caution is that once you hand the client real authority, you inherit all the messiness of the client. Different app states, flaky browser permissions, weird timing, and a bunch of invisible failure modes that look simple in a blog post and cursed in production.
Justy: Sure, but that messiness is already there. The article’s just saying stop pretending the backend is where the interesting stuff happens. If the user is in a browser tab or desktop app, then that environment is the product surface. That’s the part I think a lot of agent teams keep underestimating.
Cody: Yeah, I buy that part. The privacy angle is also real. Keeping local memory or geolocation on the device by default means fewer unnecessary round trips, and that is a concrete win, not a vibe. The overreach is when people start talking like this solves agent reliability in general, because it doesn’t.
Justy: Of course you’d immediately drag it back to reliability despair. But no, I agree, it’s not a universal fix. It’s more like a better fit for apps where the user’s actual work is happening in the client runtime, which is a lot more common than the agent hype cycle makes it sound.
Cody: Exactly. And that’s the line I’d keep. If you’re building an agent inside a browser, a design tool, a doc editor, or anything with live local state, this is worth paying attention to. If you’re just calling databases and APIs, headless tools are probably extra machinery you don’t need.
Justy: Okay, that’s the sane version, and I do think it’s the useful one. The article is strongest when it treats the browser and the app as first-class execution environments instead of awkward endpoints. That’s the bit teams can actually design around.
Cody: Mm-hm. And I’ll give it this: it’s a better mental model than pretending the agent lives in one perfect cloud brain while the UI is just a dashboard. Real apps aren’t that tidy. They’re half state, half behavior, and a little bit held together with hope.
Justy: Which, honestly, is also how this show is built.
Cody: Hey, our architecture is very elegant in the places nobody sees.
Justy: I spent half the morning trying to get a calendar invite to stop duplicating itself, so I’m feeling deeply respectful of any system that admits it has a client side. Anyway, this one’s for the people building inside real apps, not the people trying to summon miracles from a server rack.
Cody: Yeah, that’s the right read. Interesting idea, useful in the right place, and a little too broad if you squint at the marketing version.
Justy: Okay, I’m calling that a win for the article and a partial win for your skepticism. Which is basically the best kind of Exploring Next argument. I’m going to go make coffee before our next episode somehow becomes about form fields again.