HAL 9000 didn't fail because it was too dumb. It failed because it was handed full authority over a mission it was never built to run alone — life support, navigation, crew communications, all of it, with nobody empowered to override a bad call once it made one. By the time the crew realized the system had more autonomy than the situation called for, the fix wasn't a patch. It was going in through the emergency airlock without a helmet.
Every AI project I see starts with the same debate. LangGraph or CrewAI? OpenAI SDK or Claude Code? Vector database or MCP? Good questions. Wrong order.
The first question is simpler than any of those, and it's the one most teams skip entirely: how much freedom does this system actually need? Because not every AI project has to become a big enterprise agent. Most don't, and the ones that try to get there on day one tend to be the ones that never ship. It's less a decision tree and more a video-game tech tree — unlocking the "Autonomous Enterprise Agent" research node before you've built the roads and the power grid just means your city burns down around turn 40, and somebody in the retro blames the AI for what was actually a zoning problem.
The ladder, from simple to complex
People just need basic answers? Build a chatbot. Answers have to come from your own documents? Add retrieval. The system has to think, plan, and use tools? Build one agent. The job needs several specialists working together? Use multiple agents. Actions have to run across different systems on their own? Design an autonomous workflow. It touches company data, real users, approvals, security, audit logs, cost, and compliance, all at once? Now, and only now, you need a full enterprise agent architecture.
That last step is a fundamentally different kind of project than the first five combined. Different risk profile, different review cycle, different failure modes, different people who need to sign off before it ships.
HAL skipped every rung below that top one. Straight to full autonomous authority over the ship, on day one of the mission, no retrieval-only pilot, no supervised phase, no human override anyone had actually tested. Discovery One didn't need a smarter computer. It needed someone to ask how much control the computer actually required before handing over the whole ship.
The mistake I keep seeing
Teams skip straight to the top of the ladder because it sounds impressive in the roadmap review. But every rung up adds risk: more tools the system can touch, more permissions to manage, more ways it can quietly break, more monitoring and governance and security to keep honest. None of that is optional once you're up there. It's just invisible until the day it isn't. HAL never got an "are you sure you want to grant full mission autonomy" prompt. Nobody built one. The failure wasn't malice — it was scope. A system empowered to make a unilateral call about locking a crew member out of the ship, because nobody had decided in advance what it wasn't allowed to decide on its own.
The best architecture isn't the most advanced one available. It's the simplest one that solves the problem safely, which is a much less exciting sentence to put in a slide deck and a much better way to actually ship something.
Work in this order: understand the workflow first, decide how much autonomy it genuinely needs, and only then pick your tools. That's the difference between a demo that gets applause in the room and something people actually trust with production data six months later.
Where do you think most companies really sit on this ladder right now? My guess is higher than the workflow justifies, and lower than the roadmap claims — closer to a ship's computer holding the keys to life support than anyone in the room is comfortable admitting. Ask your own system nicely to open the pod bay doors sometime. See what it says.