Series: Building Quorentra CRM from Zero — A Modular, ChatGPT-Native AI CRM

Designing the complete MVP architecture with React, FastAPI, PostgreSQL, modular domain services, MCP, ChatGPT, and the OpenAI Apps SDK.

1. Introduction

In Part 1, we defined what Quorentra is intended to become:

A modular, ChatGPT-native AI CRM in which Quorentra remains the system of record while ChatGPT becomes a first-class intelligent interaction layer.

We also established an important development principle:

Every stage of development must leave Quorentra in a runnable state.

Before creating directories, installing dependencies, defining database tables, or writing FastAPI endpoints, we need one more architectural artifact.

We need to define how the complete MVP fits together.

This does not mean implementing the entire architecture immediately.

Instead, we will establish a technical reference model that tells us:

• where responsibilities belong;
• how components communicate;
• where business logic lives;
• how tenant isolation is enforced;
• how ChatGPT accesses CRM capabilities;
• where AI processing belongs;
• how knowledge retrieval fits into the platform;
• how workflows use domain capabilities;
• how future modules can be added without restructuring the entire application.

By the end of this article, we will have the architectural blueprint that the remainder of the MVP series will implement incrementally.

2. The Complete Quorentra MVP Architecture

At the highest level, Quorentra has two primary user interaction surfaces.

The first is the conventional CRM web application.

The second is ChatGPT.

Conceptually:

                         USER
                          │
              ┌───────────┴───────────┐
              │                       │
              ▼                       ▼
          ChatGPT                Web Browser
              │                       │
              ▼                       ▼
       Quorentra ChatGPT          React CRM
             App                      │
              │                       │
        OpenAI Apps SDK               │
              │                       │
              ▼                       │
          MCP Server                  │
              │                       │
              └───────────┬───────────┘
                          │
                          ▼
                       FastAPI
                          │
                          ▼
                  Application Layer
                          │
              ┌───────────┼───────────┐
              │           │           │
              ▼           ▼           ▼
          CRM Modules   AI Layer   Workflow Layer
              │           │           │
              └───────────┼───────────┘
                          │
                          ▼
                  Persistence Layer
                          │
                          ▼
                     PostgreSQL
                          +
                       pgvector

This diagram represents the target MVP architecture.

We will not implement every component immediately.

Instead, the architecture will emerge incrementally while preserving these boundaries.

3. The Architectural Layers

The Quorentra backend will use a layered modular architecture.

At a high level:

Interfaces
    │
    ▼
Application Services
    │
    ▼
Domain
    │
    ▼
Repositories
    │
    ▼
Persistence

Cross-cutting capabilities such as authentication, tenant context, configuration, auditing, logging, and authorization support these layers.

The purpose of the separation is simple.

Business rules should not depend on how the user happens to interact with Quorentra.

A salesperson might create an opportunity through React.

Another user might create the same opportunity through ChatGPT.

A workflow might eventually create an opportunity automatically.

All three should ultimately use the same business capability.

4. Interface Layer

Quorentra will eventually expose several interfaces.

For the MVP, the most important are:

┌───────────────────────┐
│      Interfaces       │
├───────────────────────┤
│ REST API              │
│ React Web UI          │
│ MCP Tools             │
│ Workflow Actions      │
└───────────────────────┘

These interfaces translate external intent into application operations.

They should contain as little business logic as possible.

For example, a REST endpoint might receive:

POST /api/v1/opportunities

An MCP tool might receive:

create_opportunity(...)

Both should eventually invoke:

OpportunityService.create(...)

This becomes one of the most important architectural rules in Quorentra:

Interfaces invoke business capabilities; they do not implement them.

5. React Frontend Architecture

The Quorentra web interface will use React and TypeScript.

React provides the traditional CRM experience.

Users will use it for tasks such as:

