Slack/CLI/Web invocation → PR
How to trigger AI agent tasks from natural language interfaces - a Slack message, a CLI command, a web form - and have the agent autonomously produce a pull request.
- ·Unattended agents (Stripe Minions model, Cursor Automations) execute tasks without developer presence
- ·Agents are invocable from at least two channels (Slack, CLI, Web, PagerDuty)
- ·Each developer runs 3-5 parallel agent sessions concurrently
- ·Agent task completion rate without human intervention exceeds 60%
- ·Agent invocation produces a PR within a defined SLA (e.g., under 30 minutes for standard tasks)
Evidence
- ·Agent invocation logs from multiple channels with timestamps
- ·Dashboard showing parallel agent session counts per developer
- ·PR history showing agent-authored PRs merged without synchronous developer oversight
What It Is
Slack/CLI/Web invocation is the interface layer that makes AI agents accessible to the full development organization, not just developers comfortable running CLI tools. Instead of opening a terminal, cd-ing to the project root, and running a complex agent command, a developer types /ai implement the new user preferences endpoint per JIRA-4821 in Slack, or clicks "Run" on a web dashboard, or runs ai-task create --from-ticket JIRA-4821. The agent receives the task, works autonomously, and posts a link to the PR when it's done.
The key architectural shift at L4 (Optimized) is that agent invocation becomes an interface, not a workflow. The underlying agent machinery (Claude Code, context loading, sandbox creation, PR creation) is hidden behind a clean interaction surface. The developer doesn't need to know how the agent works - they need to know how to describe what they want.
This pattern is in production at companies of all sizes. Slack bot integrations that trigger Claude Code runs are a common starting point. Web dashboards where PMs can view and trigger agent tasks are more sophisticated implementations. The common thread: the requester describes the desired outcome in natural language, and the system handles the entire implementation lifecycle.
At L4, these invocation paths connect to an automation layer that handles context loading, sandbox provisioning, agent execution, test running, and PR creation as a pipeline. The human provides the intent; the system provides the execution.
Why It Matters
Multi-interface invocation multiplies the reach of agent capabilities beyond the developer who runs them:
- Democratizes agent access - non-developers (PMs, QA, DevRel) can request tasks without knowing CLI syntax or agent configuration
- Reduces invocation friction - a Slack message is lower friction than any terminal workflow; lower friction means higher usage
- Enables async task delegation - fire-and-forget invocation means developers don't wait for agents; they get a notification when the PR is ready
- Creates an audit trail - every Slack command or web form submission is logged; you have a record of who requested what, when, and with what result
- Bridges AI to existing workflows - developers already live in Slack; bringing AI invocation there meets them where they are
The PR as output is equally important. The PR is the canonical interface for code change review in modern engineering. By having agents produce PRs - with a task description, diff, and test results - the review workflow is unchanged from human-authored PRs. The agent fits into the existing process rather than requiring a new one.
Design your Slack bot or web interface to require the same task specification structure your agents need: what, where, acceptance criteria, what not to touch. Enforce structure at the interface layer to prevent vague invocations that produce vague results. A form with required fields beats a free-text message.
Getting Started
- Build or adopt a Slack bot framework - GitHub has official Copilot extensions; Claude Code can be integrated via webhooks using the Anthropic API. Start with a simple bot that receives
/ai <task>and runs Claude Code with that task description. Output: a PR link posted to the channel. - Define your invocation format - Establish a standard task description structure. A good format:
[verb] [what] [where] [verification criteria]. Example: "implement user preferences endpoint in/api/users/preferencessuch that the acceptance test intests/api/user-preferences.spec.tspasses." - Wire up the CI gate - The PR created by the agent should automatically run CI. The Slack bot should report CI status back to the channel: "PR #1234 created - CI: running... ✓ CI passed, ready for review."
- Implement sandbox isolation - Each Slack-triggered task runs in an isolated environment (git worktree, ephemeral VM, or Docker container). Isolation prevents concurrent tasks from conflicting and limits blast radius of agent errors.
- Build the review interface - Add a lightweight PR dashboard (or use GitHub Projects) filtered to agent-generated PRs. This gives reviewers a clear queue of agent work to review, separate from human-authored PRs that may need different review attention.
- Start with one high-value task type - Before building a general-purpose interface, pick one specific task (e.g., "write tests for this function") and build the Slack integration for exactly that. A specific integration that works reliably is more valuable than a general interface that works sometimes.
Common Pitfalls
Building the interface before the agent works reliably. A Slack bot that triggers a flaky agent is worse than no Slack bot - it creates failed invocations in a visible, shared space and damages confidence in the system. Build the Slack interface only after the underlying agent reliably completes the target task type in isolation.
No visibility into agent progress. If a Slack invocation triggers a 20-minute agent run with no intermediate feedback, developers will assume it failed and retry, creating duplicate agents. Implement progress updates: "Agent started → Agent writing tests → Agent running CI → PR created." Even a simple heartbeat message prevents this.
Ignoring rate limiting and cost control. Every Slack invocation triggers an API call to a language model. Without rate limiting, a developer who mistypes a command and retries 10 times has run 10 agent sessions. Implement per-user rate limits, task queuing, and cost visibility at the interface layer. Show developers the estimated cost of each invocation before they confirm.
Conflating "invoked from Slack" with "no review needed." The interface (Slack, CLI, web) changes how tasks are triggered; it doesn't change the review requirements. Every agent-generated PR requires human review before merge. Make this explicit in the Slack bot's PR notification: "Agent PR ready for review - do not merge without reviewing the diff."
How Different Roles See It
Bob loves the concept of Slack-triggered agent tasks but is worried about control. What happens when someone requests something the agent shouldn't do? What if an intern fires off a Slack command that triggers a dangerous refactoring of the auth system?
What Bob should do: Implement access controls at the interface layer. The Slack bot should require: (1) a valid JIRA ticket number in the task description (proving intent has been tracked), (2) repository-level permissions check (you can only trigger agents on repos you have write access to), and (3) task scope validation (tasks touching security-critical paths require senior engineer approval before execution). These controls are straightforward to implement and address Bob's concerns without limiting the productivity benefit. Bob should also establish a "task type allowlist" - a set of task patterns that are pre-approved for autonomous execution, with everything else requiring manual escalation.
Sarah sees multi-interface invocation as the key to making AI productivity scale across the organization without requiring every employee to become a prompt engineer. But she needs to demonstrate that the interface layer adds business value beyond what developers already have with the CLI.
What Sarah should do: The business case for multi-interface invocation is adoption breadth. Track: (1) the number of unique agent task requesters per month (should increase as Slack access democratizes invocation), (2) the distribution of requesters by role (developers, QA, PM - broader distribution means broader value), and (3) time-from-request-to-PR by task type (measures system efficiency). Sarah should compare this to the CLI-only baseline: how many developers were actively using CLI agents? The Slack interface should show a step-change increase in both unique users and total task volume. That increase is the business case - wider access to agent productivity translates to organizational-scale throughput improvement.
Victor has already built a personal wrapper script that takes a task description, runs Claude Code in a worktree, and creates a PR - the same pipeline the Slack bot would use. He runs it from his terminal 10-15 times per day. He wants to scale this to the team without everyone needing to set up and maintain their own scripts.
What Victor should do: Victor's personal script is the prototype for the team's Slack integration. He should refactor it into a proper service: Slack webhook handler, task queue, agent executor (using the existing Claude Code integration), and PR creator. The engineering investment is 2-3 days to build a reliable first version. Victor should deploy it as an internal service (not a production product - it's internal tooling) and run it for one team for one month to learn the real failure modes. His advice on interface design: require structured task descriptions (don't accept free-text), implement idempotency (duplicate invocations don't create duplicate agents), and make every invocation traceable to a requester and a ticket.
Further Reading
From the Field
Recent releases, projects, and discussions relevant to this maturity level.
Where does your team actually sit on this?
This guide describes one level of one area. Run the assessment to place your team across all 16 areas, see which gates you have passed, and get a report you can take to your stakeholders.