Claude’s Slack Agent Needs 4 Human Stops

By Lazar Milicevic · Published July 26, 2026 · 11 min read

The problem is not getting an AI agent into Slack. The problem is stopping it from sending the wrong email, changing the wrong CRM record, or touching an invoice before a person has seen what it plans to do.

Claude working inside a Slack thread removes a real source of friction: copying context between chat windows. But for a small business, the safe version is not “tag the agent and let it run.” It is a short workflow with four human-controlled boundaries around every irreversible action.

Slack is the right place for context, not automatic authority

A Slack-based agent is most useful when it gathers context, compares records, summarizes information, and drafts a next step in the thread where the team is already discussing the work. Slack should be the operational interface; it should not automatically become permission to act in every connected system.

Anthropic’s Slack workflow concept matters because it reduces context switching. A founder can tag an agent in a customer escalation thread, ask it to retrieve account history and relevant documents, then receive a draft response and recommended actions without opening five tabs.

That is useful. It is also only the first half of the workflow.

The second half is deciding which actions the agent can take without review.

This distinction is where most AI agent demos fall apart in a real business. They show a sequence of tool calls as if each one carries equal risk.

They do not.

A summary that misses a detail is annoying. An email that promises a refund, a CRM update that removes a deal owner, or an invoice correction that changes the amount due creates a business problem.

Slack’s own platform supports event-driven applications, which makes it a practical place to run this kind of workflow. Its Events API documentation describes the model as a way for apps to respond to activity in Slack. The important implementation detail is to treat a Slack event as a request to prepare work, not as a blanket authorization to execute it.

The four stops are controlled boundaries, not four approvals per task

A safe Slack agent needs four human-controlled stops: scope setup, context review, action approval, and exception closure. In a normal low-risk workflow, the operator should only need to approve one proposed external action; the other stops are policy boundaries that prevent the agent from silently expanding its authority.

If every agent task needs four button clicks, nobody will use the system. The goal is not bureaucracy. The goal is to make sure the agent cannot cross a business boundary without a clear rule or a visible human decision.

The four-stop pattern

1. Stop 1: Human-defined scope
   A person decides what enters the automation. Do not point the agent at every channel, every inbox, or every customer record.

   Start with one bounded trigger:

   • Messages in #customer-escalations where an authorized employee tags the agent
   • New leads from one form or one campaign source
   • Emails carrying one Gmail label, such as needs-follow-up
   • Invoice exceptions above or below a policy-defined threshold
   • Client feedback threads in one delivery channel

   This is a setup decision, not a repeated approval. It prevents a casual “@Claude can you look at this?” message in a random channel from becoming a CRM or billing workflow.

2. Stop 2: Human-visible context review
   Before the agent recommends an action, it must show the facts it used: source messages, customer record, linked documents, missing information, and assumptions.

   The agent should not say, “I found the issue and handled it.” It should say, “I found three open tickets, the last renewal date, and a draft answer. I could not verify whether the account has an approved exception.”

   This stop catches the most common operational failure: correct reasoning based on incomplete or wrong data.

3. Stop 3: Explicit action approval
   The agent posts the exact action it wants to take. A named person approves, rejects, or requests a revision. “No response” must never mean approval.

   This is the critical boundary for customer-facing, financial, or destructive actions.

4. Stop 4: Human-owned exception closure
   If the action fails, times out, hits conflicting data, or triggers a policy rule, the agent stops and creates an exception for a person to resolve.

   The agent should not retry a customer email six times, guess which duplicate CRM record is correct, or compensate for a failed invoice update by creating a second invoice.

NIST’s AI Risk Management Framework organizes risk management around “Govern, Map, Measure, and Manage.” You do not need an enterprise governance program to apply that idea. For a 3-person or 10-person company, the four stops create a practical version: define the boundaries, expose the context, approve consequential work, and own exceptions.

Build the agent as a state machine, not a chat prompt

