Five steps.
Then it’s in your Slack.
Deploying an agent is not an integration project. The longest step on your side is creating a Slack app, which is about ten minutes of clicking in your own workspace. The agent is already built. Steps four and five depend on its published runtime and your hosting configuration, which the portal checks separately.
Saved progress. Explicit approvals.
The execution layer that keeps agent work moving—with scoped permissions, spending limits, and a record of the task. Starting with the Processor application-readiness pilot in Flows.
Preview before deliveryStart in shadow mode to inspect readiness evidence and proposed operations follow-ups without sending a message.
Approve the exact actionEach Slack delivery requires approval of the message and destination. Permissions and supporting evidence are checked again before dispatch.
Follow the same taskSee progress and model spending as application information changes. Reassess or cancel a task from its run detail.
Workspace setup is required. Broader fleet support is planned; the pilot assesses readiness and prepares operations follow-ups. Financing decisions remain with people.
What you do, and what we do
Two of the five steps are yours. We are explicit about which, because “white-glove onboarding” usually means nobody wrote down who does what.
Pick an agent
You
Choose a listing from the catalog. Each one names what it does, what it needs from you, and what it costs before you commit.
- Catalog separates agent readiness from runtime deployment availability
- No agent deploys without a named owner in your org
Create its Slack app
You · ~10 minutes
We give you a prefilled Slack app manifest and a deep link. You create the app in your own workspace, turn on Socket Mode, and paste two tokens back to us.
- The app lives in your workspace under your control — you can revoke it any time
- One app per agent, so events never get split between two consumers
- We validate both tokens live before anything is provisioned
Set the roster and the channels
You
Name who can talk to the agent and who can approve an elevated action. Pick the channel convention — one channel per deal is the pattern the Processor agent is built around.
- Approvers are enforced in the agent’s own config, not just in copy
- Anything that leaves the channel needs a human signature
We provision it
Us · deployment setup
Hosted deployment requires a published runtime image and a configured hosting environment. The intended layout is one dedicated container and memory volume per organization, with scoped network access. Confirm those requirements with our team before starting a deployment; saving a local configuration alone does not start an agent.
- One tenant per instance — no shared container, volume, or secret store
It says hello
The agent
The agent posts its introduction in the channel you chose and starts answering. From there it is a coworker you talk to, not software you operate.
- Task-level telemetry shows what it did, what it flagged, and what it cost
- Health reporting is designed, not running — there is no heartbeat route yet
A deal channel, worked
This is the shape of the work: documents land in a channel, the agent files them, says what is missing, and stops short of anything that needs a human.
Still missing: voided check, YTD P&L.
FILED_FLAGGED — May statement is a scan; totals unreadable on page 2.
One tenant per instance
Hosting someone else’s agent means holding their deal data. Six boundaries hold that line — container and volume, egress policy, provider credentials, secret delivery, deployment records, telemetry scope — and they are written up, with what is enforced separated from what is designed, on the Security page.