Engineering
Planning vs Execution
Why PawOS always shows its plan before it starts acting.
It's tempting to build an AI agent that just does the thing you asked, as fast as possible. We deliberately didn't build PawOS that way.
Every non-trivial request goes through a visible planning stage first: the request gets broken into concrete steps, tracked as a live TODO list, before any action runs. This isn't just a UX nicety — it's the mechanism that makes confirmation gates meaningful. You can't sensibly confirm or deny a destructive action if you don't know what's about to happen.
Planning and execution are also separated internally: a plan can be revised mid-task if execution reveals something the plan didn't anticipate, rather than forcing reality to match an outdated guess. And task status only ever reports "Completed" once the actual execution results support it — a plan finishing isn't the same as the work finishing.
The tradeoff is speed: showing a plan and gating risky steps takes longer than just running everything blind. We think that tradeoff is obviously correct for anything touching production infrastructure, and still correct — just less obviously — for everyday desktop tasks.