Most AI tools have a context problem, and it's not the one everyone talks about.The model knows your codebase. It knows your repo structure, your conventions, your last fifty commits. What it doesn't know is that the actual conversation about the bug is happening in a Slack thread, three replies deep, between a PM and a backend engineer who hasn't opened the IDE yet today.So you sit there, watching the thread, and at some point you do the thing. You copy the error message. You alt-tab to VS Code. You paste it into the chat. You explain to the model what the PM just said, because the model wasn't there. Then you alt-tab back and paste the answer into Slack. Maybe you reformat it.This is the friction nobody puts in the demo videos. The model is smart. The IDE is fast. The tools work. The problem is that you're acting as a bridge between two worlds that should be talking directly.Friction you stop noticing\ \There's a category of friction in dev tools that you stop being able to see after a while. It's not the loud stuff, like a slow test suite or a broken pipeline. It's the small, structural cost of moving between contexts.You feel it when you read a question in Slack and your brain has to decide whether it's worth the context switch to answer it properly. You feel it when you triage a bug from a thread and have to manually reconstruct what was already said in your prompt. You feel it when a teammate flags something, you say "I'll take a look," and then the look itself takes ten minutes of setup before you've even started thinking.If the AI lives only in the IDE or CLI, and the work starts somewhere else, then every interaction begins with you doing the unpaid labor of translation.The shape of a tool that meets you where you are\ \Kilo for Slack is a Slack bot you mention with @Kilo. That's the whole interface. You don't install anything new on your local machine. You don't open a new tab. You don't paste anything anywhere it wasn't already going.When you mention @Kilo in a thread, it reads the whole conversation, has access to your connected repos through your GitHub or GitLab integration, and either answers the question or spins up a Cloud Agent to actually do the work. If the work involves code, it creates a branch, pushes commits, and opens a pull request. You go back to whatever you were doing.Here's the thing that's easy to miss: this isn't a new product surface. It's the same Kilo. Same credits across all interfaces. Same 500+ models you can switch between in the integration settings. Same agentic infrastructure that runs Kilo from the IDE or the CLI. The bot is a way of getting work to the agent without making you go pick the agent up first.That distinction matters. A lot of "AI in Slack" integrations are actually a different product wearing a Slack costume. A separate context, a separate memory, a separate model selection, a separate billing line. You end up maintaining two AI tools that don't know about each other, which is a worse problem than the one you started with.What good "low friction" actually looks like\ \It's tempting to define low friction as "fewer clicks." That's not quite right. You can get to zero clicks and still have a bad tool, because clicks are not the unit of friction. The unit is decisions.Every interaction with a tool forces you to make a small set of decisions. Which interface do I use? Where do I paste this? Is this worth the context switch? Do I have the right tab open? Do I need to update something afterward? Each of those decisions has a tiny cost, and the costs compound across a day.Good tooling reduces decisions, not just clicks. Three examples from how Kilo for Slack actually gets used:A teammate posts an error trace in #engineering. You read it, see the stack, and instead of opening the IDE to think about it, you tag @Kilo and ask what's going on. The bot reads the trace, reads the relevant file from your connected repo, and posts an explanation in the thread. If the fix is small, you ask it to do the fix. A PR appears. The conversation stays in the thread where it started, which means the next person who comes across this bug six months from now can read the whole arc in one place instead of reconstructing it from three systems.A PM asks in a product channel whether a particular flow is feature-flagged. You don't know off the top of your head. Instead of saying "let me check," you tag the bot. It reads the relevant config file and answers in 20 seconds. You didn't lose ten minutes of focus to a context switch, and the PM got a real answer instead of a "yeah I'll get back to you" that takes two days.A bug fix needs to land in three different repos. The cloud landing page, the marketing site, the docs. Normally this is one of those tasks where the work is small but the overhead is large, because you have to clone three things, make the same change three times, push three branches, open three PRs. You tag the bot and tell it to fix the thing in all three repos. Three PRs open up. You review them like you'd review any other PR.None of these are dramatic. That's the point. Friction reduction at its best is invisible. The work just happens with one fewer step and you don't go on stage about it.The other direction: friction the tool doesn't addThe harder design problem is not introducing new friction on the other end. A lot of "frictionless" tools fix one thing and quietly add three more.Slack bots are particularly prone to this. They tend to introduce: a new place to manage settings, a new place to manage permissions, a new model picker that doesn't match the one in your other tools, a new credit system, a new auth flow you have to remember.Kilo for Slack is built around the inverse of that. Settings live in your existing Kilo workspace at app.kilo.ai. Repo access goes through the same GitHub or GitLab integration you already configured for everything else. Model selection happens in the same dashboard you set it for other features. Credits are the same credits. Billing is the same billing. If you've already set up Kilo, the Slack bot is basically a checkbox.Kilo’s Sessions concept is worth pointing out here, because it's the part that does the actual heavy lifting under the covers. Kilo Sessions are retained across interfaces. So a thread you start in Slack - a task that turns into a PR, then a follow-up the next day in VS Code looking at that PR - and it's all the same session if you want it to be. The work follows you. You don't have to brief the model on what happened earlier, because the model was already there.This is the part that makes the Slack integration not feel like a bolted-on chatbot. It's the same agent. It just happens to know how to read Slack.A small note on the ideology behind this designThe first generation of AI dev tools optimized for "AI in my editor." The second generation, the one we're in now, is figuring out that the IDE is one surface of many. Engineers spend half their day in tools that aren't an editor: chat, ticket trackers, PR reviews, docs, the browser, mobile. If the AI only lives in one of those, it forces work into that one place, which is the opposite of helpful.The version of this that works is the one where the infrastructure is the same no matter where you access it. Same context. Same memory. Same models. Same credits. Different surfaces. That's the Kilo bet across the whole product, and the Slack bot is one of the cleanest expressions of it: you don't move to the tool, the tool moves to you.When a thread comes in tomorrow morning with an error you don't recognize, you'll find out pretty quickly whether the friction you've been living with was a tooling problem or a you problem. My guess is that for most teams, it's been a tooling problem the whole time, and you stopped noticing because nothing better existed.Set up Kilo for Slack from the Integrations menu at app.kilo.ai. The bot will be in your workspace in a few minutes. The next time someone posts a stack trace in your engineering channel, see what happens when you don't alt-tab.\