We gave our AI agent Slack access. Here's what it does there.

We added Slack connector access to our Avery NXR setup three months ago. The change was bigger than we expected.

Most teams think about AI as something that lives in a separate interface — open an app, type a prompt, get an answer. When you put an agent inside Slack, the relationship inverts. The agent is where the team already is.

Here's what we've learned giving agents Slack access.

The agents we run in Slack

1. The on-call agent. Listens to #alerts. When a known issue pattern fires, the agent acknowledges, runs diagnostics, posts results, attempts remediation. Only pings a human when something needs judgment. Replaced ~80% of routine alert fatigue.

2. The pipeline agent (Carlos template + Slack). Posts a daily summary in #sales of stalled deals, slipping deals, deals worth a follow-up call today. Sales reps see it during morning standup. Replaced manual pipeline review meetings.

3. The competitor agent (Yuki template + Slack). Weekly post in #marketing summarizing meaningful changes on competitor sites. Includes impact analysis. Replaced "I should check what they're doing" intent that never executed.

4. The support escalation agent. Reads escalations posted in #support-escalations, drafts response based on past similar tickets + product knowledge base, posts as a thread reply. Support engineer reviews + sends. Replaced ~30% of escalation cycle time.

5. The standup agent. Posts daily standup prompts in #standup. Reads engineering activity (GitHub commits, Linear updates, calendar events). Drafts each person's standup update for review. Engineers edit and post. Replaced "I forgot what I did yesterday" anxiety.

What changed about how we work

Information surface concentrated. Pre-agent, important data was scattered: sales in HubSpot, support in Zendesk, dev in Linear/GitHub, monitoring in Datadog. Now: critical signals from each surface as Slack messages from agents. We check fewer places.

Context-switching dropped. Slack was already our default interface. Adding agents to it meant agent outputs land where we're already paying attention. We don't context-switch into AI interfaces.

Async work got better. When team is distributed, the agent fills the gap of "who's awake right now to triage this?" The agent triages, posts, leaves a clear trail. Whoever logs on first has structured context.

Decisions documented. Because agents post in channels with structured output, decisions get implicit logging. "Why did we follow up with that deal?" → scroll back to Carlos's post 2 days ago. Conversational logging without effort.

The privacy + audit angle

Giving an AI agent Slack access raises real questions:

→ Can the agent read channels it shouldn't? → Can the agent post things that would harm us? → Does the agent's processing of Slack messages create a data exposure?

How we handle this with Avery NXR:

Channel scoping. Each agent only has access to specific channels. Configured at setup. The pipeline agent can't read #design. The support agent can't read #board.

Post-only mode for some agents. Some agents can READ messages but can only POST to designated channels. Others can only post, never read. Permissions match the agent's job.

Local processing. Slack messages get processed by local models running on our infrastructure. Slack message content never reaches an external AI vendor.

Audit ledger. Every agent action in Slack is logged in Avery NXR's audit ledger. "Why did the agent post that?" is answerable.

Human in the loop for high-stakes actions. Agents can READ broadly, but actions that ANNOUNCE or COMMIT to something on our behalf require a human approval step.

What we learned to NOT do

Some lessons from things we tried that didn't work:

Don't make the agent chatty. Early version of our standup agent posted "Good morning team! Here's your standup prompt..." every day. It got noisy fast. Now: agents post structured content, no conversational framing.

Don't make the agent reactive to everything. First version of the support escalation agent tried to respond to every #support message. Too noisy + too many false positives. Now: agent only fires on explicit triggers (mentions, specific keywords).

Don't give the agent unfiltered channel access. Tempting to "let it learn from everything." Actual implementation: each agent gets the minimum channel access needed. Scope creep degrades quality and creates audit risk.

Don't make agents talk to other agents in public channels. Tried agent-to-agent conversations in Slack early on. Result: channels became unreadable to humans. Now: agent-to-agent talks via direct webhook/API, only final outputs land in Slack.

What enabled this

The architectural pieces that made it work:

→ OAuth Slack connector (one of Avery NXR's 15 OAuth connectors) — handles auth + permissions cleanly → Sub-agent capability — agents can chain together for multi-step workflows → Audit ledger — every action traceable → Local model — Slack content never leaves our infrastructure → YAML config — channel scopes, trigger conditions, post-only flags all configurable

Where this is going

We think 2026-2027 sees most operational AI move into the surfaces people are already using — Slack, Teams, email — instead of standalone AI interfaces.

The "open AI app, type prompt, get answer" pattern is the chatbot era.

The "AI shows up where you already work, does the job, leaves a trace" pattern is the agent era.

Avery NXR is built for the agent era. Slack is one of the surfaces. Email is another. Custom dashboards, webhooks, scheduled triggers — all of them are paths for agents to surface work in the places teams already pay attention to.

→ avery.software — Free Desktop tier. Slack connector is one of 15 OAuth connectors out of the box.