Ubie's article, Design and Implementation of an Agent Capable of Troubleshooting Infrastructure on Slack, published on Zenn on May 11, 2026, is a practical report on an AI agent autonomously performing infrastructure investigations and answering inquiries triggered solely by Slack mentions.
Historically, even across our company's custom SRE managed operations engagements, "who handles initial response for nighttime and weekend infrastructure inquiries" has been a major operational burden. Combining ChatOps with AI agents reveals a realistic division of labor: "Slack mention → AI handles initial response → escalate to a human only when necessary." Complementing the workplace AI explored in Salesforce Slackbot vs. Workspace Intelligence, this represents an application specialized for SRE and operational environments.
Why Slack ChatOps × AI Agent resonates in SRE client engagements
| Challenge | Impact of ChatOps × AI Agent |
|---|---|
| First-line response at night / on holidays | AI operates 24/7 to handle initial responses |
| Siloed infrastructure knowledge | Consolidated into the agent |
| Scattered inquiries | Consolidated in Slack + automatically classified |
| On-call burnout | Unnecessary pages reduced by 50% to 70% |
| Dispersed records | Threads automatically become incident response logs |
In particular, "on-call burnout during nights and weekends" is a critical management challenge directly linked to talent retention rates. Automating first-line response with AI agents directly contributes to preventing turnover on SRE teams.
Three architectural innovations from Ubie's case study
Innovation 1: Safely controlling autonomous execution at the network layer
This design restricts allowed domains and allowed commands at the network layer before the agent calls any arbitrary command or API. This makes it possible to physically stop at a lower layer any "agent runaway behavior." This is the operational edition of "agent boundary design" discussed in AWS Security Agent Client Projects.
Innovation 2: Making Slack threads the primary source of truth for response logs
By recording the agent's investigation logs, reasoning processes, and executed commands chronologically within Slack threads, teams obtain postmortems, audit trails, and knowledge capture with zero additional effort.
Innovation 3: Natural UX for human handoffs
When the agent determines it has "low confidence," it automatically mentions a human. Because the thread context is handed off intact, humans can respond while "already grasping the full situation from the start."
Standard technology stack set for custom development
| Layer | Recommended technology | Alternative |
|---|---|---|
| Slack integration | Slack Bolt + Block Kit | Socket Mode |
| Agent foundation | Claude Agent SDK / Mastra | LangGraph |
| LLM | Claude Sonnet / GPT-5.5 | Gemini 2.5 |
| Tool integration | MCP server | OpenAI Function Calling |
| Network controls | Cilium / NetworkPolicy | VPC Security Group |
| Observability | OpenTelemetry + Langfuse | Datadog |
| Audit Logging | Slack Audit API + S3 Object Lock | CloudTrail |
In particular, "standardizing tool integrations" via MCP servers is rapidly becoming the standard pattern to broaden integration scope while preventing vendor lock-in, as explored in the Complete MCP Guide.
Four implementation phases built in custom development
Phase 1: Current-state investigation (3 weeks)
Categorize Slack inquiries from the past three months and measure "the percentage that can be fully resolved via AI first-line response." Agree on the basis for ROI calculations with the client.
Phase 2: Tool suite implementation (6–8 weeks)
Convert frequently used investigation tools—such as Kubernetes, AWS, GCP, Datadog, and PagerDuty—into MCP servers. Narrow the initial scope to read-only operations.
Phase 3: Agent implementation and safety controls (4–6 weeks)
Implement the core agent and install dual safety controls across the network layer and IAM layer. Run shadow operations in a staging environment for 2 to 3 weeks before deciding on production deployment.
Phase 4: Operational handover and continuous improvement (monthly)
Analyze the agent's "low confidence" assessments to determine "which tools should be converted to MCP next," and continuously expand the scope of coverage.
Six clauses to include in client contracts
| Clause | Details | What the client should verify |
|---|---|---|
| Agent permission scope | Boundaries for read, write, and execute permissions | Alignment with existing IAM |
| Escalation SLA | Notification speed when confidence is low | Acceptable tolerance for business impact |
| Response log retention | Slack threads + audit logs | Retention period and costs |
| Tracking model updates | Re-evaluation frequency when LLMs change | Responsibility for evaluation effort |
| Incident shutdown | Immediate shutdown flow in runaway scenarios | Contact channels and authorized personnel |
| Data egress scope | Confidentiality classification of information sent to LLMs | Compliance requirements |
Which projects it fits and which it does not
| Suited projects | Unsuitable projects |
|---|---|
| Uses Slack as the internal communication foundation | Exclusively uses Microsoft Teams |
| Receives 5 to 30 infrastructure inquiries daily | A few inquiries per month; AI adoption yields no payback |
| On-call burnout has become a management challenge | Already maintains a sufficient SRE staffing structure |
| Team is accustomed to MCP and Agent SDKs | Strong organizational resistance to agent technology |
| Audit log requirements are clearly defined | Wandering due to undeveloped audit requirements |
Four common pitfalls
Pitfall 1: Granting write permissions from the start
Incidents have occurred where an agent exacerbated production outages by thinking, "I went ahead and restarted it." Enforce three mandatory steps: read-only initially → shadow operations → gradual granting of write permissions. This reflects the same philosophy as the guardrails covered in AI Agent Production DB Deletion Accident.
Pitfall 2: Leaving escalation criteria ambiguous
If the criteria for determining "low confidence" are "left up to the LLM's discretion," situations frequently arise where the AI holds onto critical incidents without alerting anyone. Rules that evaluate mechanically across three axes—confidence score + keywords + time window—are essential.
Pitfall 3: Storing audit logs solely in Slack
Because Slack retention periods depend on the client's plan, there are cases where logs disappear after 90 days. Separately implementing automated archiving to S3 or GCS is mandatory.
Pitfall 4: Making operational outsourcing contracts fully fixed-price monthly
Because inquiry volume fluctuates substantially, completely flat monthly pricing causes months where the vendor loses money and months where the client loses money to alternate. We recommend hybrid billing combining a baseline fee with excess per-ticket charges.
Summary — From manual SRE labor to an AI colleague living in Slack
Slack ChatOps × AI Infra Agent is a pattern that shifts SRE first-line response from "humans on constant standby" to "AI operating 24/7 with humans handling only exceptions." The network-layer safety controls demonstrated in Ubie's case study represent a standard pattern that can be directly applied to enterprise custom development.
If your "SRE team is burned out from nighttime on-call duties" or you "want to delegate Slack-based first-line response to AI," please feel free to reach out via our inquiry form.
Sources
- Design and Implementation of an Agent Capable of Troubleshooting Infrastructure on Slack (Zenn / Ubie)
- Custom Development Comparison of Salesforce Slackbot and Workspace Intelligence (GH Media)
- AWS Security Agent Custom Development (GH Media)
- Guardrails for AI Agent Production DB Deletion Incidents (GH Media)
- Complete MCP Guide (GH Media)
