Get Started with Bluebox in a Single Coffee Break #
If you've ever shipped a feature and held your breath waiting to see what broke in production or spent hours re-prompting your coding agent just Routines are now live in production for everyone. Get started with them from your Bluebox sidebar or start from the docs!
In this post: We’ll cover what routines are, how we use them at Bluebox and give you some inspiration to start building your own!
A routine is a recurring job for a Bluebox agent. Write the prompt once, pick a cadence, and it runs without you: a nightly log review, a Monday-morning SLO check, or an hourly backlog sweep. When it fires, you get a full agent run: the same tools, same production access, and same depth as typing the question into Bluebox’s chat yourself. It just happens automatically and at 4 a.m. instead.
Routines cover the work everyone agrees should happen, but no one wants (or has the time) to raise their hand to own it. Routines are for the recurring, postponable stuff in between building new features or resolving incidents: the massive backlog, cleaning up small issues, and checking how our last release is performing.
A routine is a whole agent focused on the job, not just a query. Bluebox agents are grounded in three systems today: your source code, your issues and pull requests (both through GitHub), and your production telemetry. All three of those are available to the routine. It can pull last night's errors, review the source code that emitted them, check whether a GitHub issue already covers it, and file a new one if not. Neither the telemetry nor the repository can explain a regression alone. The answer lives in the understanding of both systems working together.
A routine is like Pepperidge farm, it remembers. A recurring agent that starts from zero every morning quickly becomes a machine for generating duplicate tickets. It will re-find the same bug on Tuesday, Wednesday and Thursday, and you will mute it by Friday. Bluebox gives routines the means to carry state forward. A run can label itself, search its own past runs, record findings as artifacts, and read and write workspace memory. Memory makes routines more efficient, resuming from past runs, only readying what's updated since the last run, and updating issues instead of duplicating them.
Routines compound. The most valuable routines produce nothing a human ever actually reads. They keep the agent's picture of the environment up to date: the live topology, the service-to-repository map, and the runbooks so every other agent run in that workspace starts from a better foundation.
Keeping the backlog honest. The busiest routine in the fleet of routines setup is nine words long: "for each bug in GitHub with the label 'needs triage' find and set the correct workstream." We set this to run hourly, since day one. Other routines sweep new issues for duplicates and priority, or walk issues older than three weeks and comment where the description of the issue no longer matches the code.
Turning logs into filed bugs. One of our routines is a log analyzer that reads the last 24 hours of logs, throws out the known noise, and files one well-researched issue when something real shows up in the logs. Its latest catch: a webhook-triggered routine fire that gets silently dropped when the request context is cancelled during a rolling deploy, so GitHub never redelivers it. The routine found the two functions involved, confirmed 16 of 16 occurrences in the log window, verified no open issue covered it, and proposed the patch. A similar routine watching frontend errors fingerprinted 8,359 real-user events on its last run and filed nothing, because all of it matched work that was already tracked, ensuring we didn’t duplicate efforts or issues.
Asking whether the fix actually fixed it. "Check all PRs from yesterday against the issues they are supposed to solve and whether they actually solved them." Recently, this caught a merged fix that broke CI for an issue that auto-closed while the problem persisted, allowing us to fix it within the hour.
Writing the report nobody has time to write, but enables team collaboration. Daily digests, release notes, weekly summaries for management, standup prep. "Write like a teammate giving a standup update, not a release note. Positive but honest — if it was a slow day, say so."
At Bluebox, we’ve been running for ten days in production: 47 routines, 608 runs, across 19 workspaces and 23 users. Roughly one in five Bluebox agent runs is now something nobody typed!
We were wrong about what people would build. When we came up with the idea of routines, we thought they’d be used for scheduled production checks: nightly health checks, SLO reviews, and cost analysis. What our team actually built is engineering hygiene: backlogs, logs, PRs, and reports.
Open Routines in the sidebar, name it, pick a cadence, write the prompt exactly as you would type it into chat. Hit Run now to watch it work the first run before you leave it running.
Two practical notes. Every run counts against your workspace's allowance, so an hourly routine consumes your routine allowance 24 times a day. We recommend to start daily. Keep in mind that manual runs of a routine don’t change the schedule, doesn’t count toward the occurrence, and works on a routine that is still switched off. Manual runs are a great way to get creative and test things out.
And new routines are shared read-only with your workspace by default. This was one of our design choices as good prompts should be written once and reused, and a colleague seeing overnight output deserves to know what produced it. Set Visibility to Only me when you want to keep things secret and only make it visible to yourself.
Try out routines today (check-out the docs here)! Pick the recurring task you keep meaning to get to, and hand it off for good. Coding agents are genuinely good at understanding a local codebase. Point one at a repository and it can read the architecture, trace the data flow, interpret configuration, and
Bluebox, Kiro, and AWS DevOps Agent bring production intelligence directly into AI-driven software delivery. By connecting development and operations with shared runtime context, teams can build, deploy,