Being a graybeard now, I see this mindset as a key to early AI adopters who are actually reaping benefits now. The corporate approach is having a strongly defined agentic orchestration process backed up by evals and strict testing and validation, but that is a lot of scaffolding around something much simpler.It is good to look at and learn from agentic orchestration, but most important to understand the purpose behind the approach. Strictly quantified evals leads to more deterministic understanding of individual prompts. It is a way to build strong building blocks which is important in a large system with lots of other contributors and moving parts. It allows incremental improvement and % success rates and all that.
On my pet projects though, I avoid agentic orchestration. I'm cheap, and most orchestration is deterministic - I start here and want to get to there. Why pay for AI to manage a known process with gates and triggers? That makes it much harder to reason through possible outcomes. It may be more flexible and powerful, but that is the "multiple camera angles" concept, where you build defensively "just in case". If I know what I want the next step to be, just do that directly. I prefer to start with a clear DAG and build on top of it, keeping AI calls narrow and compose outputs not processes.
Yes, you can go to town with agentic processes but eventually you hit the wall of understanding. If you lose the thread of what an agentic process does and how it makes decisions, you lose the ability to find shortcuts. At the root of all hacking is curiosity to know how things work. Taking things apart and manipulating the underlying system is exactly how all of these new technical advancements happen, not by following "best practices" that didn't exist 2 years ago and were built to maintain a manageable engineering department more than maximize AI value at minimal cost.