Hacker Newsnew | past | comments | ask | show | jobs | submit | teknokeras's commentslogin

The invariants feature is the most interesting part to me. Are invariants like "patient name must match the source document" enforced deterministically outside the model (a separate checker that gates actions), or does the agent itself evaluate them as part of its loop? Asking because if the same model that decides actions also verifies invariants, a misread screenshot could fail both at once — the check inherits the perception errors it's meant to catch. Curious how you split trusted checks from model judgment.


teknokeras's question maps onto something I hit in a different domain, tool-calling instead of DOM/UI state, so take this as adjacent evidence, not the same bug.

Ran a 63-trial eval on an on-device agent doing calendar/reminders tool calls. The model got its own due date wrong on 89% of calls that needed one, and it wasn't a formatting slip, it computed a genuinely wrong absolute date and called the tool with full confidence. Checked an MLX model as a follow-up and it was worse: 0/36 correct, but every single one was still a well-formed, valid-looking date string. A naive "does this look like a real date" check would've passed all 36.

That's basically teknokeras's failure mode from a different angle. If verification just checks output shape/plausibility instead of an independent ground truth, it inherits whatever the model already got wrong, because the model produced something that looks right by every surface signal available to a shape check. Same reason sneefle's react-state example passes vision verification: looking correct isn't the same claim as being correct.

Fix that held for the date case: don't trust the model for anything derivable independently, resolve it in code from the real system clock, reject anything that doesn't match. Doesn't generalize to every invariant you'd want, but the principle probably does: verification needs a source of truth the model didn't produce.


Congrats on the launch. Question about the data side: conversations tend to contain a lot of PII (names, emails, account details users paste in). When you cluster and surface example messages in the dashboard, is there any redaction step before storage/display, or is that left to the customer to filter before sending through the SDK? Curious how much of SOC 2 scope covers the message content itself vs the infrastructure.


that on the customer's side to redact the PII as you are the ones sending it and you'd know better than us


Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: