AI Sales Agent CRM Architecture

The business problem: understand a deal without turning a hypothesis into fact

A manager works across amoCRM deal state, Wazzup conversations, tasks, calls and Yonote knowledge. A simple “send the chat to GPT and write the answer back” integration cannot establish which deal the conversation belongs to, what the model actually saw, why it reached a conclusion or whether an action is safe.

This system is therefore a production-oriented reasoning pipeline around real business data. It preserves provenance, freezes the source state, requires bounded evidence references and checks structured output against contracts before it can influence the workflow.

The evidence-first pipeline

1. Ingestion and normalization

   amoCRM, Wazzup, call transcripts and Yonote become local records with source identity, time and provenance.

   source evidence

2. Entity Resolution

   Structured identifiers connect a messenger identity, CRM contact and active deal. Ambiguity remains an explicit result.

   resolved · ambiguous · unresolved

3. Immutable Deal Context

   Source watermarks and normalized records form a versioned, immutable Context Package.

   snapshot · version · provenance

4. Fact Extraction and Resolver

   The model proposes facts, scenario, business goal, prerequisites and ownership through typed output with evidence references.

   AI interpretation

5. Contracts and validation

   Deterministic code verifies types, reference existence, completion validity, blockers and ownership.

   accept or reject

6. Clarification or action boundary

   A missing critical fact is requested from a manager; external actions remain a separate, explicitly constrained boundary.

   human-in-the-loop

Entity Resolution before reasoning

Immutable context and reproducibility

The model does not reason directly over a continuously changing collection of API responses. Normalized deal state and source watermarks are frozen into a Context Package. New evidence creates a new version; an earlier AI result stays linked to the snapshot that produced it.

The audit trail retains the input package, raw provider response, mechanical normalization and accepted canonical result. A later review can distinguish changed business evidence from a changed interpretation.

The deterministic safety layer

• Nonexistent evidence reference → reject. A conclusion cannot cite an item absent from the frozen input.
• Wrong evidence type → reject. Every reference must match its source type and run-local alias.
• Unsupported completion → reject. Completion must satisfy the contract for the active goal.
• Invalid prerequisite → reject. A post-decision requirement cannot be promoted into a current blocker.
• Invalid ownership → reject. Ownership is derived from accepted prerequisite state rather than fluent prose.

Human-in-the-loop without replacing evidence

When the Resolver finds an unconfirmed critical prerequisite, deterministic eligibility is checked before a scoped question is sent to the manager. The answer becomes immutable human evidence, a new Context Package is built, and reasoning runs over the updated state.

Human assertion has bounded authority: it records what the manager stated but does not prove an unrelated technical event or complete a sales goal automatically. The clarification path is separately gated, rate-limited, deduplicated and audited.

Call and operational intelligence

An operational observation is not a commercial conclusion. An overdue task may need attention, but it does not prove a customer refused or a deal was lost.

Authority model

Current implementation status