← All IntelClip / AI AgentsMCP access is not understanding: the naive-run postmortem
From Stop babysitting your agents... — Brandon Waselnuk, Unblocked · ≈4:52
A head-to-head run where the MCP-only agent passed every code check yet produced a change that would have broken production — the clearest argument that tool access alone is not context.
What’s in it
- A head-to-head run where the MCP-only agent passed every code check yet produced a change that would have broken production — the clearest argument that tool access alone is not context.
Clip transcript
Though Mythos sounds pretty cool. Um, so the problem is people think that access is the answer, but it is not understanding. So, providing your agent tools with MCPs, with pipes to different sets, allows it to access that, but you have to remember you day one when you showed up at work, you don't know where things are, and you definitely don't know what you don't know. So, there's probably some service over there you've never heard of before in your life. You're working on a thing. Your agent's like, "Ah, I did it. I wrote the whole code from scratch." And then your senior engineer is like, "Hey, bro. We have a service." And denies you. So, one thing you'll see is we actually triggered this task, that's a real prompt. You'll see data later in this slide about the outcomes. We did it with Unblocked, a context engine, and then without one, but it had an MCP access to each SaaS tool that was required to get the job done. And I'll show you the differences. The short story is you kind of get this. The naive run, which just had the MCP access, basically passed all the code checks. It compiled. But the senior engineer was like, this is totally wrong and what it tried to do would have broken our entire system if we had shipped it.
Comments
Checking sign-in…
Loading comments…