The reliable way to build a Slack agent is to model its workflow as explicit states with allowed transitions. A prompt can produce a useful recommendation, but it cannot safely replace workflow rules, approval records, idempotency checks, and timeout behavior.

Here is the state model I use for operational automations such as Gmail-to-Telegram review flows, lead follow-up systems, and invoice exception queues:

workflow: customer_escalation_reply

states:
  - received
  - scoped
  - researching
  - proposal_ready
  - awaiting_approval
  - approved
  - executing
  - completed
  - rejected
  - expired
  - exception

transitions:
  received:
    - scoped
    - rejected

  scoped:
    - researching
    - rejected

  researching:
    - proposal_ready
    - exception

  proposal_ready:
    - awaiting_approval

  awaiting_approval:
    - approved
    - rejected
    - expired

  approved:
    - executing

  executing:
    - completed
    - exception

Each state should have a record in a database, not only a message in Slack. Slack is excellent for visibility and approvals. It is not your durable workflow engine.

A minimal record can look like this:

{
  "run_id": "run_01JZK4Y8W7A9",
  "workflow": "customer_escalation_reply",
  "slack_channel": "C0123456789",
  "slack_thread_ts": "1784929200.001200",
  "trigger_user": "U0123456789",
  "status": "awaiting_approval",
  "customer_id": "cus_8492",
  "proposed_action": {
    "type": "send_email",
    "to": "customer@example.com",
    "subject": "Update on your support request",
    "body_hash": "sha256:4e322..."
  },
  "approval_expires_at": "2026-07-26T18:00:00Z",
  "approved_by": null,
  "executed_at": null
}

The body_hash matters. It prevents a subtle failure mode: an operator approves one draft, but the agent regenerates or changes the content before sending.

Approval should bind to the exact payload that will be executed.

def approve_action(run, approver_id, approved_hash, now):
    if run.status != "awaiting_approval":
        raise ValueError("Run is not awaiting approval")

    if now >= run.approval_expires_at:
        run.status = "expired"
        return run

    if approved_hash != run.proposed_action["body_hash"]:
        raise ValueError("Draft changed after review")

    run.status = "approved"
    run.approved_by = approver_id
    run.approved_at = now
    return run

This is unglamorous engineering. It is also what separates a working system from a demo that happens to look good in a Slack thread.

An approval message must show the decision, not hide it in a button

A human can only approve responsibly when the approval request states the source, recommendation, exact action, and expiration time. “Approve?” is not enough context for an employee to authorize an email, billing change, or CRM update.

For a customer escalation, the Slack message should be compact but complete:

Customer escalation: Acme Studio
Source: #customer-escalations thread, 6 messages
Account: Pro plan, renewal due August 14
Open tickets: 3
Last outbound reply: July 24, 2026

Finding:
The customer reports duplicate charges. I found two invoice records
with the same reference but cannot confirm settlement status.

Recommended action:
Send a reply confirming investigation and state a response deadline.
Do not promise a refund.

Exact action on approval:
Send the attached email draft to billing@acmestudio.com.

[Approve send] [Request revision] [Reject]
Approval expires: 4:00 PM UTC

The agent should also distinguish between a draft and an executed action in its language.

Bad:

I have contacted the customer about the duplicate charge.

Good:

Draft ready. No email has been sent.

After approval and execution:

Email sent at 2:14 PM UTC by workflow run_01JZK4Y8W7A9.
Approved by: Maya Chen.

That wording becomes important six weeks later when someone asks whether a customer was notified, whether the message was only drafted, or who approved it.

For Slack implementations, interactive buttons should submit a server-side action containing the workflow run ID and the approved payload version. Do not put credentials, customer data, or the full action payload in button metadata.

def handle_slack_approval(payload, db):
    run = db.get_run(payload["actions"][0]["value"])

    if payload["user"]["id"] not in run.allowed_approvers:
        return {"text": "You are not authorized to approve this action."}

    approve_action(
        run=run,
        approver_id=payload["user"]["id"],
        approved_hash=run.proposed_action["body_hash"],
        now=utcnow()
    )

    db.save(run)
    enqueue("execute_approved_action", {"run_id": run.run_id})

    return {"text": "Approved. The action is queued for execution."}

