CRM 정보가 틀렸다면 어떡하지?

단순히 데이터 충돌을 찾아내는 것뿐만 아니라, 그 이후에 어떤 시스템을 신뢰할지 혹은 언제 사람에게 에스컬레이션할지 같은 규칙을 에이전트가 가지고 있느냐가 핵심임

충돌을 잡아내는 건 맞는데, 내가 본 에이전트들은 판단을 내리는 대신 그냥 '모르겠다'고 해버리더라. 그래서 후속 조치가 없으면 알림은 그냥 쓸모없는 소음일 뿐임. 불일치를 찾아내는 것만으로는 부족하고, 그다음 단계에 대한 확실한 계획이 있어야 함

플랫폼별이 아니라 필드별로 권한을 정의하는 게 말이 되네.

최신 상태 필드만 볼 게 아니라 실제 이벤트 기록을 비교하는 게 유용할 수도 있음.

승자를 고르기 전에, 두 기록이 같은 시점에 대해 서로 다른 말을 하는지 확인해야 함. CRM에서는 닫혔는데 다른 곳에선 열려 있다면, 보통은 동기화 시점 차이 때문에 발생하는 문제고 에이전트가 마지막으로 읽은 게 우연히 승자가 되는 거임. 진짜 모순이라면 두 소스 모두 동일한 기준 시점을 주장해야 함.

나머지 절반은 네 예시에 있음. 에이전트가 해결되었다고 단정 지어 말하게 하지 마. 'CRM 기준 14:02에 해결됨'이라고 말하게 하면, 잘못 읽었을 경우 고객이 바로잡을 수 있는 오래된 정보로 격하됨.

오래된 데이터와 진짜 모순을 분리하는 거 좋네. 아마 둘은 완전히 다른 방식으로 처리해야 할 듯.

Tell Me Who Do You Love

난 전역적인 소스 순위는 안 매길 거임. 필드 수준의 권한 맵과 명시적인 기준 시점을 기준으로 각 주장을 해결할 거임. 만약 현재 권한이 있는 두 주장이 여전히 충돌한다면, 하나를 덮어쓰지 말고 일급 분쟁 상태로 유지할 거임. 에이전트는 위험도가 낮은 질문에는 출처를 밝히며 답변할 수 있지만, 되돌릴 수 없는 작업은 분쟁이 해결될 때까지 실패 처리해야 함.

전제 자체가 잘못됐음. 에이전트가 무엇을 신뢰할지 결정하게 하는 건, 설계 단계에서 결정을 건너뛰고 런타임으로 떠넘긴 거임. 에이전트를 더 똑똑하게 만들 게 아니라 엔지니어링으로 해결해야 함.

필드 하나당 작성자 하나, 나머지는 읽기 전용. 이건 원칙으로 끄덕이는 게 아니라 코드로 강제해야 함. 많은 AI 사용자가 여기서 실수함. 내 첫 CRM은 두 가지가 같은 상태를 쓸 수 있어서 망했음. 그리고 에이전트는 애초에 상태 필드를 읽으면 안 됨. '닫힘'은 캐시된 요약일 뿐이니까…