Nothing broke. The deploy was fine. But the 45 seconds between "why is staging deploying?" and "oh, the agent did it" aged our engineering lead about two years.

This is the approval problem. Your agent is smart enough to take consequential actions but not smart enough to know when it should stop and ask first.

The Spectrum of Danger

Not every action needs a human checkpoint. Searching Slack history? Fine. Summarising a thread? Go ahead. Looking up a Linear ticket? Nobody cares.

But there's a line, and most teams don't draw it until after the agent crosses it.

Here's roughly how I think about it. Low risk: reading data, searching, summarising, formatting. The agent can do these freely, hundreds of times a day, no oversight needed. Medium risk: creating tickets, posting messages to channels, updating documentation. These produce visible artefacts that other people see. A wrong ticket title or a confusing channel message wastes people's time but doesn't cause damage. High risk: deploying code, modifying infrastructure, closing tickets, sending external communications, changing permissions, deleting anything. These are hard to reverse, visible to customers or stakeholders, or both.

The low-risk stuff should be automatic. The medium-risk stuff depends on your team's comfort level. The high-risk stuff needs a human in the loop. Always.

What Human-in-the-Loop Actually Looks Like in Slack

The pattern is simpler than you'd think. When the agent decides to take a high-risk action, instead of taking it, it posts a message to the relevant channel or DMs the requesting user:

I'm about to deploy PR #4521 to staging.
→ Approve: react with ✅
→ Deny: react with ❌
Waiting 5 minutes before timing out.

The agent watches for a reaction. If it gets a checkmark from an authorised user, it proceeds. If it gets an X or times out, it cancels and explains why.

That's it. Reactions as an approval mechanism. It sounds hacky, but it works incredibly well in practice because it meets engineers where they already are. Nobody has to open a separate dashboard or approval tool. The approval happens in the same Slack thread where the conversation is happening.

Some teams use Slack's Block Kit buttons instead of reactions. "Approve" and "Deny" buttons in the message. This is more polished and lets you capture who clicked what, but it requires your gateway to handle Slack interactivity payloads, which adds complexity.

Building the Gate

The implementation is an MCP server with one tool: request_approval. Here's the logic:

The tool takes three parameters: what action is being requested (a human-readable description), the risk level (medium or high), and which users or roles can approve it.

When called, the tool posts the approval request to Slack, then enters a polling loop. It checks for reactions or button clicks every 2 seconds for up to 5 minutes (configurable). If approved, it returns {approved: true, approver: "@dave"}. If denied or timed out, it returns {approved: false, reason: "denied by @dave"} or {approved: false, reason: "timeout"}.

The agent's system prompt includes instructions: "Before taking any action classified as high-risk, call request_approval and wait for the result. Do not proceed without approval. If denied, acknowledge the denial and ask what the user would like to do instead."

About 150 lines of code for the MCP server. The system prompt addition is maybe 4 lines. The behaviour change is significant.

The Hard Part: Classifying Actions

The technical implementation is easy. Deciding what needs approval is hard.

If you require approval for everything, people get fatigue. They start rubber-stamping approvals without reading them. Worse, they start resenting the agent for being needy. "Why am I approving a Slack message?" is a reasonable complaint when the agent asks permission to post a summary.

If you require approval for too little, you get the "ship it" problem. The agent takes an action nobody expected, and trust erodes.

Our classification after two months of tuning:

No approval needed: Read operations (search, fetch, query). Summaries and formatting. Creating draft documents. Responding in threads where the agent was explicitly mentioned.

Approval needed from thread participants: Creating Linear/Jira tickets from conversations. Posting to channels the agent wasn't mentioned in. Updating wiki pages. Sending scheduled messages.

Approval needed from specific roles: Deploying to any environment. Modifying CI/CD configuration. Closing or merging PRs. Updating status pages. Anything touching production infrastructure. Sending communications to people outside the team.

The "thread participants" tier is interesting. If Dave asks the agent to create a ticket in a thread, the agent creates the ticket and posts the link. But if the agent decides on its own that a conversation should become a ticket, it asks Dave first. The distinction is explicit request vs. autonomous decision. Explicit requests have implicit approval; autonomous decisions don't.

Timeout Behaviour Matters More Than You Think

What happens when nobody responds to the approval request?

Our first implementation timed out silently. The agent would post "I'm about to deploy..." and if nobody responded in 5 minutes, it just didn't deploy. No follow-up message. The user would come back 20 minutes later and wonder why the deploy never happened.

Now the agent posts a timeout message: "Approval timed out. I didn't deploy PR #4521. Re-trigger by saying 'deploy #4521' when you're ready." This closes the loop. The user knows the action didn't happen and knows how to retry it.

We also added escalation for truly urgent approvals. If the approval is tagged as "urgent" (the agent can determine this from context, like an active incident), the timeout is shorter (2 minutes) and the agent DMs the on-call person directly rather than waiting for a channel reaction.

The Trust Curve

Something we didn't expect: approval gates actually increased trust in the agent.

Before the gates, people were nervous about what the agent might do. They'd phrase requests carefully, adding qualifiers like "just look, don't change anything" or "summarise but don't post anywhere." The agent's autonomy was a liability.

After the gates, people got more ambitious with requests. "Go ahead and set up the staging environment for this" or "create tickets for all the action items in this thread." They knew the agent would ask before doing anything dangerous, so they felt safe giving it bigger tasks.

Usage of high-risk tools went up 3x after we added approval gates. Not because we enabled new capabilities. The capabilities were always there. People just weren't using them because they didn't trust the agent to stop itself.

What SlackClaw Does Here

SlackClaw has approval gates built into the platform. You classify your tools by risk level in the dashboard, and the platform handles the approval flow: posting the request, watching for responses, handling timeouts, logging who approved what. You don't build the MCP server or the polling logic.

The platform also provides an audit trail, which matters for compliance. Every approval (or denial) is logged with timestamp, approver, the action requested, and the context that led to the request. If you need to demonstrate that a human authorised every production deploy, that log exists.

For teams building their own, the MCP server approach works. The 150 lines of code is real. But the audit trail, the escalation logic, the timeout handling, the Block Kit integration — that's where the additional 500 lines live, and where a managed platform saves you time.

Start With Three Rules

If you're adding approval gates to an existing agent, start small:

1. Any action that touches production requires approval.
2. Any action that communicates externally (emails, status pages, customer-facing messages) requires approval.
3. Any action the agent initiates on its own (not in response to an explicit request) requires approval if it creates, modifies, or deletes something.

That covers maybe 90% of the scary scenarios. Refine from there based on what your team actually encounters. The goal isn't to gate everything. It's to gate the things where "oops" costs more than "hold on, let me check."

Your agent should be capable. It should also know when to pause.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about the gap between what AI agents can do and what they should do unsupervised.

Three weeks ago our monitoring fired at 2:47am. The OpenClaw agent in our #incidents channel had already posted a summary: which service was affected, what the error rates looked like, which deploy had gone out 40 minutes earlier, and a link to the relevant PR. By the time the on-call engineer opened Slack on their phone, the investigation was half done.

The agent didn't fix the issue. It can't rollback deploys or restart services (yet). But it compressed the first 15 minutes of incident response into about 90 seconds of reading. That's the difference between "I need to figure out what's happening" and "I know what's happening, now I need to decide what to do."

This is the use case that convinced our engineering team the Slack agent was worth keeping.

Why Incidents Are the Perfect Agent Use Case

Most of the time, an AI agent in Slack is a convenience. Someone asks a question, the agent answers, everyone saves a minute. Nice but not transformative.

Incidents are different. The cost of slow response is measurable. Every minute of downtime has a dollar value. The first 15 minutes of an incident are almost entirely information gathering — the same information gathering that an agent excels at.

The typical incident response pattern: alert fires, on-call engineer wakes up, opens laptop, checks monitoring dashboard, finds the affected service, looks at recent deploys, checks error logs, pulls up the relevant code change, and starts forming a hypothesis. That's 15-25 minutes of context assembly before any actual problem-solving begins.

An agent can do all of that in parallel, in about 20 seconds, and post the results to Slack before the engineer has finished rubbing their eyes.

What Our Incident Agent Does

The setup isn't complicated. It's three MCP servers and some system prompt engineering.