The queue is intentional. The Slack button handler should record approval quickly, then let a separate worker execute the external action. This avoids duplicate sends if Slack retries a request or your worker temporarily fails.

Timeouts, idempotency, and permissions matter more than model choice

The operational safety of a Slack agent comes mostly from timeout rules, scoped credentials, and duplicate prevention. A stronger model may produce a better draft, but it cannot fix an integration that sends the same email twice or lets a broad API token modify every CRM record.

Start with timeouts. A proposal waiting for approval should expire automatically. The safe default is inactivity, not action.

def expire_unapproved_runs(db, now):
    pending_runs = db.find_runs(
        status="awaiting_approval",
        expires_before=now
    )

    for run in pending_runs:
        run.status = "expired"
        run.expired_reason = "No explicit approval received"
        db.save(run)
        post_to_slack(
            channel=run.slack_channel,
            thread_ts=run.slack_thread_ts,
            text=f"Approval expired for {run.run_id}. No action was taken."
        )

Then add idempotency. Every external action needs one unique execution key. If the worker receives the same job twice, it must detect that the action was already completed.

idempotency_key = (
    f"{run.run_id}:"
    f"{run.proposed_action['type']}:"
    f"{run.proposed_action['body_hash']}"
)

if execution_store.exists(idempotency_key):
    return "Already executed"

send_email(
    to=run.proposed_action["to"],
    subject=run.proposed_action["subject"],
    body=render_approved_body(run)
)

execution_store.record(idempotency_key)

Finally, reduce permissions at the integration layer.

A practical permission model

• Slack token: Read only the channels where the workflow operates; post only in its designated channels.
• CRM token: Read customer and deal data first. Add write access only for one approved object type, such as creating a follow-up task.
• Email token: Allow draft creation during early testing. Add send permission only after the approval path and audit log work.
• Billing token: Keep billing actions out of version one. Invoice and payment workflows need additional accounting controls.
• Database access: Store only the fields required for the workflow. Avoid copying your entire customer database into a prompt context.

If you use OAuth-based integrations, create a separate application identity for the agent. Do not connect it through the founder’s personal admin account. When the founder leaves, changes role, or resets credentials, your automation should not become an undocumented dependency.

Test one narrow loop before you let the agent run for days

Your first agent should automate one repetitive loop from trigger to approved action to visible completion. Long-running autonomy is useful for monitoring, research, and preparation, but short loops earn trust faster because the failure modes are easier to see and fix.

A good first build is a lead follow-up workflow:

1. A qualified form submission enters the CRM.
2. The agent checks for duplicate records and recent outreach.
3. It researches the prospect’s company using approved sources.
4. It drafts a personalized follow-up email.
5. It posts the draft to the appropriate Slack thread.
6. A salesperson approves, rejects, or edits it.
7. The system sends the approved version once.
8. The CRM receives a logged activity record with the run ID.

Test this workflow against at least these cases before using real customer data:

Track a few operational numbers from day one:

• Number of workflow runs started
• Number approved, rejected, expired, and sent to exception
• Median time from proposal to approval
• Number of duplicate-prevention blocks
• Number of manual revisions before approval
• Number of external actions completed

Those numbers tell you whether the automation is actually reducing work or merely moving it into Slack.

A high rejection rate is not necessarily bad in week one. It may mean your scope is too broad, your data is incomplete, or the agent’s recommendation format needs work. The failure becomes useful because it is visible before it reaches a customer.

Why bizflowai.io helps with this

bizflowai.io builds approval-first workflow automation for small businesses that need agents to prepare work without silently taking control of customer communication, CRM updates, or operational records. For clients, this includes narrow Slack and inbox triggers, structured research and draft generation, explicit approval messages, timeout handling, execution logs, and exception queues—so the automation remains inspectable after the first demo and after the hundredth workflow run.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.