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.
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.
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, never shown to the model or written to logs.
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 microVM sandbox, and only the prepared order and Slack post it's explicitly allowed to send leave the sandbox.
- Scoped secrets. The ordering-account credential is encrypted in the secrets manager and injected into the sandbox at runtime, never exposed to the model 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
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.
Read more
How we keep our docs in sync with the code
The docs agent we run on Kortix — connected to GitHub and our codebase. Once a day it checks the code that landed since its last run and updates the docs those changes affected, opening a PR for review.
How we QA every pull request automatically
The QA agent we run on Kortix — connected to GitHub and our test environment. It checks out each PR, runs the suite, exercises the change, and posts the result.
How we run operations from Slack
A single agent reachable from Slack, with scoped access to our database, Stripe, Linear, and GitHub. Ask in a thread and it runs the task across whatever platforms it needs.
Engineer your first loop
Give your company a workforce of agents that run on a schedule, ship real deliverables, and improve one reviewed change at a time. Free to self-host, managed cloud from $20.
Open source · SSO · RBAC · on-prem · no lock-in