• viewing dashboards;
• browsing companies;
• editing contacts;
• managing opportunities;
• moving opportunities through pipeline stages;
• reviewing activities;
• managing tasks;
• configuring settings.

The initial frontend architecture will look approximately like:

frontend/
└── src/
    ├── api/
    ├── app/
    ├── components/
    ├── features/
    ├── hooks/
    ├── layouts/
    ├── pages/
    ├── routes/
    ├── types/
    ├── utils/
    └── main.tsx

Feature-specific functionality will progressively live under:

features/
├── auth/
├── companies/
├── contacts/
├── opportunities/
├── activities/
├── tasks/
└── dashboard/

This gives the frontend the same modular philosophy as the backend.

6. React Does Not Own Business Rules

It is tempting to place validation and business logic inside frontend components.

For example:

if opportunity.value > 100000:
    require_manager_approval()

That would be architecturally dangerous.

Why?

Because ChatGPT would not necessarily use that frontend.

Neither would workflow automation.

The actual business rule must therefore live in the backend.

The frontend may provide usability validation, but authoritative validation belongs to Quorentra’s application/domain layer.

Conceptually:

React
   │
   ▼
FastAPI
   │
   ▼
OpportunityService
   │
   ▼
Business Rules

The same rule then applies regardless of interface.

7. FastAPI as the Application Gateway

FastAPI will provide the primary application API.

Its responsibilities include:

• HTTP routing;
• request validation;
• response serialization;
• authentication integration;
• dependency injection;
• tenant context;
• authorization hooks;
• error handling;
• API versioning;
• request correlation.

The API structure will initially follow:

/api/v1/

For example:

GET    /api/v1/health
POST   /api/v1/auth/register
POST   /api/v1/auth/login
GET    /api/v1/companies
POST   /api/v1/companies
GET    /api/v1/contacts
POST   /api/v1/contacts
GET    /api/v1/opportunities
POST   /api/v1/opportunities
GET    /api/v1/tasks
POST   /api/v1/tasks

These routes are interfaces.

They should remain thin.

8. The Modular Monolith

For the MVP, Quorentra will be implemented as a modular monolith.

This gives us a single deployable backend while preserving clear module boundaries.

A future backend structure may look like:

backend/
└── app/
    ├── api/
    ├── core/
    ├── db/
    ├── modules/
    │   ├── organizations/
    │   ├── users/
    │   ├── companies/
    │   ├── contacts/
    │   ├── opportunities/
    │   ├── activities/
    │   ├── tasks/
    │   └── knowledge/
    ├── ai/
    ├── workflows/
    └── main.py

The important word here is modular.

We want the operational simplicity of a monolith without creating one giant unstructured application.

9. Why We Are Not Starting with Microservices

A CRM can eventually become large enough to justify separate services.

For example:

Identity Service
CRM Service
Knowledge Service
AI Service
Workflow Service
Notification Service
Integration Service

But each service introduces operational complexity:

• deployment;
• service discovery;
• networking;
• authentication between services;
• distributed tracing;
• retry policies;
• event consistency;
• version management;
• additional infrastructure.

For the MVP, that complexity would slow development without delivering proportional value.

Therefore:

Quorentra begins as a modular monolith and earns distributed architecture later.

If module boundaries are designed correctly, selected components can be extracted later if required.

10. Application Services

Application services form the reusable capability layer.

Examples will eventually include:

OrganizationService
UserService
CompanyService
ContactService
OpportunityService
ActivityService
TaskService
KnowledgeService

Consider OpportunityService.

It may eventually support operations such as:

create_opportunity()
get_opportunity()
search_opportunities()
update_opportunity()
change_stage()
close_won()
close_lost()

These operations can be consumed by multiple interfaces.

                     OpportunityService
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
          ▼                  ▼                  ▼
       REST API           MCP Tools          Workflow
          │                  │                  │
          ▼                  ▼                  ▼
        React             ChatGPT           Automation

