You hand a long refactor to an agent, and somewhere in the middle a stray question pops into your head. "What does this error message actually mean?" "Which version of that library is current again?" As an indie developer juggling several projects at once, these tangents surface many times a day. For a long time my reflex was to just type the question into the same conversation, and the agent that had been steadily working would suddenly veer off course, the context it had built up quietly thinning out. I made that mistake more times than I'd like to admit.
The /btw slash command added in Antigravity 2.1.4 (released June 11) addresses this "by the way" problem head-on. A side question you toss mid-conversation gets handed not to your main agent but to a disposable subagent. Here are the things I noticed after actually folding it into my workflow.
Why side questions drag down your main agent's accuracy
An agent's response quality depends heavily on the context that has accumulated in its conversation. During a long task like a refactor, the agent is holding the structure of the target files, the history of changes so far, and any course corrections you gave along the way—all as working context.
Drop an unrelated question into that, and two things go wrong. The first is attention drift: when the last few turns are filled with a tangent, the agent tends to get pulled toward "what was just asked" over "what it was actually doing" on its next step. The second is context dilution: the more unrelated exchanges crowd into a finite window, the lower the density of the information that matters for the real task. Why this hits hardest in large codebases is something I covered in managing Antigravity's context window in large codebases.
My old workaround was "open a new tab and ask in a separate session." It works, but switching tabs and spinning up a fresh session is just enough friction that I'd often cut the corner and type into the current conversation anyway. /btw turns that corner-cutting into something safe.
What /btw actually does
Type /btw in the input box followed by your question, and the question never lands in the main agent's history—it's sent to an independent, disposable subagent instead. The subagent answers on its own and is discarded once it's done. Because the side exchange never piles up in the main conversation, your primary context stays intact.
# While the main agent is in the middle of a refactor
/btw what situation produces this TypeError: Cannot read properties of undefined?
The key point is that once you've got your answer and return to the main agent, the main agent doesn't know about the side question. So if you want the answer to feed back into the real work, you have to relay the insight to the main agent explicitly, in your own words. I see this not as a flaw but as the intended separation—it lets you decide what's worth carrying back into the main thread.
Where it fits, and where it doesn't
After a few days of using it, the questions that suit /btw and the ones that don't split cleanly.
It fits lookups that resolve in one shot and don't directly affect the main work: the general meaning of an error, a command flag, a terminology check, a library overview. For anything I just want to know, the disposable subagent is plenty. I use it the way you'd step out to grab a note.
It does not fit questions whose answer should shape the main work's direction. Something like "should this function I'm fixing be redesigned entirely?" only gets a meaningful answer when the main agent's context is present—why the design is the way it is, what's already been changed. Throw that at a context-free disposable subagent and you'll get generic advice that can actively mislead you. Those belong in the main conversation.
As a rule of thumb, I ask myself: "Do I want the main agent to know this answer?" If yes, ask in the main thread; if no, use /btw. That simple line keeps me from second-guessing.
How it differs from parallel agents
Antigravity 2.0 and later let you run multiple agents in parallel, but /btw serves a different purpose. Parallel agents are for "advancing several independent jobs at once," each carrying its own context and running continuously. /btw, by contrast, is a lightweight way to "duck into a one-off tangent without stopping the single job that's already running."
There's a quota difference too. Adding standing parallel agents means you have to think about how your usage budget gets consumed (I wrote that up in budgeting quota so parallel agents in Antigravity 2.0 don't run you dry), whereas /btw completes in a single shot, so the operational weight is in a totally different league. "Work I want running constantly" → parallel agents; "something I want to ask just for a moment" → /btw. Framing it that way removes the guesswork.
Make it a small habit
Features like this go unused if you merely know they exist. I deliberately built in a beat: "When I'm about to type a side question into the main conversation, first consider whether I can prefix it with /btw." I forgot the first few times, but after one experience of redoing work because a side question muddied the main context, my hands started reaching for /btw on their own.
The more time you spend handing long jobs to an agent, the more it's worth protecting the "purity" of that conversation. /btw isn't a flashy feature, but it's a quiet, dependable tool for running a single task to completion with full focus. If you've been wrestling with tangents derailing your long-running tasks, I hope this helps.