Skip to content

Growth Strategy

How the system evolves without rewriting.

Phase 1: MVP (Current)

graph LR
    B[Book-E] -->|HTTP| A[Accounting API]
    A -->|HTTP| F[Folio/Fiken]
    A --> P[(PostgreSQL)]
  • Single pod per service
  • Event store in Postgres
  • In-memory conversation state in Book-E
  • Manual review via Discord
  • SHA-based GitOps deployment

Phase 2: Persistent Memory

graph LR
    B[Book-E] -->|HTTP| A[Accounting API]
    A -->|HTTP| F[Folio/Fiken]
    B --> PB[(Postgres<br/>conversations)]
    A --> PA[(Postgres<br/>events, patterns)]
  • Book-E memory in Postgres (survives restarts)
  • Pattern learning from approved events
  • Review-E integration for automated review

Phase 3: Automate-E Platform

graph LR
    G[Book-E Gateway] -->|BullMQ| W1[Worker 1]
    G -->|BullMQ| W2[Worker 2]
    G -->|BullMQ| W3[Worker N]
    W1 --> A[Accounting API]
    W2 --> A
    W3 --> A
    A --> P[(PostgreSQL)]
  • Gateway + Worker split
  • KEDA auto-scaling on queue depth
  • Redis for hot state
  • Multiple concurrent conversations

Phase 4: Multi-Agent

graph LR
    B[Book-E] --> ES[(Event Store)]
    R[Review-E] --> ES
    C[Cost-E] --> ES
    AL[Alert-E] --> ES
    RE[Report-E] --> ES
    ES <--> A[Accounting API]
    A --> F[Folio/Fiken]
    A --> CA[Cost APIs]
  • Multiple agents reading/writing events
  • Each agent has its own character file
  • New agents added without changing existing services
  • Shared event store as integration layer

Phase 5: Multi-Company

graph TB
    subgraph Company A
        BA[Book-E A] --> ESA[(Event Store A)]
        ESA --> AA[Accounting API]
        AA --> FA[Folio A / Fiken A]
    end
    subgraph Company B
        BB[Book-E B] --> ESB[(Event Store B)]
        ESB --> AB[Accounting API]
        AB --> FB[Folio B / Fiken B]
    end
  • Tenant isolation via namespace or schema
  • Same Accounting API, different credentials per company
  • Same Book-E runtime, different character files

What Doesn't Change

Across all phases, these stay constant:

Constant Why
Clean Architecture layers Engines don't do I/O. Managers orchestrate. ResourceAccess wraps external systems.
Event sourcing Every write action is an event. State derived from events.
Proposal → Review → Execute Agents propose, reviewers approve, system executes.
Secret isolation Each service only has the secrets it needs.
GitOps deployment Code → PR → CI → SHA image → ArgoCD → k8s.
C4 diagram levels L1 Context → L2 Containers → L3 Components → L4 Flows.

The architecture is designed so that adding capability doesn't require changing the foundation.