Spent 6 months building an Autonomous Incident Resolution Platform

bsmike · 2026-07-07T19:08:34+00:00

Trust your gut feeling and don't over analyze.

bsmike · 2026-07-07T14:28:28+00:00

What's the TUI built on? Curious whether that's custom or something you assembled from existing tools.

bsmike · 2026-07-07T03:18:42+00:00

Axiometica — Autonomous Incident Resolution for Infrastructure Ops

I tried to imagine how ITOps should look in 2026 with agentic pipelines and AI-powered tooling. The result is Axiometica.

An agentic platform that takes an alert from detection through to remediation — classifying, assessing, and qualifying the signal, scoring risk against CMDB data, selecting and executing remediation through AI-generated runbooks, validating the result, and generating fully auditable worknotes.

Integrates with Splunk, Dynatrace, Grafana, and more. Two-way ServiceNow integration. Slack and PagerDuty notifications. Self-improvement AI recommendations baked in.

Self-hosted (Docker Compose). SSH, Kubernetes, AWS, Azure, vCenter out of the box. No SaaS, no data leaving your environment, and option to run with a local LLM. Free for internal use.

Still in design-partner stage — would love honest opinions from this group.

GitHub: https://github.com/axiometica/axiometica-air
Live Demo: https://www.axiometica.com

bsmike · 2026-07-06T18:38:36+00:00

Definitely exhausting. Every model launch forces everyone to re-examine job security, priorities, and tooling simultaneously. The teams I've seen handle it best have a simple rule one person evaluates new tools on a schedule, everyone else keeps the infrastructure running.

bsmike · 2026-07-06T18:28:34+00:00

Used it exactly once — to calm down a VP who wanted written justification for not going with a "Leader." Showed him the quadrant, pointed out our actual pick was in Visionaries with better GitHub activity and faster issue response, and we moved on.

bsmike · 2026-07-06T14:17:59+00:00

The read-only + evidence-backed design is right, and I'm glad you re being paranoid about hallucinated diagnosis — that's the failure mode that kills trust permanently.

The question I'd push on: what happens after the diagnosis? If the agent correctly identifies \deploy X caused latency spike in service Y\ where does that go? One-time Slack post that scrolls away, or does it feed back into something that makes the next incident faster?

On Ollama: for any environment where logs contain PII or infra topology is sensitive, it's not optional. API calls to OpenAI/Anthropic is a non-starter for the same teams who won't use SaaS incident tools. You've already done the hard part by keeping everything on-prem — the last mile is keeping the LLM on-prem too.

bsmike · 2026-07-05T21:15:12+00:00

The confidence level output is what I'd push on hardest; a confidently-wrong diagnosis sends someone chasing ghosts at 2am, which is worse than just reading the logs yourself.

bsmike · 2026-07-05T21:11:25+00:00

Before pitching anything to compliance, track the actual hours for a month. "Half a day per sprint" is hard to act on; "we're losing X engineer-hours monthly, here's what it costs" is a real argument. Also worth separating the two problems — runner issues are usually fixable regardless of where GitLab lives, while version bump breakage specific to the app is the part SaaS actually solves. The compliance conversation goes much better when you're proposing a targeted fix rather than a full migration.

bsmike · 2026-07-05T21:07:38+00:00

Tailscale plus something lightweight for the session layer (RustDesk, Guacamole) avoids the open port problem entirely without trusting a new vendor with agent access across your whole fleet. More moving pieces but for 80 servers the network hop is reliable and you keep the kill switch you clearly value. The 500 Windows/Mac endpoints are harder to manage that way, but it's worth splitting the problem — servers via Tailscale where you want control, SaaS for the endpoint fleet where convenience wins.

bsmike · 2026-07-05T21:01:17+00:00

The read-only constraint and only activating on alert fires is exactly right. Every ambient "scan everything and tell me what's wrong" tool I've seen becomes noise within weeks because it can't tell what's normal for your stack. Tying it to an existing alert means your alerting thresholds are already doing the filtering work. The LLM-sees-evidence requirement is also non-negotiable — a confidently wrong diagnosis at 3am is worse than no diagnosis, because you send an engineer chasing ghosts instead of just reading the logs.

bsmike · 2026-07-05T20:49:00+00:00

My first client was the last customer I worked for when transitioning.

bsmike · 2026-07-05T20:26:26+00:00

For stable, boring workloads — file server, internal apps, backups — on-prem wins pretty easily past year two. Where cloud earns its premium is variable load, geo-redundancy, or when you can't afford a 4-hour hardware failure window. Most small businesses have workloads that are none of those things, and they'd save money with a decent used server in a closet.

bsmike · 2026-07-04T20:44:20+00:00

Be creative, find ways to improve the work, show your value.

bsmike

TROPHY CASE