Table of Contents
The Moment That Changed Everything
What It Actually Is
The Setup Nobody Believes Is This Simple
Focused Sessions — On...
For further actions, you may consider blocking this person and/or reporting abuse
The two questions above (Nazar on silent failure modes during non-expert operations, Aliaksei on the six-month maintenance bill behind the 65% MTTR and 85% adoption numbers) both land on the failure mode the post itself does not surface, which is that the conversational layer reports success based on what the agent's own monitoring claims succeeded, not on what was independently verified to have completed correctly.
Caught the same pattern in a different domain this morning. Three weeks of live trading, displayed result was -$7.72. Production DB audit showed that for a four-day window the driver was emitting placed=1 on every cycle, the placed_ok counter was 0 for the same period, and zero execution_error events were logged. The monitoring layer was telling the attempts-tracking layer that everything was working. Operator (me) trusted the run-summary because the negative signal was missing rather than present. The placed_ok counter was in the schema the entire time, just not read as the authoritative success measure.
Translates to FRIDAY: investigation_started is the placed=1 counter. The question is whether there is an investigation_completed_correctly metric authored outside FRIDAY's own self-report, and if so what the gap between the two looks like over a six-month maintenance window. Without the second counter, "85% adoption" measures human use of the tool, not tool-success rate at the work humans no longer do.
Same shape for the 130k account cleanup. Non-expert driver plus conversational reporting means the "no errors reported" signal is functionally indistinguishable from "no errors detected by the layer doing the reporting." Nazar's point exactly.
The cluster primitive: the layer producing the work cannot be the layer judging the work, and the deterministic success counter has to be authored separately from the agent's narrative summary.
You've identified the exact architectural gap: the layer producing the work cannot be the layer judging the work. Your trading analogy is precise, placed=1 with placed_ok=0 and no execution_error is structurally identical to what happened with our metrics bug. FRIDAY does have an independent completion signal (the Teams card is posted only after the full investigation loop terminates with end_turn) but you're right that investigation_completed ≠ investigation_completed_correctly. We don't currently have an independent quality score authored outside FRIDAY's self-report.
For the tenant cleanup, spot on. "No errors reported" meant "no errors detected by the rescue block that only catches exceptions, not HTTP 400 responses." The deterministic success counter principle you're describing is something I'll be building into JARVIS from day one . Appreciate the rigor! 😊
That gap admission is the part most teams skip in public, so this lands cleanly. FRIDAY having end_turn-bound Teams notification is real, just answers a different question: "the loop finished" rather than "the loop finished correctly." Same shape as the HTTP 400 you described: the rescue block catches what looks like failure, and what fails outside its frame stays invisible.
For JARVIS day-one design, the cheapest independent quality score is usually whatever the action itself touched in the real world, read back by something that did not perform it. For tenant cleanup that would be a post-action count query on the target system, run by a deterministic script with no knowledge of the agent's narrative. For incident investigation, it could be the postmortem confirming the recommended remediation actually addressed the root cause, sampled by a human reviewer who never saw FRIDAY's chain of reasoning.
The expensive but honest version is letting the gap between the two counters become the metric you optimize against, instead of the one you suppress.
Great feedback! One clarification on FRIDAY's output, it's more structured than just a narrative summary. Every investigation produces 7 mandatory sections: Executive Summary, Key Findings, Error Breakdown, Root Cause (with Confirmed/Suspected/Unknown status and cited evidence), Customer Impact, Recommended Actions, and Not Investigated. The Root Cause section explicitly states its confidence level and cites specific tool results not "I think this happened" but "PR #2377 merged June 26, cache hit/set logs confirm functionality, error rate 5,354/hr is below 24h baseline of 6,889/hr."
So the independent verification signal is partially there and the agent cites Datadog metrics, GitHub commits, and PagerDuty data as evidence, and those are queryable after the fact. But you're right that "the agent cited real data correctly" is still different from "an independent system confirmed the conclusion was correct." The postmortem sampling idea is the missing piece comparing FRIDAY's Root Cause against what the engineer ultimately confirmed. That's a quality score we can start tracking this month with zero new infrastructure.
The seven mandatory sections plus the Confirmed/Suspected/Unknown axis on Root Cause already do most of the discipline work. That structure forces the model to admit where the evidence runs out, which is where most agent outputs quietly mask uncertainty as confidence.
The postmortem sampling design is where the verification half lives. The metric I would track is straightforward: RootCause-statement-as-emitted compared against RootCause-confirmed-by-engineer at incident close, scored as match / partial / wrong, with the citation list checked independently for whether the cited evidence actually supports the stated conclusion. That last check is what catches the failure mode where the model cites correctly but reasons incorrectly, which is the worst case for any tool that produces structured output.
A 100% sample for the first month, then a stratified sample once the base rate is known, is usually enough to stabilize the signal without burning engineer attention. Once that quality score exists you also have a non-trivial differentiator: not "our agent investigates incidents" but "our agent's Root Cause statements track engineer-confirmed truth at X%, sampled monthly." That is a number a procurement conversation can actually use.
Excellent feedback again. These are some great metrics and baseline to establish to assess my agent's analysis and make it even more accurate.
Thank you!
This is a fascinating real-world example of how AI becomes truly valuable when it's connected to enterprise systems rather than operating in isolation. The combination of MCP with tools like AWS, GitHub, Datadog, and Azure DevOps demonstrates how AI can significantly reduce context switching and accelerate incident response.
What stands out most is the progression from an AI assistant that answers questions to autonomous investigation with appropriate guardrails. That approach builds trust incrementally while keeping humans in control of critical decisions. As more organizations adopt AI for operations, success will depend not just on the language model, but on robust integrations, observability, security, and well-defined governance around autonomous actions.
Thanks for sharing such a detailed case study—it offers valuable insights into what AI-native platform engineering can look like in production.
Thank you Saleha. You nailed the key insight Critical part of this integration is the credential isolatiom, and the governance model around what the agent can and can't do. The progression from "answer questions" to "investigate autonomously" to "remediate with approval gates" is deliberate and each stage has to earn trust before the next one unlocks. I am glad that this article was helpful for you!😀
Quick question on that 130k account cleanup. You mentioned a metrics bug caused silent data loss partway through, and that's the exact failure the conversational layer is worst at surfacing, since nothing errors out and the agent reports progress as normal. When the person driving doesn't deeply know the systems, how did that one actually get caught? That's the case I'd most want a story about, because it's where "just ask in plain English" stops protecting you.
Great question! And you're right, that's exactly where the conversational layer fails silently. The metrics bug was caught because the Datadog dashboard showed "No Data" while Rundeck logs showed accounts being deleted successfully. The mismatch was visible to a human looking at both and the agent wasn't the one who caught it. That's the honest answer. The conversational layer reported "deletion complete, metrics pushed" because the HTTP call returned (with a 400 body nobody read). The fix was mechanical (V2 → V1 API format), but the detection required a human noticing two systems disagreed. Good argument for independent verification outside the agent's own reporting which is exactly what Mike's comment below gets at 😊
What's underrated here is the cross-signal reading. Everyone talks about agents writing code; nobody talks about how good they are at reading the telemetry no one has time to read. I run something close - an agent that scrapes a few platforms and 8 API providers daily and stitches them into one timeline for problem analysis. Genuinely useful, and I think it's the boring superpower most people are sleeping on.
Two questions from the trenches. How's FRIDAY holding up over months, not launch week? Mine is useful and still breaks at random, no matter what monitoring or self-checks I bolt on - the 65% MTTR and 85% adoption are launch numbers, I'd want to see the maintenance bill six months in. And I wouldn't make the jump from read-only IAM to autonomous remediation, at least not yet. I get nervous handing an agent a dev cluster, never mind letting it act on prod unwatched. What made you comfortable with that?
Boring superpower" - I'm stealing that framing. Your multi-platform timeline stitching sounds like the same pattern. On FRIDAY's durability, these are sustained numbers, not launch week. The maintenance bill is real though prompt updates when infra changes, edge case rules accumulated from investigations that went sidewa, and a periodic training mode that re-crawls the environment. It gets better over months (every failure becomes a prompt improvement) but it's not deploy-and-forget. On read-only → write-path, I share your instinct. The near-term goal isn't "unwatched on prod" , it's "creates the PR, waits for CI, asks me if I'm ready to merge." 😊