AI orchestrátor nevidí druhou stranu vlákna a dubluje práci týmu

import { Aside } from ‘@astrojs/starlight/components’;

AI vrstva plánující akce z komunikace musí vidět OBĚ strany vlákna a před založením akce ověřit, zda po spouštěcí zprávě neexistuje novější odpověď týmu — párovat přes In-Reply-To/Message-ID, thread id a fallback na adresu protistrany.

Symptom

AI orchestrátor napojený na CRM přes push sync správně zakládal úkoly typu „zpracovat schválenou objednávku z e-mailu”. Jenže obchodník mezitím klientovi sám odpověděl (vyžádal si doplňující údaje) — orchestrátor to nevěděl a:

1. zakládal úkoly na věci, které už někdo řešil (duplicitní práce, ztráta důvěry v AI úkoly),
2. neuměl hlídat opačný směr: „klient na naši žádost/nabídku X dní nereaguje → zavolat”.

Root cause

Dva na sobě nezávislé zdroje slepoty:

1. Pravidla plánovala akce jen z příchozích zpráv. Odchozí e-maily sice v DB byly, ale pravidlo „schválená objednávka” je vůbec nekonzultovalo — chyběl krok „existuje novější odchozí odpověď do stejného vlákna?”.
2. Sync navíc posílal i systémové/interní maily. Automatická potvrzení plateb a interní záznamy (odchozí bez přiřazeného uživatele, direction: "internal") se do AI vrstvy syncovaly jako běžná korespondence → falešné „tým už reagoval” i falešné kandidáty na follow-up.

Párování vláken jen podle e-mailové adresy je navíc křehké (klient odpoví z jiné adresy).

Fix

Sync (zdrojový systém): posílat jen skutečnou korespondenci a vláknová pole:

// WHERE pro push sync e-mailů
{
  direction: { in: ["inbound", "outbound"] },   // žádné "internal"
  NOT: [
    { fromEmail: "" }, { toEmail: "" },
    { direction: "outbound", userId: null },    // automat (potvrzení, reporty)
  ],
}
// payload navíc: messageId, inReplyTo, threadRef

Orchestrátor: třívrstvé párování odpovědi + kontrola před založením akce:

function isReplyToInbound(out, inb) {
  if (out.inReplyTo && inb.messageId && out.inReplyTo === inb.messageId) return true
  if (out.threadRef && inb.threadRef && out.threadRef === inb.threadRef) return true
  return norm(out.toEmail) === norm(inb.fromEmail) // fallback
}
const replied = outbounds.some(o => o.sentAt > inbound.sentAt && isReplyToInbound(o, inbound))
// replied → akci nezaložit, nebo založit jen jako „už řešeno — jen zkontrolovat"

Follow-up hlídač („klient nereaguje”): odchozí žádost/nabídka bez odpovědi klienta ≥ N pracovních dní → úkol „zavolat”. Idempotence: dedupe klíč = první neodpovězený odchozí e-mail série (série = odchozí po poslední reakci klienta). Opakované běhy nevytváří duplicity (DB unikát ruleKey+entityId), odpověď klienta sérii ukončí a follow-up se přestane tvořit.

Jak to příště poznat dřív

• Test „tým odpověděl po příchozím e-mailu → akce se nezakládá/degraduje” patří do unit testů plánovače od první verze.
• U lhůt počítat pracovní dny (pátek → pondělí = 1 den, ne 3) a mít na to test.
• Při napojování AI vrstvy na komunikaci si vypsat VŠECHNY hodnoty direction/typů zpráv ve zdrojové DB — systémové a interní záznamy vyfiltrovat už v syncu.