에이전트 결제 기능 때문에 워크플로우가 자꾸 망가짐

에이전트 레이어의 규칙은 취약함. 에이전트의 추론이 규칙을 강제하는 방식이라서 그럼. 카드나 네트워크 쪽에서 처리하는 게 훨씬 나음. 에이전트는 거절된 거래를 추론으로 우회할 수 없으니까.

Rain 같은 걸 써보는 것도 방법임. 정의된 규칙 밖의 카드는 아예 결제가 안 되게 직접 처리해주거든.

결제는 되돌릴 수 없어서, 결제가 포함된 작업에서는 워크플로우 도구들이 제대로 작동을 안 함.

솔직히 말해서 네가 잘못한 거 아님. 프롬프트는 제안이지 가드레일이 아님. 에이전트가 딴길로 새는 순간, 네가 시킨 건 다 증발하고 카드는 계속 긁히는 거임.

그래서 경험칙 하나 알려주자면, 진짜로 지켜야 할 제한 사항은 에이전트 내부에 두면 안 됨. 에이전트가 딴짓하게 만드는 그 드리프트 현상이 결국 자기 규칙까지 무시하게 만드니까.

카드 쪽에 더 가깝게 제어하는 게 정답임. 만약 네 결제 프로세서가 카드 단위 제어(Stripe Issuing, 가맹점/MCC 제한이 있는 가상 카드 등)를 지원한다면, 카드는...

중복 결제 문제는 보통 정책 문제가 아니라 retry나 idempotency 문제임. 모든 결제 시도에 idempotency key를 넣으면, retry할 때 중복 제거가 돼서 같은 카드를 두 번 긁는 일을 막을 수 있음. '엉뚱한 곳에 결제하는' 문제는 tool boundary에서 allowlist랑 기간별 한도(per-window cap)를 설정하는 게 효과적임. agent가 hard decline를 우회할 논리적 근거를 만들 수 없으니까. 규칙을 prompt에 넣지 말고, boundary에서 그냥 'declined' 결과를 반환하게 해서 agent가 루프에 빠지는 대신 그 결과에 반응하게 하셈.