PRODUCT 7 min read

Inside MAIFlow's scoring engine

When we started building MAIFlow, the temptation was obvious: run every task through a language model, ask it to output a priority number, and call it done. We tried this early on. It failed in an interesting way — the scores were plausible, but not explainable, and operators stopped trusting a system they couldn't reason about.

The version that shipped is a layered model instead. Urgency, dependency depth, blast radius, and staleness are each computed as their own signal, using a mix of deterministic rules and lightweight classifiers. Only the aggregation step uses a learned weighting, and every score in the interface can be expanded to show the components behind it.

This matters more than it sounds. In operational software, being wrong occasionally is tolerable. Being unexplainable is not — it erodes trust faster than any single bad recommendation. So the scoring engine is designed to be interrogated, not just obeyed. See our deeper walkthrough of each signal for more detail.

The result is a sort order that feels obvious in hindsight, which is exactly the point. Good prioritization shouldn't feel like magic. It should feel like the software finally agrees with what you already suspected.

More from the Log

  • MAIFlow's Score Engine, Explained

    A plain-language walkthrough of how MAIFlow turns urgency, impact, blockers, and staleness into the single number that decides what shows up at the top of your queue.

  • Applied AI is not a chatbot

    Chat interfaces are the easiest way to ship AI, and often the wrong one. Here's how we think about where a model belongs in a workflow.