← Back to essays

Start Agent Work in the Channel, Not the Terminal

·3 min read·By Ry Walker

The best place to start an agent task is not a terminal. It is the channel where the conversation is already happening.

Here is the pattern I see inside every knowledge-work organization. A customer-facing person notices a problem. A discussion starts in Slack or Teams between them and an engineer. Then the context gets squeezed into a ticket, the ticket sits in a queue, and by the time anyone picks it up, half the nuance from the original thread is gone. The handoff is lossy because the discussion and the work happen in two different places.

When the agent lives in the channel, that gap closes. Mention the agent in the thread and the discussion becomes the task. The agent spins up a cloud environment with the full codebase, does the work in the background, and comes back with a reviewable pull request. Nobody transcribed anything. Nobody lost the context. The people who understand the customer problem kick off the work directly, and engineers stay in the loop as reviewers and approvers. That is agents breaking out of engineering in practice, not theory.

The second-order effect matters more than the convenience. Work started in a channel is multiplayer by default. If a product person takes an agent down the wrong path, a senior engineer scrolling past can jump into the same session and redirect it mid-task. Compare that to an agent running in someone's private terminal, where the first time anyone sees the work is when the PR lands, which is the most expensive moment to discover it went sideways. Supervision at scale requires visibility, and visibility is what channels give you for free. This is how one human ends up supervising many agents: not by watching dashboards, but by working where the sessions are public.

We push our own team to start everything from Slack for exactly this reason, and it takes pushing, because the terminal wins by habit. I still catch myself finishing a task in a local CLI simply because I was already sitting in it when the idea struck. That is the bar a channel-first workflow has to clear: mentioning the agent in the thread must be faster and better than reaching for the terminal you already have open. The terminal is a single-player tool. The organization is a multiplayer system. Put the agents where the conversations already are, and the whole company becomes the input layer.

Key takeaways

  • Agent tasks started in chat are visible by default, so a senior engineer can redirect a session before it goes down the wrong path.
  • The lossy handoff between customer-facing teams and engineering disappears when the discussion itself becomes the coding session.
  • A terminal on one laptop is a single-player tool, and single-player tools cannot carry an organization's agent workflow.

FAQ

Why start agent tasks in Slack instead of a terminal or IDE?

Visibility and supervision. A session started in a channel is multiplayer. Teammates can see it, jump in, and correct course mid-task. A session in a private terminal is invisible until the pull request lands, which is the worst possible moment to discover it went the wrong direction.

Does this mean non-engineers write production code?

It means non-engineers can initiate work that lands as reviewable pull requests. Product managers and customer-facing staff describe the problem where the discussion already lives, an agent does the work in a cloud environment, and engineers review before anything merges. The approval gate stays with engineering.

Tembo

Drowning in pull requests that need your review? Try Tembo Review, a beautiful AI-assisted PR review tool unlike anything you’ve used.