
How Should You Route Requests Across Multiple AI Models?
When an AI system uses several models, should requests be assigned by explicit rules, predictive routing, cascades, or fallback paths?
I write about how businesses can use AI, software, data, and process redesign to create measurable value — starting with the business problem, not the technology.
I've been building software with a range of programming languages and technologies since 1998, designing reliable, scalable system architectures.
My perspective spans writing code, leading technology teams, and working hands-on across sales, marketing, and field operations.
I care less about what AI can do in theory than which processes and outcomes it can improve in a real business.
Yes, I work on technical problems too. But I don't write about technical subjects for technology's sake. I write about the business problems AI, software, automation, data and process design solve in a real business—and what they change. The question at the top of my agenda lately is this: How does a company move from using AI simply to ask questions and get answers to integrating it into its processes, decisions and, when necessary, its business model?
The pieces below are ordered from newest to oldest. If the first few feel too basic or too technical, keep exploring, because in each piece we look for answers to questions at different depths. Whether the intelligence is artificial or human, the question we need to answer is this: How can we do our work better—with higher quality, greater efficiency, more innovation and greater professionalism—and create more value?
Recent writing on AI, software, and business.

When an AI system uses several models, should requests be assigned by explicit rules, predictive routing, cascades, or fallback paths?

PeşinTaksit was a neglected side project that still required four containers. With AI, I moved it to Cloudflare Workers in about an hour.

When should an AI system begin with one model, and what improvement in quality, cost, speed, or risk would justify adding another?












Hands-on notes and tutorials on Go, Linux, Docker, web fundamentals, and more—with new technical writing added as I publish it.








What matters is not the model, but the decision, workflow, or economics it changes.
Explore AI writing →02Processes, handoffs, information, and decisions are where operational friction becomes visible.
Explore business writing →03Architecture, infrastructure, and implementation determine whether an idea becomes dependable.
Explore engineering writing →I first try to understand what needs to change. I choose the technology only after the problem, expected benefit, and cost are clear.
What should improve: cost, speed, capacity, quality, or revenue?
How does the work happen today, and where are time, money, or knowledge being lost?
Even if I do not act today, I consider likely scenarios. A small preparation now can prevent far more work later.
Which change is most likely to produce a meaningful result?
Is the expected gain worth the cost, effort, and risk?
What should be removed or changed before anything is automated?
Would AI, software, an existing product, or a process change be the best fit?
Put the change into practice and measure what actually improves.
Short accounts from systems built in the real world, with the details that made them useful.
A real-time decision-support and sales-management platform for routing, payments, and management visibility.
Read →What emerged from building and operating a chat system for patients across channels.
Read →A modern open-source infrastructure assembled with a small server and Cloudflare.
Read →This site is where I share notes on AI, software, the products I build, and the problems I encounter at work.