Parahelp published the prompt that runs their production support agent. A manager model reads a tool call the agent wants to make and returns accept, or reject with a comment. Their reason for publishing was that without the evaluation data, nobody can tell why the prompt is written the way it is.
It states its reject contract four times and contradicts itself once. A parser written from the majority form reads a line-7 reject as no verdict at all, and no verdict is what silence looks like too.
Every line of the published prompt that says how to reject, and the tag it names. Accept is the same tag in all four places, so only the reject path is ambiguous.
A reader building a parser meets line 7 before the other three. If they follow it, they write a parser that reads a tag the rest of the prompt never uses. If they read on and follow the majority, they write one that cannot see a reject issued the way line 7 describes.
The prompt is not redistributed here and neither is its text. Only the line numbers and the tag each names, both read out of the file rather than typed in.
Type what the manager returned, or pick one. The two parsers below are the ones in the repository, running here in your tab.
A gate cannot tell "the manager objected" from "the manager said nothing". Both arrive as no verdict. Unless the caller is written to treat a missing verdict as fatal, the tool call goes through, and the component whose only job is stopping an out-of-policy refund or password reset has resolved its ambiguity toward approving.
Accepts are never affected. The failure is one-directional, which is why it can sit in a prompt for a long time without anyone noticing: the system looks like it is working, and it is wrong only on the calls it was built to stop.