Gil Neto

Yes, I'd surface it. Forcing it to balance hides exactly what the accountant needs to know, which is that a piece of the history can't be checked anymore. I'd split it in two. The transfer itself usually survives the exchange, because the withdrawal is on-chain. With the hash, the amount and the destination address you can still show that 2.397 ETH arrived in the client's wallet. What dies with the exchange is the other half, what the client paid for that ETH in the first place. So the match can be confirmed while the cost basis is still unknown, and I'd want the report to say those two things separately - transfer matched, cost basis missing because the source closed. That's also why the checklist in the post asks where every withdrawal went.

Giving each line a state is roughly where I landed too - a €12.50 bank fee should never become a question to the client. The question only goes out for a line that's still unmatched after the obvious stuff is ruled out (fees, transfers between the client's own accounts, one payment covering several invoices). On late documents, the request belongs to the bank line, so the reminder should read the line's state at the moment it's about to go out, instead of being scheduled once and fired regardless. If the invoice arrived and got matched in the meantime, the line is already closed and nothing gets sent. The part I don't have an answer for yet is that the invoice lands in the practice's own intake, not in my tool, so I need to see that match happen somewhere I can read it. Until then, the fallback is a reminder that says exactly which line it's about, so a client who already sent it can just say so. None of this is built yet, so treat it as the plan.

Neither, as far as I could tell - it was session-level. Whichever rule won, won from the first message and held for the whole session - a long conversation didn't degrade it, it stayed consistently wrong in one direction. Then fresh session with the identical setup could flip. So each session looked internally fine on its own terms, which is why I kept blaming the rules instead of the setup. My best guess at the mechanism: the two rules didn't reach the model the same way. The terse one gets re-stated in the prompt stream every turn, the readable one is a static file loaded once at the start. Same words, different reinforcement, so which one lead is mostly whichever landed closer. On the eval, I don't have one. The bit I'd add is that a per-rule adherence eval still passes here, because each rule is obeyed fine in isolation. The conflict only shows up when following one breaks the other, so the adversarial prompt I'd want gives it something that can only be written tersely or readably, rather than just tempting it to be verbose.