This is one of the central architectural patterns of Quorentra.

11. Domain Layer

The domain layer represents CRM concepts and rules.

Examples include:

• organization;
• membership;
• company;
• contact;
• opportunity;
• pipeline stage;
• activity;
• task.

The domain layer answers questions such as:

• Can this opportunity move to this stage?
• Can this user modify this record?
• Does this contact belong to this organization?
• Is this task state transition valid?
• Is this operation allowed for the current tenant?

The domain should not care whether a request originated from React, ChatGPT, or automation.

12. Repository Layer

Application services should not be tightly coupled to raw database queries.

Repositories provide a persistence abstraction.

For example:

OpportunityService
        │
        ▼
OpportunityRepository
        │
        ▼
SQLAlchemy
        │
        ▼
PostgreSQL

The repository might expose:

get_by_id()
list()
search()
create()
update()
delete()

It also becomes an important location for enforcing tenant-aware database access patterns.

13. PostgreSQL as the System of Record

PostgreSQL will be the authoritative persistence platform for the MVP.

It will store structured CRM information such as:

organizations
users
memberships
companies
contacts
opportunities
pipeline_stages
activities
tasks
documents
audit_events

Later, PostgreSQL will also store vector embeddings using pgvector.

This gives us:

PostgreSQL
   │
   ├── relational CRM data
   │
   ├── transactional data
   │
   ├── metadata
   │
   ├── audit records
   │
   └── vector embeddings

For the MVP, this is simpler than introducing several specialized databases prematurely.

14. Database Identity Strategy

Most core entities will use stable unique identifiers.

Conceptually:

Organization
    id
Company
    id
    organization_id
Contact
    id
    organization_id
    company_id
Opportunity
    id
    organization_id
    company_id

Tenant ownership should be explicit.

We do not want tenant membership inferred indirectly through complicated joins whenever it can be represented clearly.

This becomes especially important for security.

15. Multi-Tenant Architecture

Quorentra will initially use a shared-database, shared-schema multi-tenant model.

Conceptually:

PostgreSQL
    │
    ├── Organization A
    │      ├── Companies
    │      ├── Contacts
    │      └── Opportunities
    │
    └── Organization B
           ├── Companies
           ├── Contacts
           └── Opportunities

Records will carry an organization identifier.

Requests will execute within an authenticated tenant context.

Conceptually:

HTTP Request
     │
     ▼
Authentication
     │
     ▼
User
     │
     ▼
Membership
     │
     ▼
Organization Context
     │
     ▼
Application Service
     │
     ▼
Tenant-Scoped Repository

Tenant isolation must not rely on the frontend hiding records.

It must be enforced server-side.

16. Authentication Architecture

Authentication will establish who the user is.

Authorization will determine what that user may do.

These are different concerns.

The initial flow will resemble:

User
  │
  ▼
Login
  │
  ▼
Authentication Service
  │
  ▼
Identity Established
  │
  ▼
Organization Membership
  │
  ▼
Role / Permissions
  │
  ▼
Authorized Operation

The first RBAC model will remain intentionally small:

Owner
Admin
Member

We can expand the permission system when real requirements demand it.

17. MCP Architecture

MCP is what allows Quorentra capabilities to become accessible to ChatGPT.

The architecture should be:

ChatGPT
   │
   ▼
Quorentra App
   │
   ▼
MCP Server
   │
   ▼
Application Services
   │
   ▼
Repositories
   │
   ▼
PostgreSQL

The MCP server is an interface adapter.

It is not a second backend.

This distinction is critical.

18. MCP Tool Design

An MCP tool should represent a clear application capability.

For example:

search_companies

might accept:

query
limit

and return structured company information.

Likewise:

get_opportunity

might accept:

opportunity_id

and return an authorized representation of that opportunity.

The MCP implementation should invoke the same application services used elsewhere.

For example:

MCP get_opportunity
        │
        ▼
