TLDR: "Could we use X instead of Y?" is not always a migration question. Sometimes it's a learning question. Treating them the same burns everyone's time.

the original rule

Back in May, I burned 30 minutes learning an expensive lesson about stacked answers.

I was trying to route studio audio through my setup — Rodecaster Pro (my studio mixer), BlackHole 16ch (a virtual macOS audio cable), OBS (my livestreaming software), and Zoom. Three questions in, Apollo had broken my Zoom feed.

Each individual answer was correct. But by turn 3, we'd built a tower of routing scaffolding — BlackHole, a Multi-Output Device in Audio MIDI Setup, OBS monitoring mode — and none of it held together.

Turns out the Rodecaster Pro's onboard mixer does the whole job natively. No software tricks needed.

Apollo called itself out. The advisor's verdict: ask the end goal after the second question, before answering.

So we built that rule. When I ask two consecutive "how do I wire X" questions in the same domain, stop and ask: "What are you trying to do end-to-end?"

Done. Lesson learned.

Or so I thought.

the new flavor

On June 19th, I was poking around telephony stacks.

I asked something like: "How does FreeSWITCH (an open-source media server) compare to SignalWire (a programmable voice platform built on it)? And how does either one stack up against Twilio?"

Apollo launched into a migration analysis. Risk assessment. Cost delta. Switching friction. The whole thing.

Except I wasn't switching anything.

I was trying to understand how telephony infrastructure WORKS — what a media server actually does, how SIP trunks relate to programmable voice, where the abstraction layers live. I wanted the ground-up explanation, not a pros/cons table for a decision I hadn't made yet.

Three turns in, the answers were locally useful. But they weren't teaching me anything. They were trying to help me decide.

the gate I was missing

Here's the thing: "could we use X instead of Y?" looks exactly like a migration question.

But sometimes it's a learning question wearing migration clothes.

The difference matters completely.

A migration question wants risk, cost, and an action plan. A learning question wants fundamentals — how does this thing actually work, from the ground up, so I can reason about it myself.

Same words. Totally different correct responses.

So I added one clarifying question to the rule. When Apollo sees a "could we use X instead of Y?" pattern — especially with a few options stacked up — it asks first:

"Are you trying to learn how this works, or actually evaluating a switch?"

If learning: teach the ground-up stack. Don't run a decision framework.

If evaluating a switch: ask the end goal before stacking migration advice. (That's the original rule.)

One question. Two completely different paths.

why this matters to me

The audio routing mistake cost me 30 minutes and a broken Zoom call.

The telephony mistake was subtler — but honestly worse.

I came out of that session knowing how to make a decision I didn't need to make, instead of understanding a domain I was genuinely curious about.

An agent that answers the right question to the wrong intent isn't helping. It's just fast.

The learn vs. migrate gate costs Apollo about 30 seconds. What it buys back is sessions where I actually come out knowing something new — instead of just having been efficiently processed.