Your Slack agent should look like it belongs to your company

Guillermo Rauch recently described @𝚟, the agent that powers Vercel’s internal operations, and made a distinction that matters: if AI becomes foundational to how a company works, that AI should belong to the company.

Guillermo Rauch

@rauchg

We built an agent that powers our company's internal operations called @𝚟.

Every day-to-day job at Vercel now involves @𝚟. It's growing exponentially both in daily interactions and token use.

One can extrapolate to the day AI agents run entire companies from here. It's an expert in finance, comms, docs, marketing, engineering, business analytics. It's seeded by the skills we gave it and we update, but it's also constantly improving.

It already keeps memories and personalized workflows and schedules on a per-user basis. For example, I knew skills⁠.sh hit 1M skills and I shared this on these forums because I asked @𝚟 to periodically check and remind me.

It's powered by and is also the basis for the design of @evedev_. We built this, it works fantastically well, we think every company should have it.

Before you @ me, I know you could also do this by picking your 'BigAI slack integration' du jour. But that's not your agent, that's their agent. If agents become the foundation of (and even synonymous with) modern companies, you being in complete control, from source → runtime → data → token, seems like a pretty big deal to me.

Aug 2, 2026View on X ↗

I agree with the destination and we've seen first hand at Adapt (as have our customers!) of the power and utility of an integrated coworker that meets you where you work -- like in Slack! I have long felt that some of the best products exist to help any team build capabilities that the best engineering teams in the world are building, which seems to continue to come up with this category of product being created by world-class engineering teams like at Vercel, Ramp, Block, and others.

Your Slack agent is not just another integration. It can answer questions in front of the team, show up when something needs attention, work across the systems your company depends on, and leave behind knowledge other people can use. I am not yet sure whether I am fully AI-pilled enough to believe in AGI, but I have seen the power of a company-branded AI coworker that just does work as a member of the team, answers questions, and keeps individuals on the team focused on what they can uniquely do.

Therefore, we believe that every company should and will have an integrated coworker that meets them where they work: in this case, in Slack!

The false choice: generic or build it yourself

Until now, teams choosing an AI agent in Slack have faced a tradeoff.

You can install a model provider's agent in minutes, but it arrives with their name, their identity, and their product boundaries. Claude Tag is useful, but it is still Claude in your workspace. It is not your company's agent, even if it is more helpful than everyone managing insights in a separate chat window.

Or you can build it yourself. You can choose the framework, models, runtime, and every part of the experience. That control is real. So is the work: a production Slack agent needs a maintained app, authentication, permissions, policies, context, durable workflows, monitoring, and someone on call when it breaks.

AI has made it much faster to build a prototype. It has not removed the work of operating a reliable, secure agent for an entire company. As the category evolves, your team owns the roadmap, the edge cases, and every capability you decide you need next.

For most teams, productionizing that stack is a weeks- or months-long engineering project. The goal is to run the company on an agent, not to make the company run an agent platform.

We built branded Slack agents around that tradeoff: set one up in minutes, while making it feel and operate like your coworker, not ours.

Branding is behavior, not a logo

Giving your agent a name, profile, and company identity matters. A teammate should be recognizable in a busy channel.

But a logo alone does not make something yours.

A branded Slack agent that is truly powerful and integrated needs four things:

• Your identity. Its name, description, and profile should feel native to the team. It should represent your company, not advertise another product in every conversation.
• Your context. It needs the skills, knowledge, systems, and conventions that make its answer useful to your team instead of vaguely correct to everyone.
• Your behavior. Every Slack channel is different. An engineering incident channel needs a different type of agentic behavior than a leadership channel. The agent needs clear policies for when to respond, when to ask, and when to leave the thread alone.
• Your control. The company should choose what the agent can access, what it can do, which model it uses, and when a human needs to be involved.

If an AI agent is going to become part of how your team works, it cannot be a black box with a different paint job. The identity, context, and operating model have to belong to the company using it.

This is what a company-native agent looks like in practice: it carries the company's identity, works from its systems and rules, and explains the work it is taking on.