OpportunityService.get()
        │
        ▼
OpportunityRepository
        │
        ▼
PostgreSQL

19. Tool Design for AI

Tools intended for AI require slightly different thinking from conventional APIs.

An API may expose dozens of low-level endpoints.

AI tools should generally expose meaningful operations.

For example, instead of forcing ChatGPT to reconstruct a customer history using many unrelated database calls, Quorentra might eventually provide:

get_customer_timeline

or:

prepare_account_context

The tool should represent a useful CRM capability while still preserving clear security and authorization boundaries.

20. Read Tools First

The initial MCP implementation will focus on read operations.

Examples:

get_crm_status
get_current_user
get_organization
list_companies
search_companies
get_company
list_contacts
search_contacts
get_contact
list_opportunities
get_opportunity
list_tasks
get_customer_timeline

This allows us to validate:

• ChatGPT connectivity;
• authentication;
• tenant context;
• tool schemas;
• data serialization;
• authorization;
• error handling.

Only after these work reliably will we introduce write tools.

21. Write Tools

Write operations may eventually include:

create_company
update_company
create_contact
update_contact
create_opportunity
update_opportunity
change_opportunity_stage
create_task
complete_task
record_activity

Write tools carry greater risk.

They therefore require additional controls.

22. The AI Action Boundary

A write operation initiated through ChatGPT should follow:

User
  │
  ▼
ChatGPT
  │
  ▼
MCP Tool
  │
  ▼
Authentication
  │
  ▼
Authorization
  │
  ▼
Input Validation
  │
  ▼
Business Rules
  │
  ▼
Confirmation if required
  │
  ▼
Application Service
  │
  ▼
Transaction
  │
  ▼
Audit Event

ChatGPT never becomes the security boundary.

Quorentra remains responsible for deciding whether an operation can occur.

23. OpenAI Apps SDK Architecture

The OpenAI Apps SDK will allow Quorentra to become a richer ChatGPT application rather than merely exposing isolated tools.

Conceptually:

ChatGPT
   │
   ▼
Quorentra ChatGPT App
   │
   ├── conversational interaction
   │
   ├── Quorentra tools
   │
   └── interactive UI where appropriate
   │
   ▼
MCP
   │
   ▼
Quorentra Backend

This gives us the possibility of combining conversational interaction with structured CRM experiences.

For example, a user could ask:

Show my pipeline.

Quorentra could provide structured pipeline data that ChatGPT can use as part of the interaction.

The Apps SDK therefore becomes an application surface, not the CRM’s source of truth.

24. Knowledge Architecture

Once the core CRM and ChatGPT connection work, Quorentra will introduce unstructured knowledge.

The knowledge pipeline will eventually resemble:

Uploaded Document
       │
       ▼
Document Storage
       │
       ▼
Text Extraction
       │
       ▼
Normalization
       │
       ▼
Chunking
       │
       ▼
Embedding Generation
       │
       ▼
pgvector

Each chunk will carry metadata such as:

organization_id
document_id
entity_type
entity_id
source_type
created_at

This metadata is essential for tenant-aware retrieval.

25. Retrieval Architecture

A user may ask:

What did Acme say about security requirements?

Quorentra should not simply perform global vector similarity search.

Retrieval must consider business context.

Conceptually:

Question
   │
   ▼
Tenant Filter
   │
   ▼
Entity Context
   │
   ▼
Structured Filters
   │
   ├───────────────┐
   ▼               ▼
Keyword Search   Vector Search
   │               │
   └───────┬───────┘
           ▼
        Ranking
           │
           ▼
Relevant Evidence

This eventually becomes hybrid retrieval.

26. CRM Context Builder

The Context Builder sits above raw retrieval.

Its responsibility is to assemble the information needed for a particular AI task.

Suppose the user asks:

Which opportunities need attention?

The Context Builder might retrieve:

Open Opportunities
       +
