How we run day-to-day operations from a Slack thread
Ops jobs rarely sit inside one tool. They hop between the database, Stripe, the sandbox providers, Linear and GitHub. Bringing on a new customer means provisioning them, setting up their billing and opening an issue to track it. Getting a fix out means reviewing the PR, cutting a branch and updating the ticket. No one product does the whole job, so a person ends up as the glue, flicking between a stack of browser tabs.
We send all of this through one agent you can talk to in Slack, with narrow access to each tool we have connected. It is how we run our own operations on Machine, and any team can set it up the same way.
The problem
The jobs that cross tools are the ones that belong to nobody. "Set up this enterprise customer" involves the database, Stripe and Linear. "Ship this fix" involves GitHub, the sandbox where the bug reproduces, and the ticket that follows it. No single step is hard. The pain is in joining them up: hopping tabs, copying IDs around, and keeping everything in the right order.
The usual stopgaps don't quite get there. Internal scripts each handle one narrow job and snap whenever an API shifts. A no-code automation covers the exact flow it was designed for and nothing else. A Slack chatbot can answer questions, but it cannot carry out a multi-step job, because it has no safe way to hold keys and act across several systems.
What we built
Our Slack is hooked up to an agent with narrow access to every system we have connected. You @-mention it in a thread and explain the job in everyday words. It opens a session, a fresh cloud computer (a sandbox) just for that request, with limited access to our connected tools. It figures out the steps, carries them out and keeps you posted in the thread. Teaching it something new is as simple as connecting one more tool.
How it works
Use Slack as the place you give orders
Slack is hooked up as a channel, so a message is what starts the work. Mention the agent in any thread and that request opens a new session in a sandbox of its own. The agent stays in the thread and reports back as it goes. Each request gets its own session on its own throwaway computer.
Hook up a tool
When you want the agent to handle something new, you connect that tool to Machine one time. The database, Stripe, the sandbox providers, Linear and GitHub each become a connector, a narrow link whose keys stay on our servers so the model never sees a raw token. As soon as a tool is connected, the agent can work with it. You write no integration and look after no script.
Hand it jobs that span those tools
Once the tools are hooked up, the agent takes on work that crosses them:
- Add someone to Linear, set up the project and open the tracking issues.
- Review an open PR on GitHub, and raise its own PRs against the code when a change makes sense.
- Ask the database things like how many accounts sit on a particular plan.
- Check and change Stripe, whether that is a plan, an invoice or a subscription.
- Start a sandbox to recreate a bug or run a one-time job.
However many tools the job touches, it happens in a single thread with a single agent.
Set the limits
This agent can reach every connected tool, so we keep what it may do on a short leash. By default it is mostly read-only. Anything that moves money, touches production data or changes an account (an edit in Stripe, a merge, a query that deletes) pauses at a human approval gate right there in the thread. Credentials are stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
Run ops from one thread
Now "set up this customer" is a single message. The agent provisions them in the database, sets up billing in Stripe and creates the Linear project, holding the steps you cannot undo until someone approves. "Review this PR" gets you a code review and, where it is needed, a follow-up PR. The work lives in one thread rather than across a handful of tools.
The setup
Hook Slack up as the channel, connect each tool to Machine as a narrow connector (that is the only setup per tool), and put a person in front of every sensitive action. From then on, one agent handles jobs that cross tools, all from a thread.
Guardrails
Handing one agent the keys to the database, Stripe, sandboxes, Linear and GitHub raises real security questions. These are the controls that make it safe to do:
- Isolation. Each request runs in a sandbox of its own, on a branch of its own. A session can reach only the tools it was given, and only what it is explicitly permitted to send ever leaves it.
- Scoped secrets. Every tool's key is stored encrypted in the Secrets Manager and only handed to the agents you grant them to.
- Human approval gates. Anything that cannot be undone (money, production data, merges) needs a person to approve it in the thread.
- Everything is code. The agent's persona, skills and permissions for each tool are files in the repo. They keep their history, and changes go through a reviewed change request instead of a dashboard toggle.
The outcome
Jobs that cross tools, like onboarding, reviews, provisioning and billing changes, now happen in the same Slack thread where people were already talking about them, and the risky steps wait for a yes. Growing what it can do is a matter of connecting the next tool.
More use cases
How we answer GDPR data-subject requests before the deadline
Our Machine agent checks each GDPR access or deletion request, finds the person's data across our product database, builds the report well within the SLA and hands it to legal before anything is sent.
How we keep our docs matching what the code does
Once a day a Machine agent reads every commit merged since its last pass, finds the doc pages those changes made wrong, rewrites them and sends you one pull request to review.
How we test every pull request without lifting a finger
Our Machine QA agent works with GitHub and our test environment. For each pull request it checks out the branch, runs the tests, tries the change for real, and posts what it found.
Put your first agentto work today.
- SSO
- RBAC
- Governed agents
- Full audit trail