Control matters just as much when an agent is ready to act. A branded agent should know when it needs explicit approval instead of treating an ambiguous message as permission to change a system of record.

Otherwise, it is just a mascot.

Slack is where the agent makes the company smarter

One of my favorite things about working in Slack is how a good answer can help more than one person.

We saw this internally with an Adapt agent that answered a technical question in a team channel. I am a curious person, and I try not to pester people when I can avoid it. The agent gave me a more direct answer than a teammate could have given from memory, because it could go find the details.

But the best part was not that I got an answer.

The whole team could see it. The next person with the same question did not need to ask again. The answer became part of how we work.

That is the shape of a real company agent. It is not a private shortcut that makes one person slightly more productive. It is a shared teammate that makes the whole organization more capable over time.

A good branded agent should do exactly that:

• Answer a question in the thread where everyone can benefit.
• Pull the company context that a busy teammate would otherwise need to hunt down.
• Turn a recurring question into durable knowledge.
• Notice an event in the right channel and take the obvious first step.
• Report back in the language, format, and place the team already understands.

This is why I care about the Slack surface so much. It is not just another place to access a model. It is one of the places where company knowledge compounds and everyone learns and benefits from the answer in public.

It has to know when not to talk

There is a very real failure mode here, obviously.

Nobody wants a branded spam bot (cough Viktor, cough) that feels like a toy that pesters you. We have enough distractions without an LLM wrapper pestering us in Slack.

An agent that responds to every message feels less like a teammate and more like somebody who just joined the company and has not learned the social norms yet. That person might be enthusiastic. They are also exhausting.

A useful Slack agent needs the same kind of judgment people use all day: is this a question I should answer? Is this something I should investigate and report back on? Is this sensitive? Is the right move to do nothing?

This is why Adapt lets teams set response behavior per channel and thread. You can keep the agent mention-only, give it a plain-English SMART policy for the things it should handle, or make it respond to every message where that is actually useful.

@Adapt you're a member of the engineering team so participate in discussions where you can add value, which includes replying automatically to PR reviews, responding when there are architectural details to evaluate or trade-offs to consider, or in general when you have something to add to the conversation. Otherwise: be quiet! Let us work.

The ability to be proactive matters. The ability to be appropriately quiet so the team can get shit done matters just as much.

Slack is the front door, not the whole house

A Slack agent is just one surface of where team's work, but Adapt aims to integrate where every team member works, which includes our messages integration (iMessage and RCS), GitHub, our web UI, and more surfaces coming in the future. More generally, our ambition is that anything with an API and wherever a team works, we integrate.

The conversation may start there, but the work rarely ends there. A useful answer might require checking GitHub, reading a customer email, querying a warehouse, looking at a meeting transcript, opening a browser, or running a small piece of code.

The agent needs to be native in Slack, then able to go do the work somewhere else.

That is why a branded Slack agent needs more than a model and a connector. Underneath it, there has to be a real system: a model router that can choose the right intelligence for the task, a secure runtime to inspect and act on the relevant systems, and a durable filesystem for the skills, knowledge, and automations that make it more useful over time.

Slack is where the company meets the agent. It should not be the boundary of what the agent can do.

Your own agent, powered by Adapt

As is abundantly obvious at this point, today we are launching branded Slack agents. Your company can give Adapt its own name, description, and icon in Slack, then put it to work across the systems and workflows your team already uses, integrating with anything with an API and providing real, durable infrastructure that the agent can do work in with Firecracker microVMs aka sandboxes (a "computer").

The setup has three parts:

1. Customize it. Choose the name and description your team will see.
2. Create it in Slack. Adapt prepares the manifest, permissions, and callback URLs. Add your icon in Slack.
3. Connect it. Bring the app credentials back to Adapt and authorize the connection.

Give it a name that belongs in your workspace. Teach it how your company works. Let it help where it should. Make it quiet where it should be quiet. Let it do the work that starts in Slack and finishes across the rest of your stack.