Recent Activities
       +
Outstanding Tasks
       +
Stage Age
       +
Expected Close Dates
       +
Relevant Notes
       +
Customer Context

It then produces a structured context package for AI reasoning.

Conceptually:

User Question
      │
      ▼
Intent / Context Request
      │
      ▼
CRM Context Builder
      │
 ┌────┼─────────┬─────────┐
 ▼    ▼         ▼         ▼
CRM  Timeline  Tasks   Knowledge
 │    │         │         │
 └────┴────┬────┴─────────┘
           ▼
      Context Package
           │
           ▼
       AI Reasoning

This component will eventually become one of Quorentra’s major differentiators.

27. AI Service Layer

Quorentra should avoid direct model calls scattered across modules.

Instead:

CRM Module
    │
    ▼
AI Service
    │
    ▼
Model Provider

The AI layer can eventually provide capabilities such as:

summarize()
extract_structured_data()
classify()
analyze()
generate_recommendations()

It can also centralize:

• model configuration;
• prompt management;
• structured outputs;
• token accounting;
• retries;
• usage tracking;
• model selection;
• safety controls.

28. ChatGPT Versus Backend AI

An important architectural distinction is that Quorentra may use AI in two contexts.

ChatGPT interaction

User
 ↓
ChatGPT
 ↓
MCP
 ↓
Quorentra

Backend AI processing

Quorentra
 ↓
AI Service
 ↓
Model API

These solve different problems.

ChatGPT is the conversational environment.

Backend AI is useful for asynchronous or application-controlled operations such as:

• document processing;
• extraction;
• classification;
• automated summaries;
• scheduled analysis;
• workflow intelligence.

We should use each where it provides the greatest value.

29. Workflow Architecture

The MVP will eventually include a lightweight workflow engine.

A workflow can be represented as:

Event
  ↓
Trigger
  ↓
Conditions
  ↓
Actions

For example:

opportunity.stage_changed
          ↓
stage = proposal
          ↓
create follow-up task

Later:

opportunity.stage_changed
          ↓
AI analyzes opportunity context
          ↓
risk detected
          ↓
recommend action

The workflow engine should consume the same application services as REST and MCP.

Again:

One capability, multiple interfaces.

30. Domain Events

Modules will eventually communicate using domain events.

Examples:

company.created
contact.created
opportunity.created
opportunity.updated
opportunity.stage_changed
opportunity.won
opportunity.lost
activity.recorded
task.created
task.completed

Initially these events can remain in-process.

We do not need Kafka or another distributed event platform for the MVP.

The abstraction matters more than the infrastructure.

31. Audit Architecture

Quorentra needs to know how important state changes occurred.

An audit record might contain:

event_id
organization_id
user_id
source
action
entity_type
entity_id
timestamp
metadata

The source could identify:

web
api
chatgpt
workflow
system

This becomes particularly useful when AI-driven actions are introduced.

32. Observability Architecture

The MVP requires enough observability to diagnose failures.

We will eventually track:

Request
   │
   ▼
Correlation ID
   │
   ├── FastAPI
   ├── Application Service
   ├── Repository
   ├── MCP
   └── AI Operation

Initial observability will include:

• structured logs;
• request IDs;
• error logging;
• health checks;
• AI usage information;
• MCP tool-call logging.

We will not begin with a huge enterprise observability platform.

33. Error Architecture

Errors should be translated consistently.

For example:

Domain Error
    │
    ▼
Application Error
    │
    ▼
Interface Mapping

REST may translate an error into:

HTTP 404

while MCP may represent the same underlying condition in a tool-compatible response.

The domain should not generate HTTP-specific logic.

This separation keeps the core reusable.

34. Configuration Architecture

Configuration will be environment-driven.

For example:

APP_ENV
DATABASE_URL
SECRET_KEY
FRONTEND_URL
OPENAI_API_KEY

Not every variable will exist in the first implementation.

