# How we run day-to-day operations from a Slack thread One agent you can call from Slack, with narrow access to our database, Stripe, Linear and GitHub. Describe the job in a thread and it carries it out across every tool involved. Canonical page: https://themachine.myapps.ai/use-cases/slack-control-pane 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. - **Team:** Machine - **Control surface:** Slack - **Connected systems:** Database · Stripe · Sandboxes · Linear · GitHub - **Setup per platform:** Connect it once and the agent can use it ## 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 - **One thread:** Any job across tools, asked for in everyday words - **Connect once:** Each new tool adds a new skill, with nothing to build - **5+ systems:** Database, Stripe, sandboxes, Linear and GitHub, all through one agent 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.