Design goals
- Tenant isolation by design: every record, file, index and queue message is tenant-scoped.
- Deterministic rules around probabilistic AI: models assist; policies and systems of record decide.
- Provider neutrality: AI, speech, telephony and messaging providers sit behind adapters.
- Observable and recoverable: idempotent processing, retries, replay and traceable runs.
- Least privilege and deny by default: every endpoint has an explicit authorization policy.
Logical architecture
The platform is a modular core exposed through one API and a web application. Modules have explicit contracts and own their data.
| Layer | Components |
|---|---|
| Experience | Web application (installable PWA), public REST API and signed webhooks |
| Core modules | Identity and tenants · CRM and leads · communications · AI orchestration · knowledge and retrieval · workflow and scheduler · campaigns · integration hub · billing and usage · audit and governance · analytics |
| Data and messaging | PostgreSQL (system of record, with vector search), Redis (cache and rate limits), RabbitMQ (durable messaging), S3-compatible object storage |
| Telephony | FreeSWITCH controlled through an adapter; SIP trunks and number mappings kept separate from business logic |
| Providers | Language, speech, embedding, messaging and billing providers behind adapters |
| Observability | OpenTelemetry traces, Prometheus metrics, centralized structured logs |
Separation of concerns
The platform deliberately keeps different kinds of state apart so each can be reasoned about and recovered independently.
| Concept | Represents |
|---|---|
| CRM entities | Business state |
| Workflow runs | Process state |
| Conversation sessions | Interaction state |
| AI runs | Model and tool execution state |
| Provider events | External observations |
| Audit events | Traceable actions and changes |
| Analytics models | Derived aggregates, never the source of truth |
Reliability patterns
- Outbox pattern: events are written in the same transaction as the change and published afterwards, so nothing is lost between commit and publish.
- At-least-once delivery, idempotent consumers: duplicates are expected and harmless.
- No network calls inside database transactions.
- Bounded concurrency, timeouts, circuit breakers and provider-specific rate limits.
- Modular monolith first: clear modules and contracts, with services extracted only when load, ownership or failure isolation justifies it.
System of record boundaries
For each integration, EAIBAP documents which system owns each field, the sync direction, conflict rules and outage behavior.
| Data | Authoritative owner |
|---|---|
| Balances and payment status | Your core banking or payment system |
| Policy state and coverage facts | Your policy administration system |
| Call-leg media events | The telephony layer |
| Workflow state, activity history, routing decisions, AI configuration | EAIBAP |
| Analytics aggregates | Derived only |