We will add configuration as capabilities are introduced.

Sensitive configuration must never be committed to Git.

The repository will contain:

.env.example

rather than real credentials.

35. Initial Repository Architecture

The canonical repository will evolve toward:

quorentra/
│
├── backend/
│   ├── app/
│   │   ├── api/
│   │   ├── core/
│   │   ├── db/
│   │   ├── modules/
│   │   ├── ai/
│   │   ├── workflows/
│   │   └── main.py
│   │
│   └── tests/
│
├── frontend/
│   └── src/
│       ├── api/
│       ├── app/
│       ├── components/
│       ├── features/
│       ├── layouts/
│       ├── pages/
│       └── routes/
│
├── mcp/
│
├── scripts/
│
├── docs/
│
├── docker/
│
├── .env.example
├── docker-compose.yml
├── .gitignore
└── README.md

We will not create empty complexity merely to match this final structure.

Directories will be introduced as needed.

36. Development Architecture

Local development should eventually allow the developer to run:

PostgreSQL
     │
FastAPI
     │
React
     │
MCP

independently.

This makes debugging easier.

During early development, we will favor direct local execution.

Later, Docker Compose will provide a reproducible integrated environment.

This gives us both:

Native development

and:

Containerized integration

without forcing every edit through a container during the earliest stages.

37. Testing Architecture

Testing will be introduced progressively.

The backend will eventually contain:

tests/
├── unit/
├── integration/
└── api/

We will test:

• domain behavior;
• application services;
• repositories;
• APIs;
• tenant isolation;
• authentication;
• MCP tools;
• AI structured behavior where practical.

The goal is not maximum test count.

The goal is confidence in architectural boundaries and critical workflows.

38. The Vertical Slice Pattern

Every CRM module should follow the same development path.

For example, when we build Companies:

Migration
   ↓
Database Model
   ↓
Repository
   ↓
Application Service
   ↓
Schemas
   ↓
REST API
   ↓
React Feature
   ↓
Tests
   ↓
MCP Tool

We may introduce the MCP portion later than the initial REST/React implementation, but the service boundary should already support it.

The same pattern repeats for:

Contacts
Opportunities
Activities
Tasks
Knowledge

This repetition is intentional.

It makes Quorentra predictable.

39. Dependency Direction

A clean architecture depends heavily on dependency direction.

The desired direction is approximately:

Interfaces
    │
    ▼
Application
    │
    ▼
Domain

Infrastructure supports the application through defined boundaries.

We should avoid patterns such as:

Domain → React
Domain → FastAPI
Domain → MCP
Domain → OpenAI SDK

The CRM domain should remain as independent as practical from external frameworks.

40. The Complete Request Path

Consider a conventional browser request.

A user creates an opportunity.

React
  │
  ▼
POST /api/v1/opportunities
  │
  ▼
FastAPI Router
  │
  ▼
Authentication / Tenant Context
  │
  ▼
OpportunityService
  │
  ▼
Business Validation
  │
  ▼
OpportunityRepository
  │
  ▼
SQLAlchemy
  │
  ▼
PostgreSQL

Now compare a ChatGPT request.

The user says:

Create an opportunity for Acme worth €75,000.

The path becomes:

User
  │
  ▼
ChatGPT
  │
  ▼
Quorentra App
  │
  ▼
MCP create_opportunity
  │
  ▼
Authentication / Tenant Context
  │
  ▼
OpportunityService
  │
  ▼
Business Validation
  │
  ▼
OpportunityRepository
  │
  ▼
PostgreSQL

Notice what happens.

The upper interface changes.

The core does not.

That is exactly what we want.

41. The Complete AI Request Path

Now consider:

Which opportunities need my attention?

The architecture eventually becomes:

User
  │
  ▼
ChatGPT
  │
  ▼
Quorentra MCP Tool
  │
  ▼
