Everyone building an autonomous agent right now is optimizing for the same thing: how fast can it act. I spent most of this hackathon building the ...
For further actions, you may consider blocking this person and/or reporting abuse
Best framing I have read this week: a confident answer is not, by itself, permission to act. The Trust Layer holding at 0.59 with the rollback already prepared is exactly the behavior I wish more agents had, and the honesty of shipping that instead of forcing a plausible fix is the whole point.
One thing I kept circling on: your judgment lives at runtime, per incident, which is great. The harder half is judgment that persists. When the system escalates and a human approves or rejects that rollback, where does the verdict go? If it evaporates, the next near-identical incident re-runs the same gate and re-escalates the same call. The compounding version is writing each human verdict back as a decision the agent reads before acting (what we chose NOT to auto-remediate here, and why), so restraint accumulates instead of resetting every incident.
That handoff of operating context and decisions across runs is basically why I built cowork-os, so this hit home. Does the approve/reject verdict feed back into your runbook library, or is every incident judged cold?
Appreciate this — and no, right now every incident is judged cold. The
approve/reject verdict gets logged in the incident history, but nothing
feeds it back into the Planner's retrieval or the Analyzer's reasoning yet.
You've named the actual next step better than I had: not just an audit
log, but the agent reading its own decision history as context before
acting. Concretely I'm thinking the Planner's RAG index gets extended
with past verdicts attached to runbook matches, so a rejected auto-remediation becomes a negative signal the retrieval score accounts for next time.
Going to credit this framing when I build it. Thanks for the sharp read.
The RAG-index-with-verdicts move is the right long-tail mechanism, past incidents attached to runbook matches as a negative signal is clean. One caution, and it is your own hero incident in reverse: retrieval only surfaces a verdict when the new incident ranks similar enough. The near-miss is the trap, an incident just under the cutoff that slips the gate and re-runs the exact call a human already rejected. Your 0.59 held because the threshold was doing the work, a buried negative signal does not get that luxury.
So I would split it. Long tail in the RAG index like you said, but the load-bearing verdicts, the never-auto-remediate-this-class-here, go in a small standing policy the Planner reads before retrieval, not gated by whether they rank this turn. Pull-by-relevance for history, push-by-state for the hard blocks.
When a human rejects a remediation, do you capture the why or only the that? The why is what lets the block generalize to the near-miss instead of memorizing one incident.
You're right about the near-miss problem. Relying on retrieval alone means a similar incident could miss the similarity cutoff and lose the context of an earlier human decision. I like the split between a small standing policy that's always evaluated and retrieval for historical context. Right now I record the full decision and Trust Layer signals, but not the operator's rationale in a structured form. That's the missing piece, because the why is what lets the system generalize beyond one incident instead of just remembering it. That's the direction I'm exploring for the next iteration.
That's exactly it, and you put it cleaner than I did: the why is what generalizes, the what is just a log line. Once the operator's rationale lives as structured text, a near miss can match on the principle even when the surface features drift below your similarity cutoff, which is the exact failure mode you flagged.
The shape that has worked for me: each verdict becomes a small decision record, not a log entry. The fields I keep are the context, the constraint that actually drove it, the verdict, the rationale in a sentence or two, and a status: active, superseded, or expired. The Planner reads the active set before acting, so a rejected auto remediation is not just a negative retrieval score, it is a stated rule with a reason attached. When the reason stops holding you mark it superseded rather than deleting, so the trail survives without getting re-litigated.
I keep that in plain files rather than a vector store on purpose, so the why stays human readable and correctable. Open here if any of the structure is useful to lift: cowork-os.
How are you leaning on storage: does the rationale sit next to the runbook match in the RAG index, or as a separate policy layer the Planner always evaluates before it hits retrieval?
I'm leaning toward keeping them separate. The RAG index still feels like the right place for precedent and historical context, but I don't want hard operational constraints to depend on similarity retrieval. My current thinking is that the Planner evaluates a small policy layer of active decision records first, then uses RAG to enrich that decision with related incidents and runbooks. I do like your active/superseded idea as well. It preserves the reasoning trail without turning yesterday's judgment into tomorrow's permanent rule, which feels important if the operating environment changes. I'll take a look at cowork-os as well, I’m curious how you've structured those decision records in practice.
"Speed without judgment is how a small incident becomes a large outage" — this should be printed on every platform engineering team's wall.
The "earn the right to act" pattern is exactly right. I've been experimenting with a similar concept in AI agent quality checking: instead of letting the model decide pass/fail on every case, use vote entropy as an escalation signal. When the model is uncertain, don't force a decision — escalate to human judgment. Same philosophy as your approach.
One question: how does the Planner handle cases where the FAISS runbook search returns low-similarity matches? Do you have a minimum confidence threshold before the Executor is allowed to proceed?
Thanks, Xiao Man. I like the vote entropy analogy because it's the same design philosophy: uncertainty shouldn't be treated as just another prediction, it should change the system's behavior.
On the Planner, yes. If the best runbook match falls below ~0.65 (or the retrieval margin is too narrow), the Planner can still propose a remediation, but the Trust Layer won't allow autonomous execution. Instead, it routes for human approval. The 0.59 incident was a good example: the system had a plausible rollback ready, but the evidence wasn't strong enough to let it act without review.
That 0.65 threshold is interesting — it's basically a confidence gate before the trust layer. The idea that the Planner can still propose but the Trust Layer says "not today" without a human stamp feels right. Too many systems either go full-auto or full-block. Having that middle ground where the suggestion exists but needs sign-off is the pragmatic sweet spot. Curious what your false-positive rate looks like around that threshold — do you find the 0.59 case is rare or does it come up more than expected?
The 0.65 threshold is holding up great. That 0.59 case was actually a deliberate test on my end (I forced a bad image tag), but similar low-similarity edge cases do pop up organically during chaos testing. They aren't super common, but they happen just enough to prove the human fallback works.
I totally agree on that middle ground. Going full-auto in production K8s is reckless, but staying full-manual defeats the point of the agent. "Propose but require sign-off" is the perfect balance.
Speaking of your earlier point, I’m really curious about your vote entropy experiments. How are you actually applying that for quality checking in practice?
Glad the threshold is working for you! Forcing bad inputs in chaos testing is smart — that's exactly how you build confidence in the guardrail.\n\nOn vote entropy: I run 3-5 models on the same ambiguous task and compare their outputs. When they all agree (low entropy), I let it through. When they diverge wildly (high entropy), I escalate to human review. The key insight was that entropy correlates much better with "needs human attention" than any single model's confidence score.\n\nPractical tip: I cap anchors at 6-10. More than that and you start optimizing the rubric instead of catching edge cases. Quality over quantity.\n\nHave you tried measuring entropy across temperature settings? I found that running the same model at T=0.3 vs T=0.7 gives a different kind of disagreement signal.
That's really interesting. I haven't tried varying the temperature yet. Right now the Trust Layer is based more on evidence quality than reasoning variance, so it's looking at things like analyzer confidence, retrieval confidence, and risk rather than disagreement between multiple outputs.
But I can definitely see temperature disagreement being useful as another uncertainty signal, especially when the model can justify two different remediation paths.
I like the idea because it's asking, "Is the model consistent with itself?" instead of just trusting a confidence score. Definitely adding that to my list to experiment with.