We're a small team of DevOps engineers who built an AI teammate that actually knows your infrastructure. This is the story of how B.O.R.I.S came to be.
We’re a small team of DevOps engineers who got tired of watching AI tools fail at the one thing they should be good at - understanding the infrastructure they’re supposed to help with. So we built something different.
B.O.R.I.S is an AI DevOps teammate that actually knows your systems, remembers your environment, and works alongside your team - not in a private chat window, but right where your engineers already communicate.
Here’s how we got here.
It started with a broken experience
About a year ago, we were experimenting with AI-powered CLI tools for troubleshooting AWS infrastructure. They worked - sort of. The problem was that every time you asked something, the tool had no idea where it was. Like a newborn baby opening its eyes: “What services are running? Let me run 30 commands to find out.”
Every conversation started from zero. No memory, no context, no understanding of your environment. As DevOps engineers, we knew exactly how frustrating this was - because we lived it daily.
So we asked ourselves: can we do better?
Four bets we made early on
We started building B.O.R.I.S around four core beliefs:
1. Data privacy matters. Your infrastructure data should stay in your AWS account, encrypted, auditable, and under your control - not shipped off to some third-party cloud.
2. Context is everything. An AI that doesn’t know your accounts, services, and dependencies is just a fancy search engine. B.O.R.I.S builds a living memory of your infrastructure.
3. AI should be a team activity. 95% of LLM interactions today are private. We put B.O.R.I.S in Slack so the whole team sees the reasoning, the evidence, and the conclusions - together.
4. Take the toil away. For every 10 developers, there’s 1 DevOps person. That person quickly becomes a help desk. B.O.R.I.S handles the routine questions so humans can focus on real work.
What B.O.R.I.S actually does today
After six months of daily use with real customers, here’s what’s working. B.O.R.I.S operates across three modes - and the thread connecting all of them is the same: it’s a proactive teammate, not a chatbot you have to prompt into action.
On-demand: investigate, answer, unblock
- Incident investigation. It’s 3 AM and you’re paged. The last thing you want is to manually chase down alerts, dig through logs, and figure out which deploy broke what. B.O.R.I.S goes from alert to logs and metrics, from logs to code, from code to root cause - and surfaces the answer in Slack. Five minutes later you have a clear breakdown of what happened, what changed, and who to talk to.
- Parallel hypothesis testing. Incidents rarely have one obvious cause. Meanwhile, the volume of log events and signals involved is simply too large for a human to process in real time. B.O.R.I.S pursues multiple theories simultaneously - correlating signals across systems, ruling out dead ends, and narrowing in on the cause while your team is still reading the first alert.
- Infrastructure Q&A. “Where is the result service deployed?” “Who owns this bucket?” “Which team manages the auth flow?” These questions land in the DevOps team’s queue all day - from developers, security staff, and management alike. B.O.R.I.S answers them accurately from your live infrastructure. Everyone self-serves. Your DevOps team gets their time back.
Automated procedures
Some operational work is repetitive by nature - the same steps, the same checks, the same write-ups after every incident. B.O.R.I.S handles it through SOPs (standard operating procedures defined in plain language, so the team controls what gets automated and how).
- Postmortem generation. After an incident, someone has to piece together the timeline - what happened, when, what changed, what the impact was. B.O.R.I.S does it for you: Slack thread, cloud events, logs, source code changes - assembled into a structured document before the retrospective even starts.
- Recurring operational checks. Any routine that runs on a schedule - health checks, compliance reviews, daily summaries - can be handed off to B.O.R.I.S entirely. It runs them automatically so no one has to remember to trigger them. (Coming soon.)
Proactive: B.O.R.I.S acts before you ask
This is what separates a teammate from a tool. B.O.R.I.S doesn’t wait to be invoked - it monitors external signals and acts based on your team’s operating experience.
- AWS Health event analysis. AWS publishes health events constantly. Most teams either miss them or spend hours manually assessing impact. B.O.R.I.S reads those events, cross-references them against your actual infrastructure, and delivers a breakdown of the real impact on your specific accounts, regions, and services - automatically.
- And more. There are many scenarios where B.O.R.I.S takes action on its own rather than waiting for the team to invoke it. The common thread: it takes on the operational toil that would otherwise fall on your engineers by default.
Where we are now
A few milestones we’re proud of:
- Accepted into the Technopole AI Accelerator in Tallinn, Estonia - selected from 100+ applicants
- Sirob Technologies incorporated in Estonia as an e-Residency company
- 6+ months of daily production use with real customers in highly regulated industries
- Opened the B.O.R.I.S Slack community for anyone to try it out
What’s coming next
We’re heads down building new capabilities that will make B.O.R.I.S significantly more useful for engineering teams. We’ll share more as things take shape - stay tuned.
We’ve also launched Humans in the Loop - a series of live sessions where we talk about the human element of DevOps with AI. It’s a real conversation between experienced DevOps engineers who are building B.O.R.I.S - no scripts, no polish, just honest takes on what works, what breaks, and what we’re learning along the way. New episodes drop every week - subscribe to our YouTube channel to catch them all.
Follow us on LinkedIn to catch future live sessions and B.O.R.I.S updates.
By the way - the name? B.O.R.I.S is “Sirob” backwards. The acronym came after the name, as usually happens with acronyms. It started as a joke, and it stuck.
Until next time, The Sirob Technologies Team