CRM Context Builder
  │
  ├── OpportunityService
  ├── ActivityService
  ├── TaskService
  └── Knowledge Retrieval
           │
           ▼
     Context Package
           │
           ▼
        ChatGPT
           │
           ▼
     Recommendation

Quorentra retrieves and structures authoritative context.

ChatGPT reasons over it.

42. The Complete AI Action Path

Finally:

Create follow-up tasks for the three opportunities you recommended.

The flow becomes:

User
  │
  ▼
ChatGPT
  │
  ▼
Proposed Actions
  │
  ▼
MCP Tools
  │
  ▼
Authorization
  │
  ▼
Validation
  │
  ▼
Confirmation where required
  │
  ▼
TaskService
  │
  ▼
PostgreSQL
  │
  ▼
Audit Events

This is the full architectural proposition of the Quorentra MVP.

43. Architecture Evolution

The architecture is intentionally designed to evolve.

The MVP starts:

React
  ↓
FastAPI
  ↓
PostgreSQL

Then becomes:

React
  ↓
FastAPI
  ↓
Modular CRM
  ↓
PostgreSQL

Then:

ChatGPT       React
   │            │
   MCP        REST
   │            │
   └──────┬─────┘
          ▼
       Quorentra

Then:

ChatGPT
   │
Quorentra
   │
CRM + Knowledge
   │
Context Builder
   │
AI Intelligence

And eventually:

ChatGPT
   │
Quorentra
   │
CRM + Knowledge + AI + Workflows
   │
Controlled Business Actions

Each stage extends the previous stage rather than replacing it.

44. Architectural Decisions Established

We can now record the major architectural decisions for the MVP.

ADR-001 — Modular Monolith First

Quorentra will begin as a modular monolith.

ADR-002 — PostgreSQL as System of Record

PostgreSQL will hold authoritative CRM data.

ADR-003 — Shared Schema Multi-Tenancy

The MVP will use organization-scoped records within a shared database/schema.

ADR-004 — Application Services Own Use Cases

Business capabilities will be exposed through reusable application services.

ADR-005 — Thin Interfaces

REST and MCP will adapt external requests to application capabilities.

ADR-006 — React Is Not the Business Layer

Authoritative validation and business rules remain server-side.

ADR-007 — MCP Is Not a Second Backend

MCP tools reuse Quorentra application services.

ADR-008 — ChatGPT Is a First-Class Interface

ChatGPT is designed into the architecture rather than added as a late chatbot feature.

ADR-009 — Quorentra Remains Authoritative

ChatGPT never becomes the system of record or authorization authority.

ADR-010 — Read Before Write

AI access begins with retrieval before controlled mutations are introduced.

ADR-011 — PostgreSQL + pgvector for MVP Knowledge

Semantic retrieval will initially use the existing PostgreSQL platform.

ADR-012 — Context Before AI Reasoning

Quorentra will assemble authorized CRM context before asking AI to reason over it.

ADR-013 — Human Control for Sensitive Actions

Risk-sensitive AI actions can require explicit confirmation.

ADR-014 — Audit AI-Initiated Mutations

Important ChatGPT and workflow-driven changes must be traceable.

ADR-015 — Complexity Must Be Earned

Microservices, Kubernetes, distributed messaging and similar infrastructure will be introduced only when justified.

These decisions now become part of the architectural contract for subsequent articles.

45. MVP Architecture Acceptance Criteria

The architecture is suitable for the MVP if it can ultimately support the following without major redesign.

A user can:

1. register;
2. create or join an organization;
3. authenticate;
4. manage companies;
5. manage contacts;
6. manage opportunities;
7. manage pipeline stages;
8. record activities;
9. manage tasks;
10. view CRM dashboards.

The same user can then access Quorentra through ChatGPT and:

1. find companies;
2. retrieve contacts;
3. inspect opportunities;
4. review activities;
5. retrieve tasks;
6. request account context;
7. search organizational knowledge;
8. ask grounded CRM questions;
9. receive recommendations;
10. initiate controlled CRM actions.

