Intake Is a Listener on Slack, Linear, GitHub, and Cron, Not a New Tool
Intake is a set of listeners on the surfaces your team already uses, not a product surface you build for the agent. Over 1,300 pull requests merged at Stripe each week are completely minion-produced, containing no human-written code, and the most common way one starts is an engineer tagging a Slack app in the thread that was already discussing the change (Stripe).
Every production system in the corpus converged on this independently.
Brex named the pattern in one sentence
Brex's platform description is the cleanest statement: "Tasks come in from Slack, Linear, GitHub, or a cron job. The orchestrator routes them to the agent pool. Each task gets its own RDE" (Brex). An RDE is Brex's per-task isolated workspace.
The user experience is a Slack message in, a finished PR out: "You send a Slack message describing a bug or a refactor. The system spins up a dedicated environment, assigns an agent, and gives it the full toolchain." The engineer's next interaction is a human review of a finished PR.
The orchestrator, not the human, does the assignment work: it maps an inbound message to an environment, an agent, and an owner. That last part is load-bearing, because Brex states as a governance principle that agent work "needs to be attributed back to an actual human and not just a bot." Routing is where that binding happens; see binding to the human.
The same channels show up everywhere
| Platform | Intake channels | Source |
|---|---|---|
| Brex | Slack, Linear, GitHub, cron jobs | Brex |
| Stripe minions | Slack (primary), CLI, web UI, internal docs platform, feature flag platform, internal ticketing UI | Stripe |
| Spotify Honk | Slack and GitHub Enterprise, via MCP | Spotify |
| GitHub Copilot cloud agent | Issue assignment ("Copilot" as assignee), @copilot PR comments, scheduled or event-triggered automations, security-campaign alerts, external tools | GitHub Docs |
Two details make the chat entry point more than a convenience:
- Context rides along. A Stripe minion kicked off from a Slack thread "will be able to access the entire thread and any links included as context." The thread is the task description.
- Intake can refine. At Spotify, the user "first talk[s] to an interactive agent that helps to gather information about the task at hand," and that interaction produces the prompt handed to the coding agent. Intake and scoping can be the same conversation.
Lowering the intake bar widens who can file work. Spotify reports product managers "can now propose simple changes without cloning and building repos on their laptops." When intake is a chat message, the set of people who can delegate engineering work stops being the set of people with a working dev environment.
Cron and events make intake proactive
Half of Brex's intake list isn't a human at all. Cron jobs file tasks on a schedule; GitHub events file them on triggers. Stripe wired this into its quality loop: "when our CI systems detect flaky tests, we create automated tickets that prompt users to fix the problem with a minion." GitHub Copilot supports automations that run "on a schedule or in response to events such as an issue being opened," and security campaigns can assign code-scanning alerts directly to the agent.
The system can file its own backlog. Flaky tests, security alerts, and scheduled maintenance become tasks the moment they're detected, instead of waiting for a human to notice, triage, and copy them into a tool. What a trigger buys you only pays off if the agent can then iterate unattended, which is the feedback loops chapter.
Routing assigns an environment, an agent, and a human
Accepting a task means assigning three things at once. Across every system above, the orchestrator binds:
- Isolated environment. Brex: "each task gets its own RDE." See one environment per task.
- An agent. Pulled from a pool, or picked from several specialized identities.
- Accountable human. By default the person whose Slack message, issue assignment, or ticket created the task.
The payload usually already names the agent. An issue carries an assignee, a Slack message carries the mentioned handle, and GitHub's cloud agent is invoked by putting "Copilot" in exactly that field (GitHub Docs). The trigger declares which payload field carries the identity. The router resolves that field against the directory of agent identities by a stable key: the agent's own handle on that platform, matched case-insensitively. Two rules keep the lookup from misrouting quietly:
- Default on no match. A handle no agent owns, or one whose agent is disabled, routes to a designated default identity instead of dropping the task.
- Signal the miss. Every failed resolution emits an event, so unroutable handles surface for someone to fix.
The orchestrator is thin. It is plumbing between where work appears and where work runs, and Brex's MVP version of it was literally three Python scripts.
One gap: the corpus is silent on prioritization. Nobody published what happens when inbound tasks exceed agent-pool capacity, how queues are ordered, or whether a cron-filed task can starve a human-filed one. If you build this, you will decide that yourself.