# How we keep the office stocked People request snacks through a Slack shortcut, and an agent batches the requests weekly, prepares an order, and posts it for the office manager to approve before placing anything. Canonical page: https://kortix.com/use-cases/office-snacks Keeping an office stocked is a small recurring chore that never quite has an owner. Requests come in over Slack, hallway conversations, and sticky notes; the office manager reconciles them into an order; and half the time a request is forgotten by the time the order goes in. It's low-stakes, but it's steady work. We handle it with an agent on Kortix. People request snacks through a Slack shortcut, and once a week the agent batches every request, prepares an order, and posts it for the office manager to approve. Nothing is placed until a person signs off. - **Team:** Kortix - **Control surface:** Slack - **Connected systems:** Slack · Ordering account - **Mode:** Weekly batch · human-gated ## The problem Snack requests arrive one at a time and out of band. Someone asks in a channel, someone else mentions it in passing, and the office manager is left assembling a list from memory. Requests get dropped, duplicates slip through, and the order goes in later than it should. The task is simple but constant. It needs one place to collect requests, a way to batch them on a schedule, and a person's sign-off before any money is spent — none of which a shared spreadsheet or a recurring calendar reminder actually provides. ## What we built Requests come in through a Slack shortcut, so there's one place to submit them. Once a week a cron trigger spawns an isolated session that collects the week's requests, prepares an order against the ordering account, and posts the draft in Slack for the office manager to approve. Only after approval does it place anything. ## How it works ### Collect requests through a Slack shortcut Slack is connected as a **channel**, and a shortcut is the way people submit requests. Each submission is collected against the week's batch. There's one place to ask, and nobody has to track requests in their head. ### Batch them on a weekly cron A **cron trigger** fires once a week and spawns a fresh **session** in its own isolated sandbox. The run gathers every request submitted since the last order. One run, one sandbox, torn down when it's done. ### Give the agent the ordering rules The preferred vendor, the budget, standing staples to always include, and how to consolidate duplicate requests live as **skills** and **memory**. The rules are updated as preferences and the budget change. ### Connect Slack and the ordering account Through scoped **connectors**, brokered server-side so no raw token reaches the model, the agent can: - **Read requests from Slack** — the week's submissions from the shortcut. - **Prepare an order in the ordering account** — build the cart against the vendor, but not check out. - **Post to Slack** — the draft order for the office manager to review. ### Approve before it places anything The prepared order stops at a **human approval gate** in Slack. The office manager sees the full cart and the total, and nothing is purchased until they approve. Credentials for the ordering account are encrypted in the secrets manager and injected at runtime, scoped to the agents you grant them to. > **The pattern** > Collect requests through a Slack **channel** shortcut, batch them on a **cron > trigger**, keep the vendor and budget rules in **skills** and **memory**, and hold > the order at a **human approval gate** before it spends. One place in, one approved > order out. ## Guardrails Because the agent can prepare an order that spends money, the controls matter even for a small chore: - **Isolation.** Each weekly run executes in its own isolated sandbox, and only the prepared order and Slack post it's explicitly allowed to send are written back out. - **Scoped secrets.** The ordering-account credential is encrypted in the secrets manager and injected into the sandbox at runtime, scoped to the agents you grant them to or the logs. - **Human approval gates.** No purchase is placed until the office manager approves the draft order in Slack. - **Everything is code.** The vendor, the budget, the staples, and the batching schedule are files in the repo — versioned and changed through a reviewed **change request** rather than a dashboard setting. ## The outcome - **Weekly:** Requests batched into one order on a schedule - **One place:** Every request comes in through a Slack shortcut - **Approve first:** Nothing is purchased without a person signing off Requests stop getting lost, duplicates get consolidated, and the office manager reviews a finished order instead of assembling one. The spending step stays behind a person, so the automation saves the busywork without ever placing an order on its own.