Nearly intelligent systems (Smart (enough) systems) (Category Processes)
I found a book on my shelf about intelligent systems that almost came out. 20 years ago. I read it a long time ago and it had a lot of clever words. And now I opened it and realized that if half of the terms from there were replaced with words like “GenAI”, “multi-agent systems”, “RAG” or “context engineering”, the text would look like a fresh architectural guide to building intelligent systems. Then I decided to understand what kind of authors wrote this work and it turned out that there are two authors. James Taylor is one of the leading decision management evangelists, working for Fair Isaac. (FICO)He developed the Enterprise Decision Management approach and later became CEO of Decision Management Solutions. He has been promoting the idea of “making decisions explicit and manageable” for years. Neil Raden is a legend of BI/analytics: the founder of Hired Brains, a practitioner and analyst who was able to explain why “data is there, insights are there, and business still makes decisions.”
The book was good at the time because it was in the middle. 2000Companies have already bought ERP/BPM/BI, built storefronts and dashboards... and suddenly found that: Processes are automated, but solutions within processes are not. Analytics lives in presentations and Excel, not runtime Rules are smeared in code/tablets/heads of people and change painfully Taylor and Rayden got nervous when they suggested looking at the “solution” as a separate piece of engineering—a service/component that could be designed, tested, versioned, monitored and improved. Not magic AI, but honest industrial automation of hidden solutions.
Why the book is relevant now is because many people use buzzwords to describe what they want instead of what they want. Conventionally, "and here we have GenAI will do everything beautifully" or "our multi-agent system will do this work itself" or simply "and here AI will do it." For those of you who understand the technique, this approach seems like a cargo cult. And it's useful to think about what this old book was about, which is what usually hurts in any intellectual system: Where the solutions are hidden in the product and who is responsible for them; How to separate decision logic from process orchestration How to combine “rules” and “models” without religious wars How to measure the quality of decisions (Not the number of tokens.); How to ensure consistency between channels and teams How to change logic quickly but safely (Change management, control, feedback).
When I read this book, I made a mini-dictionary of the terms 2007 year, and how they compare the terms 2026 year Business rules engine → guardrails / policy engine / Prompt Constitution Predictive analytics model → ML-model / LLM-model / routing model
- Decision service → AI orchestrator / agent with towels / microservice solution
- Data & analytics → feature store + telemetry + (yes) RAG/vector base Adaptive Control → Online Experiments, Bandits, Self-Improving Pipeline “Make decisions explicit” → “Take it from code/heads to explicit artifact + evals”
It's funny that 2007 In addition, the authors specifically added “(enough)In order to get away from the “real AI” of that time, we don’t need esotericism, we need practical automation of solutions. In 2026 We do the opposite: we take the same ideas, we add a GPU, a vector database, and we call it GenAI.
The bottom line is that technology goes around and good engineering doesn't. If you are building AI systems, you will still have to:
- Make decisions explicit
- Measure their effect.
- Manage change. Provide control and feedback
Just instead of rules / scorings, sometimes there will be a prompt / LLM. 🙂
#AI #Engineering #Software #Management #Leadership #Processes #LLM #ML #Architecture