-
-
OCA Dashboard
-
Tickets Page
-
Jira Integration
-
Slack Integration
-
In-Depth Ticket Overview
-
Individual Incident Reports
-
A/B Testing in Sandbox
-
Local-AI Choice, Command Blacklists, Allowlists
Inspiration
As artificial intelligence becomes increasingly integrated into company infrastructure, we believe the next major breakthrough in AI shouldn't just be about making models smarter or faster. It should be about making them more responsible, reliable, and accountable.
Our inspiration behind OCA (On Call Agent) came from two questions:
What if Local AI could be trusted to manage critical infrastructure responsibly? And what if engineers no longer had to wake up at 3 AM just to resolve a production incident?
Today, companies rely on on-call engineers to respond to unexpected outages, investigate failures, and restore services, often in the middle of the night. At the same time, businesses are rapidly adopting AI, yet trusting AI to make decisions within critical infrastructure remains a major challenge.
We saw an opportunity to address both problems.
We wanted to pioneer a future where AI doesn't just assist engineers but can take on the responsibilities of an on-call engineer, from investigating incidents and identifying root causes to proposing solutions and safely executing approved fixes.
What it does
On-Call Engineer (OCA) is a fully local, autonomous on-call team for a company’s infrastructure. It watches the company’s health, and when something breaks it opens a ticket. Three AI agents then take over. The Investigator finds the root cause, the Engineer writes a fix and proves it works in an isolated copy of the company, and the Guardian reviews how risky the fix is. If the fix passes our safety gate, OCA backs up the system, deploys the fix and checks that the company is healthy again. Everything runs on one ASUS Ascent GX10 with a local model, so no code, logs or company data ever leave the machine. The team can follow along live on a dashboard and gets updates in Jira and Slack. To demo it, we built Driftwood Coffee Co., a fake online coffee shop, and break it on purpose with realistic bad deploys.
How we built it
The three agents are written in Python and share one local Nemotron model served by Ollama, but each has its own prompt and its own limited set of tools. The platform is built with FastAPI and SQLite, with a server-rendered dashboard that works offline. It also includes health checks, a command gate that only lets approved commands run, git-based backups, staged deploys that restore automatically if something goes wrong, and a sandbox built with Docker Compose. Driftwood runs in Docker Compose too, with a storefront, an orders API, Postgres, Redis, Prometheus and a load generator that simulates customers. We inject incidents by merging a teammate’s branch, the way a real bad deploy happens. Jira and Slack only receive approved fields, never logs or code.
Challenges we ran into
The local model kept getting stuck in loops: it would repeat the same tool call while the results filled up its context, until it ran out of steps. We fixed it with loop guards. An identical tool call is refused until something actually changes, every tool result shows how many steps are left, the agent gets a nudge when it’s running out, and oversized tool outputs are cut down to a preview. On some machines the fake company wouldn’t run in Docker at all, because Windows line endings broke the scripts and the .env file was missing or being misread. The injection script was also unreliable: once an incident branch had been merged, running it again did nothing. We fixed that by resetting the company to a clean baseline before each injection and wrapping both steps into one script.
Accomplishments that we’re proud of
The whole pipeline works end to end on the GX10 with a local model, from detecting the problem to diagnosing it, fixing it, proving the fix in the sandbox, reviewing it, deploying it and verifying the result. One run went from detection to resolved in 6 minutes 38 seconds with no human involved, without any cloud LLM requests or infrastructure data leaving the box. The AI never touches production directly: a deterministic safety gate decides what can run, and risky fixes like database migrations wait for a human to approve them. We’re also proud that Driftwood behaves like a real business, including a storefront that shows customers friendly error messages during an outage.
What we learned
We learned that small local models need guardrails, and that strict step limits, loop detection and validated JSON outputs mattered as much as the prompts did. Having software detect the problem and AI reason about it worked better than asking an LLM to watch metrics. Sending everything through one API and one safety gate made the system easier to trust, test and debug. We also learned that setting up a realistic fake company with Docker, git history and deploy scripts takes more work than we expected.
What’s next for On Call Engineer
Next, we want to benchmark other local models, such as Qwen and larger Nemotron versions, on accuracy and speed, and run agents at the same time to resolve incidents faster. We also want to support more kinds of infrastructure, such as Kubernetes and cloud services, add more incident types like memory leaks, bad dependencies and security issues, and let teams start and approve incidents from Slack.
Log in or sign up for Devpost to join the conversation.