u/sevenboxdev
-
2points
-
1points
-
6points
-
1points
-
1points
I built a way to track why an AI agent made a decision, so you can find what breaks when it turns out to be wrong (i.redd.it) [Beginner Agent]
-
1points
sevenboxdev
sevenboxdev
That’s a sharp question, and you’re right. Today Sevenbox treats every dependency as a joint requirement, with nothing that marks one as an alternative that would have been enough on its own.
I ran exactly the test you described, with a conclusion C that has two parents A and B, A retracted and B untouched. In one fixture C was meant to require both, and in the other either one was meant to be enough. Both reported exactly one obligation, an identical result despite the opposite intended meaning, which confirms the repair is conservative rather than targeted.
That was the safer default for what I care about most, since in an audit of irreversible actions flagging a decision for review is much cheaper than silently missing one. It’s still a genuine gap, and fixing it properly needs real design work on what a conclusion with alternative support looks like in the data and how a correction should walk it. I opened an issue with the code and the real output, and I’d really like your view on how you’d want it represented.
sevenboxdev
Thanks again for the questions, they turned into real changes. v0.1.1 is out with a discharge helper that closes an obligation either as compensated, with the compensating action recorded as evidence, or as not needed, which covers your moot write case. It also fixes a bug where direct obligations kept showing as pending after being resolved. There’s a short example in examples/discharge_obligation.py, and the question about compensation handlers is now an open issue if you want to weigh in on whether they should run automatically or only be suggested.
Release: https://github.com/sevenboxlabs/sevenbox/releases/tag/v0.1.1
Handlers discussion: https://github.com/sevenboxlabs/sevenbox/issues/3
sevenboxdev
sevenboxdev
Thanks :) that’s exactly what the graph is for. Each node is a decision your agent made, labeled by where it came from, so an axiom is a starting premise, an oracle is a model’s answer, a tool is an action it took, derived is something computed from earlier steps, and human is input from a person. When something goes wrong a few steps in, you can follow the edges back to the belief it all rested on, and if that belief gets corrected, Sevenbox marks everything downstream that depended on it, including actions that can’t be undone. What you’re working with, have you had an agent go off the rails like that, and how did you figure out where it went wrong?
https://github.com/sevenboxlabs/sevenbox