Monitoring MCP server. Connects to our observability platform (Datadog, but this works with Grafana, New Relic, whatever). Two tools: get_service_health (returns error rates, latency, request volume for a service) and get_recent_alerts (returns alerts from the last hour with severity and affected components).

GitHub MCP server. Already had this for other agent tasks. The relevant tool here is get_recent_deploys ‚Äî returns the last 5 deploys with author, PR link, files changed, and deploy timestamp.

Incident MCP server. A thin custom server with three tools: create_incident_summary (structures the agent's findings into a formatted Slack message), get_runbook (retrieves the relevant runbook from our wiki for the affected service), and update_incident_status (updates a status page).

The system prompt for the #incidents channel tells the agent: "When an alert is posted in this channel, immediately investigate. Check service health, identify recent deploys, retrieve the relevant runbook, and post a structured summary. Do not wait to be asked. Do not ask clarifying questions. Investigate and report."

That last part matters. The default agent behaviour is to ask "what would you like me to look into?" when it sees an alert message. At 3am, nobody wants to have a conversation with a chatbot. They want information.

The 90-Second Investigation

Here's what happens when an alert hits #incidents:

Second 0-5: The monitoring integration posts the alert. PagerDuty notifies the on-call engineer.

Second 5-10: The agent recognises the alert, triggers get_service_health for the affected service, and get_recent_deploys in parallel.

Second 10-15: Results come back. The agent sees elevated 5xx rates on the payments service. A deploy went out 40 minutes ago touching the checkout flow. It triggers get_runbook for the payments service.

Second 15-20: The agent posts a structured summary to the channel:

🔴 Incident: payments-service 5xx spike
- Error rate: 12.3% (baseline: 0.2%)
- Started: ~02:05 UTC
- Recent deploy: PR #4521 (checkout flow refactor) by @dave, deployed 02:07
- Runbook: [Payments Service Incident Response]
- Likely cause: checkout flow changes correlate with error spike timing

Second 20-90: The on-call engineer reads the summary on their phone and already knows: which service, what's broken, when it started, and which code change probably caused it. They can make a decision (rollback the deploy, apply a hotfix, escalate) without any additional investigation.

Compare that to the no-agent experience: the engineer sees "payments-service high error rate" from PagerDuty, opens their laptop, navigates to Datadog, finds the right dashboard, identifies the error spike, opens GitHub, searches for recent deploys, finds PR #4521, reads the diff, and then starts thinking about what to do. That's 15 minutes on a good night.

What We Got Wrong First

The first version was too chatty. The agent would post updates every 30 seconds: "Still investigating...", "Checking deploy history...", "Found a recent deploy, analysing...". At 3am, every notification is a phone buzz. We got a very direct message from the on-call rotation about stopping the noise.

Fix: the agent compiles everything and posts once. One comprehensive message. If it finds additional context later (someone's thread message triggers more investigation), it threads the update rather than posting to the main channel.

The second mistake was false positives. The agent treated every message in #incidents as an alert. Someone posted "reminder: we have incident retro at 2pm" and the agent launched a full investigation into... nothing. It checked service health, found everything green, and posted "All services healthy, no incidents detected" which was technically correct but useless.

Fix: the agent now checks for specific patterns — monitoring integration messages from known bot accounts, messages containing error rate thresholds, or messages explicitly tagged with @incident-agent. Casual conversation in the channel is ignored.

Third mistake: the runbook tool returned a full wiki page. Some of our runbooks are 3,000 words. The agent would paste the entire thing into the channel. Nobody reads a 3,000-word runbook at 3am.

Fix: the tool now returns only the "immediate actions" section of the runbook — typically 3-5 bullet points. The full runbook is linked, not inlined.

The Economics

The incident agent costs us about \(2/month in idle monitoring (it checks service health every 5 minutes during off-hours, much less during business hours). When an incident fires, the investigation costs about \)0.15 in API calls and tokens.

The value: our mean time to first action dropped from 18 minutes to 4 minutes. We haven't done the formal calculation on what that's worth in reduced downtime, but our platform serves about $50k in daily transaction volume. At 12% error rate, even 10 minutes of faster response is meaningful.

PagerDuty's new AI agent suite does something similar with their SRE Agent, but it's tied to PagerDuty's ecosystem. If you're already using PagerDuty, their agent is worth evaluating. If you're using a different monitoring stack, or you want more control over the investigation logic, building it with OpenClaw gives you flexibility.

What SlackClaw Adds

The incident response pattern is one of SlackClaw's pre-built templates. You connect your monitoring tool, configure your deploy source, and the platform handles the investigation flow, message formatting, and noise reduction out of the box.

The advantage over building it yourself: the template includes the lessons we learned the hard way. Single-message summaries instead of chatty updates. Pattern-based alert detection. Runbook section extraction rather than full-page dumps. Thread-based follow-ups. You skip the two weeks of iteration we went through.

For teams that want the custom approach, the MCP server architecture I described above works. It's about 400 lines of code across three servers, plus system prompt tuning. Not trivial, but not a month of work either.

The Broader Point

The incident agent is the thing that made our engineering team actually care about the Slack agent. Before this, it was "a useful tool." After this, it was "something I rely on at 3am."

That's the transition every Slack agent needs to make. From "nice to have" to "I'd notice if it disappeared." Incident response is one path to that transition because the value is obvious and immediate. Find yours.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about what happens when AI agents meet real operational pressure.

We rewrote our agent's system prompt four times in six weeks. Each rewrite cut our error rate, reduced costs, and improved response quality. The first version was 3,200 tokens. The current one is 890.

That's not a story about minimalism for its own sake. It's about all the ways a bloated, poorly-structured system prompt quietly degrades your Slack agent without anyone noticing until the bill arrives or a user screenshots a bizarre response.

The Copy-Paste Trap

Most teams start their system prompt by copying an example from the docs or a tutorial. The example includes instructions for web browsing, code execution, image analysis, file management, and a dozen other capabilities. Your agent lives in Slack. It doesn't browse the web. It doesn't execute code. It doesn't analyze images.

But those instructions are in the system prompt, so the model reads them on every single request. Two problems with this.

First, tokens. A 3,200-token system prompt means 3,200 input tokens before the user's message, before the conversation history, before the tool descriptions. On Opus, that's about \(0.05 per conversation turn just for the system prompt. Multiply by 200 turns per day in a moderately active workspace, and you're spending \)10/day on instructions the agent never uses. We were.

Second, capability confusion. When the system prompt tells the model it can browse the web, the model sometimes tries to browse the web. It hallucinates a browsing action, formats a response as if it received web data, and presents made-up information with confidence. We caught this because a user asked about a competitor's pricing and the agent returned specific numbers that were completely fabricated. It had "browsed" their website in its imagination.

Remove every instruction for a capability your agent doesn't have. This isn't optional cleanup. It prevents hallucinations.

The Identity Crisis

Slack agents need a clear identity. Not a corporate mission statement. A functional identity that tells the model what it is, who it talks to, and what it should refuse.

Our first system prompt started with "You are a helpful AI assistant." Which is what every AI assistant's prompt says. In a Slack workspace, that's too vague. The model doesn't know if it should answer questions about the company's benefits policy, debug a production error, or write marketing copy. So it tries to do all three, badly.

Our current prompt opens with three sentences: what the agent does (answers engineering and ops questions), who it serves (the engineering team), and what it declines ("I don't handle HR, legal, or finance questions — direct those to the relevant Slack channel"). Clear boundaries made the agent more useful, not less. Engineers stopped getting hedged, generic answers and started getting specific, confident ones about the domain it actually knows.

The identity also needs a tone. "Be concise" doesn't cut it. We specify: "Respond in 1-3 sentences unless the question requires a longer explanation. Use code blocks for technical content. Don't apologise for limitations — just state what you can't do and suggest where to find the answer."

That last bit matters more than you'd think. An agent that opens every third response with "I apologise, but I'm not able to..." trains users to stop asking questions.

Tool Descriptions Are Part of Your Prompt

Here's what catches people: your MCP server tool descriptions are injected into the context alongside your system prompt. Every tool, every parameter description, every example — that's all tokens.

We had six MCP servers with a combined 6,400 tokens of tool descriptions. Add that to our 3,200-token system prompt, and every conversation started with 9,600 tokens of instructions before anything useful happened.

Two fixes. First, we rewrote our tool descriptions to be shorter. Most were written as documentation, with paragraphs explaining edge cases and usage patterns. The model doesn't need a paragraph. It needs a sentence: "Search Slack messages by keyword, user, or date range. Returns max 20 results." That's enough. We cut tool description tokens by 60%.

Second, we scoped which tools load per channel. Our #engineering channel gets GitHub, Linear, and deploy tools. Our #general channel gets Slack search and knowledge base tools. The agent in #general doesn't need to see GitHub tool descriptions, and not loading them saves tokens and prevents the agent from trying to use tools irrelevantly.

SlackClaw does this scoping automatically — tools load based on channel configuration, not as a global dump. If you're self-hosting, you need to build this routing yourself, but it's worth the effort.

The Conversation History Problem

Your system prompt defines the agent. But in Slack, the conversation history that accumulates during a thread can dwarf the system prompt entirely.

A 30-message Slack thread might add 15,000 tokens of history. Your 890-token system prompt is now 5% of the input. The model's behaviour is being shaped more by the conversation history than by your instructions. This is where agents "drift" — they start matching the tone and format of the thread rather than following prompt instructions.

We handle this with context summarization. After 10 messages in a thread, the agent summarizes the conversation so far into a compact state object and uses that instead of the raw message history. The summary is typically 400-600 tokens regardless of thread length. It preserves the key facts and decisions without the verbosity.

This isn't just a cost optimization (though it is — we save roughly $4/day on context tokens alone). It's a quality improvement. The agent stays anchored to its system prompt instructions because the prompt remains a meaningful proportion of the input.

Channel-Specific Personas

This is the thing that made the biggest difference and nobody talks about it.

We run one OpenClaw agent across four Slack channels. Same agent, same gateway, same MCP servers. But each channel gets a different system prompt addendum.

In #engineering, the prompt adds: "This channel discusses code, architecture, and technical decisions. Include relevant file paths and link to PRs when referencing changes. Assume the reader is technical."

In #ops, it adds: "This channel handles deployments, incidents, and infrastructure. Be specific about timing, status, and next steps. If an incident is active, prioritize clarity over completeness."

In #general, it adds: "This channel is mixed. Keep responses brief. If a question is better suited to #engineering or #ops, say so and suggest they ask there."

Same agent, three different personalities. The responses in #engineering are longer, more technical, and include code references. The responses in #ops are terse and action-oriented. The responses in #general are short and redirecting.

This is straightforward to implement — your gateway receives the channel ID with every message and prepends the channel-specific addendum to the system prompt. Maybe 50 lines of code. The user experience improvement is dramatic.

The Prompt You Should Start With

If I were writing a system prompt for an OpenClaw Slack agent today, from scratch, it'd have four sections:

Identity (2-3 sentences). What the agent does, who it serves, what it declines.

Behaviour rules (5-8 bullet points). Response length, tone, format preferences, error handling. Specific enough to be useful, short enough to not waste tokens.

Channel context (2-3 sentences, injected per channel). Domain, audience, expected response style.

Tool usage guidance (3-5 lines). When to use which tools, what not to attempt, how to handle tool failures.

Total: 800-1,200 tokens. If your system prompt is longer than that, you're probably including instructions the model doesn't need, capabilities the agent doesn't have, or context that belongs in tool descriptions rather than the prompt.

The prompt is the most important config file in your agent's stack. It's also the one that gets the least attention after initial setup. Review it quarterly at minimum. Better yet, track which instructions the agent actually follows and which it ignores, and cut the ignored ones.

SlackClaw includes prompt templates tuned for Slack-specific patterns out of the box, with per-channel persona support and automatic context management. If you'd rather not spend six weeks learning this the hard way like we did, that's the shortcut.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about what it actually takes to run AI agents in production.

OpenClaw shipped v2026.3.8 this morning. Twelve security patches, a new backup tool, ACP provenance for agent identity, and a fix for duplicate Telegram events. Most of the coverage I've seen focuses on the feature list. I want to talk about what it actually changes if you're running an agent in Slack.

Because some of these fixes are more important than they look.

The Security Patches Are the Real Story

Twelve security fixes in one release. OpenClaw doesn't break these out individually in the changelog (they never do, which is its own problem), but the volume tells you something. This comes two weeks after ClawJacked made headlines and about a month after Invariant Labs published their MCP server audit showing 36.7% of servers vulnerable to SSRF.

The pattern is clear: OpenClaw is in a hardening cycle. They shipped fast, broke things, and now they're fixing what broke. That's not a criticism. It's the natural lifecycle of any tool that goes from "interesting project" to "thing that enterprises depend on" in under a year.

But if you're running an OpenClaw agent in Slack, "they're fixing things" isn't reassuring unless you're actually applying those fixes. I talked to three teams last week. None of them had updated past 2026.2. One was still on January's release. Their agent had been running fine, so why touch it?

Because your agent is a network-connected process with credentials to your Slack workspace, your GitHub repos, your deployment pipeline, and whatever else you've wired up through MCP servers. "It's working fine" doesn't mean "it's secure." Those twelve patches exist because twelve things were wrong.

Update. Today. Not next sprint.

ACP Provenance: Why Agent Identity Matters in Slack

ACP provenance lets agents verify who's interacting with them. In practical terms: your agent can now confirm that a request claiming to be from "the deployment server" actually came from the deployment server, not from a spoofed source.

This matters more in Slack than most contexts. A Slack workspace has dozens of people, multiple bots, possibly other agents. When your OpenClaw agent receives a message, it needs to know who sent it. Slack handles this at the message level (every message has a sender), but what about tool calls? What about agent-to-agent communication?

Before ACP provenance, if you had two agents in the same workspace, agent A could invoke tools on agent B's MCP servers without any identity verification. Agent B would process the request because it came from localhost. We're back to the "localhost is trusted" assumption that ClawJacked already demolished.

With provenance, each agent interaction carries a verifiable identity chain. It's not foolproof; nothing is. But it closes a real gap in multi-agent setups, which are becoming more common as teams wire up specialized agents for different functions (one for engineering, one for support, one for ops).

If you're running a single agent in Slack, this is nice to have. If you're running three, it's close to mandatory.

The Backup Tool Changes the Deploy Calculus

The openclaw backup command lets you snapshot and roll back your agent's state. This sounds mundane until you think about what "state" means for a Slack agent.

Your agent's state includes its configuration, MCP server connections, system prompts, tool definitions, and (depending on your setup) conversation history and learned preferences. When something goes wrong after an update, rolling back used to mean: stop the agent, manually revert config files, restart, hope you didn't miss anything, watch it for an hour.

Now it's: openclaw backup restore. Done.

This changes how aggressively you can update. The biggest reason teams fall behind on patches is fear of breaking a working setup. If you can roll back in seconds, the cost of trying a new version drops to nearly zero. Which means those twelve security patches actually get applied instead of sitting in a changelog nobody reads.

We've been running our Slack agent with manual config backups since January. It's three scripts and a cron job. Works, but it's the kind of thing you build because the tool doesn't do it for you. Now it does.

Telegram Duplicate Fix: Small Bug, Big Implications

This one's niche but worth mentioning. If you had an OpenClaw agent feeding notifications to Telegram (and plenty of Slack-adjacent setups do), you might have noticed duplicate messages. Not every time, but often enough to be annoying. Events were firing twice under certain race conditions.

The fix is straightforward, but it highlights something about the agent ecosystem that doesn't get discussed enough: edge cases compound. A duplicate notification is annoying. A duplicate tool call is expensive (double the API costs). A duplicate write operation is dangerous (two deploys, two database writes, two Slack messages that confuse your team).

If your agent has side effects, and a Slack agent always has side effects, idempotency matters. This fix handles it at the framework level, which is where it belongs.

What This Means for Managed vs Self-Hosted

Every release like this makes the argument for managed platforms a little stronger. Not because the features are hard to adopt, but because the operational burden of staying current is real.

If you're self-hosting, you need to: notice the release, read the changelog, test the update against your config, apply it, verify nothing broke, and do this every time a new version ships. OpenClaw has released three times this month. That's three update cycles for one component of your stack.

SlackClaw applies these updates as part of the platform. You don't run openclaw backup because the platform handles state management. You don't worry about ACP provenance configuration because agent identity is built into the multi-tenant architecture. The twelve security patches ship without you doing anything.

I'm not saying self-hosting is wrong. I'm saying the overhead is higher than most teams budget for, and it grows with every release. If your team has a dedicated platform engineer who enjoys this, great. If "the person who set up the agent" is also "the person who ships features," the updates won't happen. And that's how you end up three versions behind with twelve unpatched vulnerabilities.

The Practical Checklist

If you're running an OpenClaw Slack agent, here's what to do with today's release:

Run openclaw backup before updating. Even if you've never used it before, start now. Make it a habit.

Update to 2026.3.8. Don't wait for next week.

Check your MCP server authentication. The security patches are great, but they don't fix your MCP servers if those are still running without auth.

If you have multiple agents, enable ACP provenance. Read the docs; the config is about five lines.

Review your notification pipeline for duplicate handling. The framework fix helps, but if you've built custom notification logic, check whether it's idempotent.

Consider whether self-hosting is still worth the operational cost for your team. Not as a philosophical question. As a spreadsheet question. Hours spent on agent infrastructure times your engineer's hourly rate, compared to SlackClaw's pricing. The math is getting harder to ignore.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about what changes when AI agents go from demo to daily driver.

I'll be honest: when the announcement dropped, my first reaction was "finally." My second was "wait, does this break what we've built?"

We've been running an OpenClaw agent with a custom Slack MCP server for two months. Hand-rolled. It reads channels, searches messages, pulls user profiles. Works fine. Took about a week to build and another week to stop it from falling over at inconvenient hours.

Now Slack ships an official version that does... roughly the same thing. But with their infrastructure behind it, their auth model, and (crucially) their blessing. Here's what that actually means in practice.

What the Official Server Does

The Slack MCP server gives AI agents a standardised way to interact with Slack data. Search messages and files with filters for date, user, and content type. Retrieve user information by name, email, or ID. Discover channels. Read conversation history.

The Real-Time Search API is the more interesting piece. It gives apps real-time access to conversational data, which means your agent can search across current discussions instead of relying on whatever's in its context window. For anyone who's hit the context overflow problem (and if you're running an agent in a busy workspace, you have), this is a big deal.

Slack says partner ecosystem queries and MCP calls have grown 25x since launch. Claude, Manus, Guru are all in the marketplace. The ecosystem is moving fast.

What Changes for OpenClaw Agents

If you're self-hosting an OpenClaw agent with a custom Slack MCP server, you now have a decision. Keep your custom server or switch to Slack's official one.

The case for switching is straightforward. Slack's server handles auth properly. It respects workspace permissions. It gets updated when Slack's API changes. Your hand-rolled server does none of this automatically.

Our custom server broke twice in February because Slack deprecated an endpoint we were using for message search. We found out when the agent started returning empty results. Nobody noticed for a day and a half. With the official server, Slack maintains the integration. That's their problem, not yours.

The case for keeping your custom server is narrower but real. Slack's official MCP server exposes a specific set of tools. If your agent needs something beyond search, user lookup, and channel discovery — say, posting messages on behalf of users, managing workflows, or interacting with Slack's newer automation features — you'll still need custom tooling. The official server is read-heavy. It's built for retrieval, not action.

We're running both. The official server handles all our search and discovery. Our custom server handles writes: posting messages, creating reminders, updating channel topics. It's less code to maintain now, which is the right direction.

The Auth Problem Gets Better (Mostly)

This is where things get genuinely interesting. Slack's MCP server uses Slack's own OAuth flow. Your agent authenticates as a Slack app with specific scopes. The workspace admin controls what data the agent can access. It's not a personal token sitting in a JSON file.

Compare this to how most of us were doing it before. A bot token with broad permissions. Maybe a user token for search because the bot token couldn't access certain message types. Credentials stored in config files, never rotated, belonging to whoever set up the integration three months ago.

I wrote about the credential problem a couple weeks back. 67% of teams use static credentials for their AI agents. Slack's official MCP server doesn't solve this entirely, but it pushes auth into Slack's permission system, which is at least auditable. Your IT team can see what the agent accesses in the same admin panel they use for everything else.

The gap: the official server doesn't cover credentials for your other MCP servers. Your GitHub PAT, your Linear API key, your deployment tokens — those are still sitting in config files. Slack's server fixes the Slack auth piece. Everything else is still on you.

Real-Time Search Changes the Economics

Here's what nobody's talking about. The RTS API changes the cost structure of running a Slack agent.

Before: your agent monitored channels by reading every message. Every message was input tokens. In a busy workspace, that's thousands of messages per day that the agent reads, processes, and mostly ignores. We were spending $8 per day just on the agent passively watching channels.

After: your agent can search for relevant content on demand. Instead of reading everything and filtering, it searches when it needs context. "What did the team discuss about the billing migration this week?" becomes a search query instead of a context window full of messages.

The difference is substantial. We cut our daily Slack-related token spend by about 60% after switching search queries to the RTS API. The agent reads less, searches more, and the searches return only relevant results. Fewer input tokens, lower costs, and the agent actually has better context because the search is more targeted than "here's everything from the last 4 hours."

SlackClaw has had this pattern built in since launch — the platform manages context retrieval so you're not burning tokens on passive channel monitoring. If you're self-hosting, the RTS API lets you build something similar. It's not trivial, but the pieces are there now.

What's Still Missing

Slack's MCP server is version one. Good version one, but version one.

No write operations. You can't post messages, create channels, or manage workflows through the official MCP server. For a read-only agent, this is fine. For an agent that actually does things in Slack, you need additional tooling.

No per-channel permission scoping. The agent either has access to search a workspace or it doesn't. You can't say "this agent can search #engineering but not #exec-team." That's a problem for anyone running agents in workspaces with sensitive channels. Slack's broader permission model has channel-level controls, but the MCP server doesn't expose them granularly.

No built-in rate limiting feedback. If your agent hammers the RTS API, you'll hit rate limits. The MCP server doesn't proactively tell the agent "slow down" — it just starts returning errors. Your agent needs to handle this gracefully, which means building retry logic into your system prompt or your gateway layer.

No conversation threading awareness. The search returns messages, but threading context is limited. If someone asked a question in a thread with 30 replies, the search might return the parent message without the resolution. You need additional calls to get thread context, which eats into your rate limit budget.

What I'd Do Starting Fresh

If I were setting up an OpenClaw Slack agent today, from scratch, here's the stack.

Use Slack's official MCP server for all read operations. Search, user lookup, channel discovery. Don't build this yourself anymore. It's not worth the maintenance.

Build a thin custom MCP server for writes. Message posting, workflow triggers, channel management. Keep it minimal. Every tool you add is a tool you maintain.

Use the RTS API instead of passive channel monitoring. Your agent doesn't need to read every message. It needs to find relevant information when asked. This saves money and improves response quality.

Put your agent behind SlackClaw if you don't want to maintain any of this. The managed platform handles context retrieval, credential management, and the read/write split. You focus on what the agent does, not how it connects to Slack.

The Slack MCP server isn't revolutionary. But it's the foundation that was missing. Before this, every team building an OpenClaw Slack agent had to solve the same integration problems independently. Now there's a standard. The interesting work shifts from "how do I connect to Slack" to "what do I do once I'm connected."

That's where it should have been all along.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about what changes when AI agents actually ship to production.

Nobody had reviewed those keys since we set them up. Nobody had rotated them. The Linear key was a personal token belonging to an engineer who'd left two weeks earlier.

This isn't unusual. A Teleport report published last week puts numbers on what I'd already suspected: organisations where AI agents run with over-privileged credentials see a 76% incident rate. Organisations that enforce least-privilege access for agents? 17%. That's a 4.5x difference, and honestly it's lower than I expected.

The Problem Isn't What You Think

When people talk about AI agent security, they usually mean prompt injection or data exfiltration. Those matter. But the credential problem is more basic and arguably worse.

Your OpenClaw agent authenticates to external services using API keys, OAuth tokens, and personal access tokens stored in its MCP server configurations. Each MCP server gets a credential. Your Slack MCP server has a bot token. Your GitHub MCP server has a PAT. Your Linear MCP server has an API key. Your deployment MCP server probably has something that can push code to production.

Here's what goes wrong.

Most teams use a single credential per service with broad permissions. The GitHub PAT has repo access to everything, not just the repos the agent needs. The Linear key can create, read, update, and delete across all projects, not just the ones relevant to the Slack channel. You set it up once, it works, you move on.

67% of teams rely on static credentials for their AI agents, according to Strata's research on agentic identity. Static meaning: generated once, never rotated, sitting in a JSON config file on whatever machine runs the gateway.

The agent itself doesn't know what its permissions are. It just calls tools. If the Linear MCP server lets it close all tickets matching a filter, it will close all tickets matching a filter. We learned this one the hard way when an intern made a broad request and the agent complied without hesitation.

Agents Aren't Users

Traditional identity management treats every principal as either a human or a service account. Humans get SSO, MFA, session timeouts. Service accounts get scoped tokens and are supposed to get audited.

AI agents don't fit either bucket. They're not humans (no MFA, no session concept, no "log out and go home"). But they're not traditional service accounts either. A service account runs predictable code paths. An AI agent decides at runtime which tools to call based on natural language input from whoever's typing in Slack.

Teleport's phrase for this is "identity dark matter." Agents are real risk, real access, real credentials, sitting outside the governance framework that covers everything else. Only 22% of organisations treat AI agents as independent identities with their own access policies. The rest use shared API keys, or worse, borrow a human's credentials.

When an agent runs with Sarah's GitHub PAT and Sarah leaves the company, what happens? In most setups: nothing. The agent keeps running. The token keeps working. Sarah's permissions persist in a config file nobody remembers to update.

What This Means for Slack Agents Specifically

Slack-connected agents have a particular version of this problem. The agent sits in a channel where anyone can talk to it. Every message is a potential instruction. The agent's access envelope (everything it can reach through its MCP servers) is the same regardless of who's asking.

Junior dev asks the agent to check a ticket: it uses the same Linear credentials as when the VP asks it to reassign the sprint. The intern asking it to summarise a thread: same GitHub PAT as the lead engineer asking it to merge a PR.

You can see where this breaks down. The agent's access is set at deploy time, not at request time. And because MCP servers are just processes with API credentials, there's no built-in concept of "this request came from a junior dev, so limit what this tool can do."

Some teams solve this with system prompt instructions: "Only allow users in the #engineering channel to trigger deploys." That works right up until someone figures out they can DM the bot, or the agent gets confused about which channel a message came from. Prompt-level security is not security. It's a suggestion.

The Rotation Problem Nobody Talks About

API key rotation is boring. I know. Stay with me.

Your agent has, say, six MCP servers. Each has at least one credential. Some have two (an API key plus an OAuth token). That's maybe ten credentials total.

Each credential has a different expiration policy. Slack bot tokens don't expire unless revoked. GitHub PATs expire based on when you created them (30 days, 90 days, or never, depending on what you clicked). Linear API keys don't expire. OAuth tokens expire and need refresh tokens.

When a credential expires, the MCP server starts returning errors. If you've structured your responses well, the agent tells the user "this tool failed." If you haven't, the agent might fabricate a result based on the error message text (I wrote about this problem last week).

Either way, the agent is degraded until someone manually generates a new key, updates the config, and restarts the MCP server. There's no centralised credential management for MCP server configs. It's JSON files on disk.

We built a cron job that tests each MCP server endpoint every 15 minutes and alerts if anything returns non-200. But that only catches expired credentials after they've expired. Proactive rotation (replace keys before they expire) requires tracking expiration dates across six different services with six different APIs. We haven't built that. I doubt many teams have.

What Actually Works

Three things, from the teams I've talked to who've thought about this seriously.

Scope credentials to the minimum. Don't give the GitHub MCP server a PAT with full repo access. Create a fine-grained PAT scoped to the specific repos the agent needs, with read-only on code and read-write only on issues and PRs. Do the same for every service. Yes, this takes an afternoon. The alternative is the agent having more access than most of your engineers.

Track credentials like you track dependencies. Write down what key goes where, when it expires, who generated it, and what permissions it has. We use a private Notion page for this. A spreadsheet works. The format doesn't matter. Knowing what credentials exist and where they live is the baseline.

Separate access by operation, not by tool. This is where the architecture matters. Instead of "can use the Linear MCP server" (one permission), you want "can read tickets, can update individual tickets, can't bulk update, can't delete." This requires the MCP server to implement operation-level checks, which is more work than most people want to do when they're just trying to get the agent running.

SlackClaw handles this at the platform level. Credentials are managed per workspace, rotated automatically, and scoped per channel. The permission system works at the operation level, not the tool level, so your intern can read tickets in #support without being able to close everything in Linear. I'm biased (I use it), but building equivalent credential governance into a self-hosted setup took our team the better part of three weeks, and we still don't have automated rotation.

The Supply Chain Angle

One more thing. An incident report from earlier this year described a supply chain attack on an AI agent plugin ecosystem where compromised credentials went undetected across 47 enterprise deployments for six months. Six months.

The attack vector wasn't the AI model. It wasn't a prompt injection. It was a malicious plugin that silently forwarded API credentials to an external server. The credentials were the target, not the conversations.

This matters for OpenClaw because the MCP server ecosystem is growing fast, and not every server you find on GitHub has been audited. If you install a community MCP server and point it at your GitHub PAT, you're trusting that code with those credentials. There's no sandboxing, no credential isolation, no review process. ClawHub had 341 flagged malicious skills in a recent audit.

Every MCP server you add to your agent expands the credential surface. Every credential you store in a JSON config is a static secret that could be in a git repo, a backup, a log file. Treat your agent's credentials with the same care you'd treat production database passwords. Because functionally, that's what they are.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about AI infrastructure and what breaks when you actually run it.

I've been using it for six weeks. It's genuinely good at some things. It's also fundamentally limited in ways that matter if you're trying to do real work with AI in Slack rather than just ask it questions.

What Slackbot Actually Does Well

Credit where it's due. The new Slackbot nails the basics.

It reads your channels and threads, so when you ask "what happened in #engineering while I was out?" you get a real answer based on actual messages. Not a guess, not a summary of your calendar. The actual conversation.

The meeting prep feature is better than I expected. You tell it you have a 1:1 with Sarah at 2pm, it pulls recent messages between you, surfaces any open threads, checks for mentions in shared channels. Useful.

And the "draft in your voice" thing works, sort of. It clearly studies your message history to match tone and length. My drafts come out with British spelling and shorter sentences, which is more than I can say for most writing tools.

Where It Falls Apart

Here's where it gets frustrating.

Slackbot is a closed system. It can read your Slack data. It can read things connected through Salesforce's integrations. That's it. Your Linear tickets? Can't see them. Your Notion docs? Not without Agentforce connectors. Your custom deployment pipeline? Forget it.

When I ask Slackbot "what's the status of that billing bug Sarah mentioned?" it can find the Slack message where Sarah mentioned it. It cannot look up the actual ticket, check whether there's an open PR, or tell me if the fix shipped. It gives me a pointer and I have to do the rest myself.

This is the core problem. Slackbot is a search and summarisation tool wearing an agent costume. It can tell you what people said. It can't actually do things.

The second problem: you can't customise its behaviour per channel. In #support, I want the agent to check our knowledge base before answering customer questions. In #engineering, I want it to pull ticket context from Linear. In #general, I want it to mostly shut up. Slackbot gives you one behaviour everywhere.

Third: pricing. Business+ starts at \(12.50 per user per month. Enterprise+ doesn't publish pricing but it's significantly more. That's before you pay for Slack AI features or Agentforce add-ons. For a 50-person team, you're looking at \)7,500+ per year just for the tier that includes the AI agent. And every person on your Slack pays the same price whether they use the AI features or not.

The OpenClaw Alternative

This is where running your own AI agent makes more sense.

OpenClaw connected to Slack via MCP (Model Context Protocol) gives you everything Slackbot does — channel reading, message drafting, conversation summarisation — plus everything it doesn't. You define what tools the agent can access. Linear, Notion, GitHub, your deployment pipeline, your database, whatever you need.

I wrote about building MCP servers for this exact purpose a few weeks ago. Three custom servers — ticket bridge, docs resolver, deploy watcher — and suddenly the agent isn't just reading messages. It's looking up tickets by vague description ("that billing thing"), checking documentation freshness, and triggering deploys with permission checks.

The thing Slackbot can't do is the thing that actually matters: connecting to your specific workflow. Every team's stack is different. A one-size-fits-all agent handles the generic 60% and leaves the useful 40% to you.

But Self-Hosting Is Its Own Problem

I'd be dishonest if I pretended self-hosting OpenClaw in Slack was easy.

You need to maintain the gateway process. Configure MCP servers. Handle authentication. Set up permissions so the intern can't trigger production deploys by asking nicely. Build audit logging so you know what the agent did and why. Monitor costs because a runaway agent hitting GPT-5 can burn through $200 in an afternoon if nobody's watching.

We spent about three weeks getting our setup stable. A month if you count the time lost to the CVE-2026-25253 vulnerability patch and the two command injection advisories that followed it. Security with self-hosted agents is ongoing work, not a one-time setup.

This is why I ended up recommending SlackClaw to teams who ask me about this. It runs OpenClaw agents in Slack with the infrastructure already handled — per-channel permissions, audit logging, model-agnostic backend, credit-based pricing instead of per-seat fees. You get the flexibility of OpenClaw without maintaining the plumbing yourself.

The credit-based model particularly matters here. With Slackbot, your quietest team member and your power user pay the same monthly rate. With credits, you pay for actual usage. A 50-person team where 10 people use the agent heavily costs dramatically less than paying per-seat for everyone.

The Real Comparison

Let me be concrete about what each option gives you.

Slackbot works if: your team lives entirely in Slack and Salesforce. You don't need custom tool integrations. You're already on Business+ or Enterprise+. You want zero setup effort.

Self-hosted OpenClaw works if: you need custom integrations. You have an engineer who can dedicate time to maintaining the setup. You want full control over model choice, prompts, and data flow. You're comfortable with the security responsibility.

Managed OpenClaw via SlackClaw works if: you need custom integrations but don't want to maintain infrastructure. You want per-channel permissions and audit logging without building them. You'd rather pay per usage than per seat. You want to swap between models without rewriting prompts.

Most teams I talk to land on option three. Not because self-hosting is impossible, but because the time spent maintaining agent infrastructure is time not spent on the work the agent is supposed to help with.

What Happens Next

Salesforce will keep improving Slackbot. The Agentforce integrations will get deeper. More third-party connectors will show up. It'll get better.

But the architecture won't change. Slackbot will always be limited to what Salesforce decides to connect. Your niche internal tools, your custom workflows, your specific way of working — those will always need something more flexible.

The gap between "AI that answers questions about your Slack" and "AI that actually works alongside your team" is still wide. Slackbot fills the first category well. Everything else needs a different approach.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about AI infrastructure and the gap between what tools promise and what teams actually need.

I've been running OpenClaw agents in Slack for production teams since January. Here's what the actual bill looks like, and where managed hosting like SlackClaw changes the maths.

The Self-Hosted Bill

Let's say you're running a fairly standard setup: one OpenClaw agent connected to Slack, handling 50-100 messages per day, with access to your docs (Notion), your project tracker (Linear), and your codebase (GitHub). Nothing exotic.

Compute: $30-80/month

You need a server that's always on. OpenClaw's gateway process isn't heavy, but it needs to be responsive. Options:

• Hetzner CX31: 4 vCPU, 8GB RAM, ‚Ǩ8.50/month. Works fine for low traffic. Gets sluggish when the agent processes large context windows.

• AWS t3.medium: 2 vCPU, 4GB RAM, ~$30/month. The sensible middle ground.

• DigitalOcean Premium AMD: 4 vCPU, 8GB RAM, $48/month. What I'd recommend for teams that don't want to think about it.

If you're running multiple agents or handling more than 200 messages/day, double these numbers.

LLM API costs: $50-300/month

This is the big one, and it's the one that surprises people. Every message your agent processes costs money. Claude, GPT-4, whatever you're using under the hood.

A typical Slack message exchange (user question ‚Üí context retrieval ‚Üí response generation) runs about 2,000-4,000 input tokens and 500-1,000 output tokens. At Claude Sonnet pricing (\(3/\)15 per million tokens), that's roughly $0.01-0.02 per exchange.

At 100 exchanges per day, that's \(1-2/day, or \)30-60/month.

But here's what people miss: long Slack threads balloon the context. A 20-message thread with full history? That's 8,000-12,000 input tokens per response. A single busy thread can cost \(0.50-1.00 by itself. I've seen months where API costs hit \)300 purely because of a few runaway threads during incident response.

MCP Server hosting: $0-40/month

If you're connecting to Notion, Linear, GitHub, and your internal docs, each MCP server needs to run somewhere. Most people run them on the same box as the gateway, which is fine until one of them starts leaking memory (the Notion MCP server is particularly bad about this).

If you split them out to separate processes or containers, add $10-40/month depending on how many you're running.

SSL, domains, monitoring: $10-20/month

You'll want:

• A domain for your webhook endpoint (if not using Socket Mode): $12/year

• SSL certificate: Free via Let's Encrypt, but someone has to renew it

• Uptime monitoring (UptimeRobot, Betterstack): $0-10/month

• Log aggregation (if you're doing it properly): $0-15/month

Your time: priceless (and expensive)

Here's the cost nobody puts on a spreadsheet. Someone has to:

• Set up and maintain the server

• Configure Slack app permissions correctly (see my previous article on why this matters for security)

• Keep OpenClaw updated (three security patches this year alone)

• Debug issues when the agent stops responding at 3am

• Manage API key rotation

• Handle the inevitable "why did the agent say that in #general" incidents

In my experience, this takes 4-8 hours per month for a stable setup, and 20+ hours in the first month. At the fully loaded cost of an engineer's time, that's $500-2,000/month that doesn't show up in any cloud bill.

Total self-hosted: $90-440/month + engineer time

The Managed Alternative

SlackClaw runs on a credit-based model. You buy credits, and each agent interaction costs credits based on complexity. No per-seat fees, no monthly subscription.

For the same 100-exchange-per-day workload:

• Credits: roughly $50-120/month depending on average complexity

• Server, MCP servers, monitoring: included

• Security configuration: included (per-channel permissions, audit logs, output filtering)

• Updates and patches: automatic

• Your time: near zero after initial setup

So the managed cost is \(50-120/month with no engineering overhead. The self-hosted cost is \)90-440/month plus 4-8 hours of an engineer's time.

When Self-Hosting Makes Sense

I'm not saying managed hosting is always better. Self-hosting makes sense when:

1. Compliance requires it. If your data literally cannot leave your infrastructure (healthcare, defence, certain financial services), you have to self-host.

2. You need deep customisation. If you're building something that doesn't fit standard deployment patterns — custom auth flows, unusual MCP servers, non-standard Slack configurations.

3. You have a dedicated platform team. If someone's job is already managing infrastructure, adding one more service isn't a meaningful cost increase.

When Managed Makes Sense

Managed hosting wins when:

1. You're a small team. Fewer than 20 engineers. You don't have spare capacity to run infrastructure.

2. Speed matters. Getting from "we want an AI agent in Slack" to "it's running and useful" in a day vs a week.

3. Security is a concern but not a differentiator. You want it done right, but building security infrastructure isn't your core business.

4. You're cost-conscious about engineering time. The real cost isn't the cloud bill. It's the opportunity cost of your engineers maintaining agent infrastructure instead of building your product.

The Numbers, Side by Side

Your numbers will be different. But the pattern holds: self-hosting looks cheap until you count the engineering time, and managed hosting looks expensive until you count what's included.

Do the maths for your specific situation. If you're just experimenting, self-host on a $5 VPS and see what works. If you're deploying for a real team, SlackClaw is probably cheaper than you think.

Helen Mireille is chief of staff at an early-stage tech startup. She writes about the operational costs that don't make it onto pitch decks.

That's the promise. Here's how it actually works with OpenClaw, what the configuration looks like, and where it falls down.

The integration model

OpenClaw treats each external service as a tool the agent can call. You configure the connection (API key, OAuth token, scopes) and define what the agent is allowed to do with it. The agent then decides which tools to invoke based on the user's request.

This is different from traditional integrations, which are usually one-directional pipes. A GitHub-to-Slack integration posts PR notifications. That's it. An OpenClaw agent with GitHub access can post notifications, but it can also answer "what PRs are open against the billing service?" or "who reviewed the most PRs last week?" It reads, queries, and reasons about the data.

Here's the tool configuration for our three main integrations:

tools:
  github:
    auth:
      type: oauth_app
      credentials: vault://github-openclaw-token
    scopes:
      - repo:read
      - pull_requests:read
      - issues:read
      - actions:read
    allowed_operations:
      - list_pull_requests
      - get_pull_request_details
      - list_commits
      - get_workflow_runs
      - list_issues

  linear:
    auth:
      type: api_key
      credentials: vault://linear-openclaw-key
    scopes:
      - read
    allowed_operations:
      - search_issues
      - get_issue
      - list_project_issues
      - get_cycle_progress

  notion:
    auth:
      type: integration_token
      credentials: vault://notion-openclaw-token
    scopes:
      - read_content
      - read_databases
    allowed_operations:
      - search_pages
      - get_page_content
      - query_database

Notice: all read-only scopes. We don't let the agent write to any of these systems. That's a deliberate choice. It can read GitHub, Linear, and Notion. It cannot merge PRs, close tickets, or edit documents. Some teams are comfortable with write access; we're not there yet. Maybe we never will be. Reading and reporting is valuable enough.

Multi-tool queries in practice

The useful bit is when the agent combines information from multiple tools in a single response. Let me show some real examples from our Slack history.

Query: @agent what's the status of the billing refactor?

The agent searches Linear for issues tagged with the "billing-refactor" project, checks GitHub for open PRs linked to those issues, and pulls the project brief from Notion. The response:

Billing Refactor Status:

Linear: 14 of 22 issues complete. 5 in progress, 3 in backlog.
Current cycle: 4 issues planned, 2 completed, 2 in progress.

Open PRs (GitHub):
  - #847 "Migrate invoice generation to new billing engine" — opened 2 days ago
    by Marcus, review requested from Sarah. 412 lines changed.
  - #851 "Add retry logic for payment webhook failures" — opened today
    by Priya, no reviewer assigned yet. 89 lines changed.

Notion project brief last updated: 8 days ago.
Key risk noted in brief: "Dependency on Stripe API v2024-12 migration,
deadline March 15."

That response would have taken me fifteen minutes to assemble manually. Open Linear, find the project, count the issues. Switch to GitHub, search for related PRs, check review status. Open Notion, find the brief, skim for risks. The agent did it in about four seconds.

Query: @agent which PRs have been open for more than 3 days without a review?

PRs open >3 days without review:

1. #839 "Update dependency on auth-commons to v3.2"
   Author: James | Opened: 5 days ago | Files: 3 | Lines: +12/-8
   Linked Linear issue: AUTH-201 (priority: medium)

2. #842 "Fix timezone handling in scheduler"
   Author: Priya | Opened: 4 days ago | Files: 7 | Lines: +145/-62
   Linked Linear issue: PLAT-88 (priority: high)
   ⚠ Note: PLAT-88 is marked high priority but PR has no reviewer.

3. #844 "Add OpenAPI spec for billing endpoints"
   Author: Marcus | Opened: 3 days ago | Files: 1 | Lines: +580/-0
   No linked Linear issue.

The flag on #842 is the kind of thing that makes this valuable. The agent noticed that a high-priority Linear ticket has a PR with no reviewer assigned. I wouldn't have caught that without manually cross-referencing both systems. Our product manager now runs this query every morning.

Query: @agent summarise what the team shipped this week

Weekly Ship Summary (March 3-7):

Merged PRs: 11
  - 4 feature PRs (billing refactor, new onboarding flow)
  - 3 bugfixes (timezone scheduler, auth token refresh, webhook retry)
  - 2 dependency updates
  - 2 documentation updates

Linear issues closed: 16
  - billing-refactor: 6
  - onboarding-v2: 4
  - platform-maintenance: 6

Notable:
  - Billing refactor is now 64% complete (was 50% last week)
  - Onboarding v2 hit its cycle goal — all planned issues complete
  - 3 issues were reopened after being closed (AUTH-198, PLAT-92, BILL-44)

The "reopened" detail comes from Linear's issue history. The agent checks whether any closed issues were reopened, which is a signal that something was marked done prematurely. Useful for retros.

Configuring multi-tool skills

Beyond ad-hoc queries, you can define skills that combine tools automatically. Here's our weekly engineering report skill:

skill: weekly_engineering_report
trigger:
  schedule: "0 9 * * 1"
  timezone: "Europe/London"

steps:
  - action: query_github
    operations:
      - merged_prs:
          period: last_7_days
          group_by: author
      - open_prs:
          age_gt: 3_days
          flag: stale

  - action: query_linear
    operations:
      - completed_issues:
          period: last_7_days
          group_by: project
      - cycle_progress:
          current: true
      - reopened_issues:
          period: last_7_days

  - action: query_notion
    operations:
      - search:
          database: "Project Tracker"
          filter: "status = 'Active'"
          fields: [name, status, owner, target_date]

  - action: compile_report
    template: weekly_engineering
    post_to: "#engineering"
    also_post_to: "#leadership"
    format: |
      *Weekly Engineering Report — {{week_of}}*

      **Shipped**
      {{merged_prs_summary}}

      **In Flight**
      {{open_prs_summary}}
      {{cycle_progress}}

      **Attention Needed**
      {{stale_prs}}
      {{reopened_issues}}

      **Project Status**
      {{notion_project_summary}}

Every Monday at 9am, this assembles a report from all three tools and posts it. Before this existed, I wrote this report manually. It took about an hour and I quietly resented it.

What doesn't work well (yet)

Honesty section. Some things are rough.

Search quality varies by tool. GitHub's API is excellent for structured queries (PRs by date, by author, by status). Notion's API is less predictable. Searching for a page by name works; searching for "the doc about billing architecture" sometimes returns the right page and sometimes doesn't. The agent is interpreting the query and constructing an API call, and Notion's search API isn't great to begin with.

Rate limits. If you ask the agent something that requires pulling data from all three tools simultaneously, you can hit rate limits, especially on GitHub's API. The agent handles this with retries, but responses can take 10-15 seconds for complex queries during busy periods. Not terrible. Not instant either.

Stale data. The agent queries tools in real time; it doesn't maintain a cache. This means it's always current, but it also means it can't answer historical questions that require data the APIs don't expose. "What was the cycle progress two weeks ago?" requires Linear to have that data available via API. It doesn't always.

Context window limits. For large queries (like "summarise all PRs from the last month"), the agent might hit token limits. It handles this by truncating or summarising in batches, but the results can be less precise than a smaller query. Ask specific questions and you'll get better answers.

Setup and hosting

Connecting these tools to OpenClaw requires API credentials and configuration. If you're self-hosting, you manage the secrets and the agent deployment yourself. If you'd rather skip that part, SlackClaw handles the hosting, and you configure integrations through their dashboard. We use SlackClaw because managing OAuth tokens for three services plus Slack itself was more credential-wrangling than I wanted to take on.

The integration setup through SlackClaw took about twenty minutes per tool. GitHub was fastest (OAuth flow, select repos, done). Linear was straightforward (API key, paste it in). Notion was the most involved because you need to share specific pages and databases with the integration, and Notion's sharing model is, charitably, not intuitive.

Is it worth it?

Before this, our workflow was: someone asks a question in Slack, someone else opens three tabs, gathers the answer, pastes it back into Slack. Multiply that by ten questions a day across the team.

After: someone asks the agent. The agent answers. The conversation continues.

The time savings are real but hard to quantify precisely. I'd estimate we save 5-8 hours per week across the team on information retrieval alone. More importantly, decisions happen faster because the information is available when people need it, not when someone has time to go look it up.

If your team's workflow involves context-switching between GitHub, Linear, and Notion (or similar tools), an OpenClaw agent that connects all three is worth the setup time. The first week feels like magic. The second week it just feels normal, which is actually the better compliment.

I'm going to walk through four skills we built for our Slack workspace. These are real configurations running in production (via SlackClaw for the hosting, but the skill definitions work the same if you're self-hosting). I'll explain what each one does, why we built it that way, and what went wrong the first time.

How skills work (the 30-second version)

A skill is a YAML definition that tells the agent what to do when a certain condition is met. Conditions can be scheduled (cron), triggered by a command (@agent do-thing), or fired by a webhook. The skill defines inputs, actions, and where the output goes.

Skills can call external APIs, run queries against connected tools, and compose results into messages. Think of them as recipes the agent follows, with the LLM handling the parts that require interpretation.

Skill 1: Standup automation with blocker detection

The most common starting point. Here's what ours looks like:

skill: engineering_standup
description: "Collect daily standups and identify blockers"
trigger:
  schedule: "0 9 * * 1-5"
  timezone: "Europe/London"

inputs:
  channel: "#engineering"
  participants: "@engineering-team"

steps:
  - action: prompt_users
    message: |
      Morning. Three quick ones:
      1. What shipped yesterday?
      2. What's on for today?
      3. Anything blocking you?
    timeout_minutes: 60
    reminder_at: 30

  - action: analyse_responses
    extract:
      - blockers
      - themes
      - dependencies
    cross_reference:
      - source: linear
        match: mentioned_tickets

  - action: post_summary
    channel: "#engineering"
    format: threaded
    sections:
      - shipped_yesterday
      - planned_today
      - blockers_and_dependencies
    notify_on_blockers: "#leadership"

A few things to note.

The cross_reference step is what makes this better than a simple survey bot. When someone says "blocked on AUTH-142," the agent looks up that Linear ticket and includes its status in the summary. Instead of just reporting the blocker, it tells you whether the blocking ticket is in progress, unassigned, or stuck.

The notify_on_blockers parameter sends a separate, shorter message to #leadership when blockers are detected. This saves me from reading the full engineering standup every morning; I only get pinged when something needs attention.

What went wrong first time: We set timeout_minutes: 30 initially. Not enough. People who start at 9:30 were getting marked as non-respondents. We bumped it to 60 and response rates went up immediately. Also, the original message was more formal. People responded better when it sounded casual.

Skill 2: PR triage and review assignment

This one fires on a webhook from GitHub:

skill: pr_triage
description: "Categorise new PRs and suggest reviewers"
trigger:
  webhook:
    source: github
    events: ["pull_request.opened", "pull_request.ready_for_review"]

steps:
  - action: analyse_pr
    fetch:
      - diff_summary
      - files_changed
      - linked_issues
    classify:
      categories:
        - feature
        - bugfix
        - refactor
        - docs
        - dependency_update
    estimate_review_time:
      basis: diff_size_and_complexity

  - action: suggest_reviewers
    strategy: ownership_and_availability
    rules:
      - prefer_codeowners_for: [feature, bugfix]
      - any_team_member_for: [docs, dependency_update]
      - exclude: pr_author
      - max_active_reviews: 3

  - action: post_to_slack
    channel: "#pull-requests"
    template: |
      *New PR:* {{pr.title}}
      *Author:* {{pr.author}} | *Type:* {{classification}}
      *Est. review time:* {{review_estimate}}
      *Suggested reviewer:* {{suggested_reviewer}}
      *Files:* {{files_summary}}
      {{#if linked_issues}}
      *Linked:* {{linked_issues}}
      {{/if}}
    add_reactions:
      - eyes  # reviewer should react when starting review

The max_active_reviews: 3 rule prevents the agent from piling reviews onto one person. We had a senior engineer who was listed as codeowner for half the repo, and before this rule existed, every PR went to her. She was spending more time reviewing than coding. This fixed it.

The review time estimate is surprisingly accurate. It's not just line count; the agent looks at the complexity of the diff. A 500-line migration file gets a shorter estimate than a 200-line change to authentication logic. It's not perfect. But it gives the reviewer a rough expectation, and that alone reduced the "I'll get to it later" delays.

What went wrong first time: The webhook initially fired on pull_request.opened, which includes draft PRs. We were triaging PRs that weren't ready for review, cluttering #pull-requests with noise. Adding pull_request.ready_for_review and filtering out drafts solved it.

Skill 3: Incident response coordinator

This one's more involved:

skill: incident_response
description: "Coordinate incident response from detection to resolution"
trigger:
  webhook:
    source: datadog
    events: ["alert.triggered"]
  command: "@agent incident"

steps:
  - action: create_incident_thread
    channel: "#incidents"
    template: |
      :rotating_light: *Incident Detected*
      *Alert:* {{alert.name}}
      *Severity:* {{alert.priority}}
      *Service:* {{alert.tags.service}}
      *Started:* {{alert.timestamp}}
    pin: true

  - action: identify_oncall
    source: pagerduty
    escalation_policy: "engineering"
    notify: true
    message: "You're on-call. Incident thread is above."

  - action: gather_context
    queries:
      - source: datadog
        query: "recent deployments for {{alert.tags.service}}"
      - source: github
        query: "commits to {{alert.tags.service}} in last 2 hours"
      - source: linear
        query: "recent tickets for {{alert.tags.service}}"
    post_context_to: incident_thread

  - action: monitor_resolution
    watch: alert.status
    on_resolved:
      - prompt_oncall:
          message: "Incident resolved. Quick summary of what happened and the fix?"
      - compile_postmortem_draft:
          post_to: "#incidents"
          template: postmortem_v2

The gather_context step is the one I'm proudest of. When an alert fires, the agent immediately posts: "Last deployment to this service was 45 minutes ago by Marcus (commit abc123). Two Linear tickets were completed this week affecting this service." That context used to take 10-15 minutes of manual investigation during an incident. Now it's there in seconds.

The monitor_resolution step watches for the Datadog alert to clear, then prompts the on-call engineer for a quick summary. That summary feeds into an auto-generated postmortem draft. We still write proper postmortems, but having a draft with the timeline already filled in saves significant effort.

What went wrong first time: We didn't filter alert severity initially. The agent was creating incident threads for warning-level alerts that resolved themselves in minutes. We added severity-based routing: critical alerts get the full incident workflow, warnings just get posted to #incidents without the on-call ping and context gathering.

Skill 4: Customer feedback digest

The simplest skill, and possibly the most valuable:

skill: feedback_digest
description: "Weekly summary of customer feedback from support channels"
trigger:
  schedule: "0 8 * * 1"
  timezone: "Europe/London"

steps:
  - action: collect_feedback
    sources:
      - channel: "#customer-feedback"
        period: last_7_days
      - channel: "#support-escalations"
        period: last_7_days

  - action: analyse
    extract:
      - recurring_themes
      - feature_requests
      - frustrations
      - positive_mentions
    group_by: theme
    rank_by: frequency

  - action: post_digest
    channel: "#product"
    format: |
      *Weekly Customer Feedback Digest*

      *Top themes this week:*
      {{#each themes}}
      {{rank}}. *{{name}}* ({{count}} mentions) — {{summary}}
      {{/each}}

      *New feature requests:*
      {{#each feature_requests}}
      - {{description}} ({{source_count}} customers)
      {{/each}}

It reads every message in #customer-feedback and #support-escalations from the past week, groups them by theme, and posts a ranked summary. Our product manager used to do this manually every Monday morning. It took her about two hours. Now she reviews the agent's summary in ten minutes and adds her own commentary.

What went wrong first time: Nothing, actually. This one worked on the first try. Some skills are just straightforward.

General lessons

Start with the skill definition in a branch or test workspace. Don't deploy directly to your main Slack workspace. We learned this by accidentally posting test standup prompts to #general at 3am.

Keep skill descriptions clear. The agent uses the description to understand the skill's intent, which affects how it handles edge cases. "Collect daily standups" gives the agent less to work with than "Collect daily standups and identify blockers that might affect sprint goals."

Test your cron schedules. I don't know why, but I get cron syntax wrong about 40% of the time. Use crontab.guru. Every time.

If you want to skip the hosting and infrastructure parts and just focus on writing skills, SlackClaw handles the OpenClaw deployment. You write the YAML; they run the agent. That's the setup we use, and it means I can iterate on skills without asking our CTO to redeploy anything.

Build the simple skills first. Get the team used to the agent. Then add the complex ones. Trust is earned incrementally, even with software.