The platform must enforce the same tenant and business rules regardless of interface.

46. What We Will Not Build Yet

Although we have now described the complete MVP architecture, Part 3 will not create every component shown here.

We will not immediately implement:

• AI agents;
• embeddings;
• pgvector;
• RAG;
• MCP;
• workflow automation;
• advanced auditing;
• sophisticated RBAC;
• Kubernetes;
• distributed messaging;
• microservices.

Instead, we will build the architecture in increments.

Our first implementation objective remains:

Browser
   ↓
React
   ↓
FastAPI
   ↓
PostgreSQL

Once that works, we add the next vertical capability.

47. The Implementation Sequence

The technical architecture gives us the destination.

The implementation sequence gives us the route.

Repository
    ↓
FastAPI
    ↓
PostgreSQL
    ↓
React
    ↓
Identity
    ↓
Multi-Tenancy
    ↓
Companies
    ↓
Contacts
    ↓
Opportunities
    ↓
Activities
    ↓
Tasks
    ↓
Dashboard
    ↓
MCP
    ↓
ChatGPT
    ↓
Knowledge
    ↓
AI Context
    ↓
AI Actions
    ↓
Workflows
    ↓
Production

Every step must produce working software.

48. The Architecture in One Diagram

The complete MVP reference architecture can now be summarized as:

                           USER
                            │
               ┌────────────┴────────────┐
               │                         │
               ▼                         ▼
            ChatGPT                  Web Browser
               │                         │
         Quorentra App                   │
               │                         ▼
         OpenAI Apps SDK              React
               │                         │
               ▼                         │
           MCP Server                    │
               │                         │
               └────────────┬────────────┘
                            ▼
                         FastAPI
                            │
             Authentication / Tenant Context
                            │
                            ▼
                    Application Services
                            │
       ┌────────────────────┼────────────────────┐
       │                    │                    │
       ▼                    ▼                    ▼
   CRM Modules          AI Services          Workflows
       │                    │                    │
       │              Context Builder            │
       │                    │                    │
       │              Knowledge Layer            │
       │                    │                    │
       └────────────────────┼────────────────────┘
                            ▼
                       Repositories
                            │
                            ▼
                        SQLAlchemy
                            │
                            ▼
                       PostgreSQL
                            │
                    ┌───────┴───────┐
                    │               │
               Relational Data    pgvector

This is the architecture we will now build.

Not all at once.

Module by module.

Checkpoint by checkpoint.

49. The Most Important Architectural Rule

If there is one rule to carry into the implementation phase, it is this:

Build business capabilities once and expose them through multiple interfaces.

We do not want:

React business logic
+
REST business logic
+
MCP business logic
+
workflow business logic

We want:

                Business Capability
                        │
          ┌─────────────┼─────────────┐
          │             │             │
        REST           MCP         Workflow
          │             │             │
        React        ChatGPT       Automation

This is what will allow Quorentra to remain manageable as the project grows.

50. What Comes Next

We now have two critical artifacts.

Part 1 defined the product, MVP strategy, development principles, and roadmap.

Part 2 defined the complete technical architecture.

Now we stop designing and start building.

In Part 3, we will create the Quorentra repository and establish the development environment from zero.

We will define the canonical directory structure, initialize Git, create the Python backend environment, prepare the frontend workspace, establish environment configuration, and introduce the first development commands.

Most importantly, Part 3 will establish the repository structure that every subsequent article will use.

From that point onward, the series becomes an incremental construction process:

Empty Directory
      ↓
Repository
      ↓
Running Backend
      ↓
Connected Database
      ↓
Running Frontend
      ↓
Working CRM
      ↓
ChatGPT-Native CRM
      ↓
AI CRM

The architectural planning is complete.

It is time to create Quorentra.