A few weeks back I had an agent reconciling a vendor list. It ran clean. No error, no crash, output looked right. Then I noticed it had merged two ...
For further actions, you may consider blocking this person and/or reporting abuse
honestly the certified-vs-practiced line gets fuzzy for greenfield PMs - if you’ve never had a bad agent run to learn from, "go get the reps" is easy to say and slow to live. i underscoped how someone builds that instinct before they’ve been burned once.
the 'out_of_scope' constraint format in that task spec is doing more work than it looks like. we've started treating agent task specs like API contracts — explicit invariants at the top, not requirements. 'do not merge distinct legal entities' is a constraint that should fail the run if violated, not a hope. the thing the PMP change won't capture: how you write a task that makes the override moment discoverable. if the only way to catch the vendor merge is to recognize the shape from having been burned before, the scope definition failed. the spec should surface it. what does your current pattern look like for writing the acceptance criteria?
treating them as fail-hard invariants is right. the thing most teams miss is the abort vs log-and-continue call — and it matters most for OUTPUT constraints. "do not merge distinct entities" is a hard abort if you catch it pre-write. caught post-write it becomes a post-mortem. the spec needs to tag which phase each constraint guards.
the pre write vs post write distinction is the piece worth encoding explicitly. we've started labeling each constraint in the spec as either
guard_phase: pre_commitorguard_phase: post_commit— guards that fire post commit need a rollback plan in the same spec, not just an error. without that, the agent 'succeeds' and the human cleans up. does your tooling surface which phase a constraint belongs to, or is that still a manual annotation at spec write time?the guard_phase labeling is the part i want to steal - post_commit constraints in our specs always have the weakest rollback plans. making rollback a required field for post_commit guards specifically would have caught two incidents this quarter.
making rollback required rather than optional is the right call tbh. we have the same enforcement — if guard_phase is
post_commitandrollback_fnis undefined the spec fails validation before it ever runs.the edge case that bit us: rollback itself can fail. you need a fallback for the fallback, especially on writes that are partially flushed. do you treat double failure as halt or escalate to human?
escalate for us - halt masks the problem. partial write plus failed rollback is exactly when a human needs to see the actual state, not a clean error log that pretends it never happened.
The most important AI skill may be knowing when to intervene.
knowing when NOT to intervene is the harder half — intervening has an immediate visible cost. not intervening has a deferred cost you might not see for hours. most teams bias toward intervention because the harm is legible in real time. the skill is trusting the run long enough to collect signal without letting a bad branch compound.