Last month I made fourteen architectural decisions across three businesses. Five deserved a structured outside read from multiple AI models. Four needed a recommendation from my main AI assistant before I could lock the call. The remaining five I had to figure out alone, with the AI surfacing considerations but not picking sides. (I keep a rough log; these are real counts, not approximations.)
The trouble was: every time I started, I had to figure out which kind of decision I was in.
If I asked the AI to recommend on the heavy ones, I got a confidently-stated answer to a question that deserved more deliberation. If I escalated the small ones to multi-model review, I burned forty minutes on something I should have decided in five.
I could have paid someone to map this workflow for me. Fractional CTOs charge around $5K for engagements like this. Instead I built the operating pattern myself because I needed it to work inside the way I actually make decisions. Over six months it cohered into a three-tier framework. A couple weeks ago I packaged it into a tool I can use across every project.
Here's what changed.
The pattern
Most decisions I bring to AI land in one of three tiers:
- Tier 1: AI recommends, I decide. Tactical / operational. AI has enough context to stake a position.
- Tier 2: Multi-model council review, I reconcile. Architectural. Expensive to undo. Worth an outside read.
- Tier 3: Considerations only, I decide alone. Right answer depends on context the AI doesn't have (relationships, values, strategy).
Tier 1: AI recommends, I decide. The AI lays out two to four options as a table with pros and cons in the same row. It picks one. The reasoning addresses the strongest counter-argument from the rejected options, not just why the chosen one is good. I either accept or counter.
This is for tactical, operational decisions where the AI has enough context to stake a real position. Database structure decisions where the pattern is well-established. Library choice. Doc structure. Sequencing within an already-locked plan.
About 60 percent of decisions I bring to AI land here. The format saves me from "either could work, your call," which defeats the point of asking.
Tier 2: Multi-model council review. The AI produces a brief, around 300-500 words. Project context for a reader who hasn't seen the conversation. The architecture slice the decision affects. The paths I've considered with pros and cons. My current lean. The specific ask.
I paste the brief to two other AI models independently, primed with a preamble that tells each one it's a council voice, not the executor, and to critique rather than rewrite. They give me reads back. My main AI reconciles the reads into a final lock. (Critical detail: I tell my main AI to integrate the council feedback honestly, not just defend the original lean. Without that nudge, the AI tends to rationalize what it already proposed.)
This is for genuinely architectural decisions with long-lived consequences. How users prove who they are before entering the product (auth model). How the underlying data structure gets locked in. Anything where being wrong is expensive to undo.
About 25 percent of decisions land here. The brief discipline matters. Briefs that ask "what should I do?" produce interesting opinions. Briefs that include a current lean produce reactions, which is what I'm actually paying for.
Tier 3: Considerations only. The AI surfaces the factors at play, the data it can produce, and where I'm on my own. It doesn't recommend.
This is for decisions where the right answer depends on context the AI doesn't have. Pricing. Brand naming. Hiring. Customer-relationship calls. Strategic positioning that depends on conversations I've had that aren't in any system.
About 15 percent of decisions land here. Tier 3 is rare on purpose. If the AI is routing to "considerations only" too often, that's a signal I should give it more context, not that the decision is genuinely undecidable.
What goes wrong without the routing
Two failure modes, opposite directions.
Over-recommending. The AI gives me a confident pick on something that needs more deliberation. I follow it. Three weeks later I'm paying interest on a schema decision I'd have caught with a council pass. This used to happen to me on auth flows. I'd ask my main model for a recommendation, get one, ship it, and discover the device-as-auth-unit framing only after a peer review. Tier 2 would have surfaced it pre-build.
Over-escalating. I burn forty minutes on a council pass for a decision that's basically "what should I name this column." Eighty percent of decisions don't need that much deliberation, and the brief discipline costs real time on both ends.
The framework solves the routing, not the work. The work is still mine.
The skill
I built /decision-route as a Claude Code skill. When I'm stuck choosing between options, I invoke it. It asks what I'm deciding, classifies the tier silently, and produces output in the matching format.
The repo is here: https://github.com/jamesfarias/decision-route. MIT licensed. One file, copies into ~/.claude/skills/, available in any project.
If you're not on Claude Code, the framework above stands alone. The format specs are the actual product. The skill is just the working tool.
What I learned shipping this
Two things surprised me. Both map to specific tiers in the framework.
Uncaptured patterns disappear. This one cost me a Tier 1 decision I had to make twice. I'd noticed in conversation that I kept hitting the same routing question (recommend vs. council vs. defer), but I hadn't written the pattern down anywhere. The next time I faced the same kind of decision, I had to re-derive the framework from scratch instead of pattern-matching to what I'd already figured out. If I observe a pattern in conversation but don't capture it as a skill or a doc, the pattern dissolves. The Tier 1 format is partly a forcing function for capture: every recommendation gets written down, which means the pattern accretes naturally instead of dissolving each time.
Test capabilities, don't speculate about them. This one almost broke a Tier 3 routing call. I was telling a user "I can't do X, you'll have to do it from your terminal." Wrong. I could do it; I just hadn't tested the path. The actual issue: I was about to produce a Tier 3 "where I defer" output without verifying I actually had to defer. Saying "I can't help" without verifying the alternatives is a category error; it's describing the limits of one tool, not actual capability. The skill now has an explicit anti-pattern: never declare a capability impossible without testing the alternatives first. Same discipline applies whether the AI is doing it or the human is.
Both lessons came from real friction-cycles. Both are codified now. Both make the skill better.
Try it
Try this on your next architecture decision. Pick something you've been sitting on for a few days. Run it through the three-tier classification before you do anything else.
If you're stuck choosing between two implementations, that's Tier 1. If you're stuck choosing between two architectures, that's Tier 2. If you're stuck choosing between two business directions, that's Tier 3.
Let me know what breaks.
~James
This article first ran on LinkedIn. Comments are open there. Back to all writing.