A command surface for your agents: Slack in, Linear out.

The gap shows up the same way in most setups. Someone types a request into a thread. An agent could act on it, but nothing routes the request anywhere durable, and nothing confirms it happened. The thread scrolls away. A week later the same request gets typed again, because no one remembers whether it was done.

The shape that closes it.

Two private channels, each with one job. A command lane is where a request gets dropped, in a small structured block: what to do, and optionally which project and how urgent. An activity lane is where ticket movement shows up, so status is visible without opening another tab.

An in-session agent reads the command lane, does the work, files or updates a ticket for it, and replies in the thread with the link. A sentence typed in passing becomes a tracked, assignable, searchable record, with the filing conventions and the voice rules applied on the way through. The chat stays where a human already is. The system of record stays where work is supposed to live.

The convention has to be small enough to actually use.

A request format that requires filling out six fields never gets used at 4pm when someone is already moving fast. The convention that works is closer to a fenced block with one required field, the task itself, and everything else optional: a project name, a priority. An agent that already knows the filing conventions can fill in the rest.

The one-required-field design matters more than it looks. Every optional field you make required is a request someone decides not to bother typing, and an unrouted decision made in a hallway instead of in the system.

The honest architecture limit.

This runs in-session, not as an always-on bot. An agent reads the channel and acts while a working session is open. It is not a service sitting on an events subscription, answering at any hour whether or not anyone is watching. That is a materially different, and materially more expensive, thing to build: a deployed runtime, its own credentials, its own failure modes, its own monitoring.

Naming that boundary matters, because a lot of "AI agent in Slack" demos quietly assume the always-on version and skip the cost of standing it up. The in-session tier is worth running first because it delivers most of the value at a small fraction of the operational weight, and running it first is what tells you whether the always-on tier is worth building at all, instead of guessing.

How Rarefied Earth runs this.

The firm stood up exactly this: a private command channel and a private activity channel, with a documented request convention (a fenced task block, project and priority optional) pinned where anyone dropping a request can see it. An in-session agent reads the command channel, does the work, files or updates the matching ticket under the firm's filing discipline, and replies in the thread with the issue link.

This is Tier 1, and it is live. Tier 2, an always-on bot that answers without a live session open, is designed and scoped but deliberately not built yet. The firm treats that as the correct order: prove the in-session version pulls its weight before paying for the always-on one. Whether Tier 2 ever gets built depends on whether the request volume through Tier 1 actually justifies it, not on whether the idea sounds good.

What an operator can do this week.

Create one private channel as a command lane. Adopt a request convention with exactly one required field. Point an agent at the channel: read it, act on the request, file the result as a tracked issue, reply in the thread with the link. Run it in-session for a while before considering an always-on bot. If the request volume never justifies the always-on tier, that is a useful answer too, and a cheaper one to learn than building it first and finding out after.