Lean Pilot Architecture

Pilot topology

Flutter application
  └── LiveKit Cloud or approved self-hosted LiveKit + TURN
          ├── farmer audio/video room
          └── optional officer participant

FastAPI modular application
  ├── room token/session API
  ├── case state and reasoning loop
  ├── STT/TTS and model adapters
  ├── adaptive frame-sampling worker
  ├── retrieval and research tools
  └── policy verification

PostgreSQL + PostGIS + pgvector
S3-compatible object storage
One background worker / queue

Why this is the minimum

LiveKit is no longer optional because the product thesis is a live call. The pilot still avoids unnecessary clusters: one media deployment, a modular application, one database, one object store and one worker can validate interaction quality, frame selection, reasoning, safety and economics.

Logical boundaries retained

Even in one deployable application, keep explicit modules for rooms/media, case state, reasoning, retrieval, context tools, research, policy, review and audit. This allows later extraction without paying microservice cost during discovery.

Pilot capacity assumptions

• Controlled concurrency and scheduled sessions where necessary.
• One active video subscription per AI agent, with low-rate sampling.
• No default full-call recording.
• Officer join limited by staffed operating hours.
• Load test TURN usage, mobile network variation and concurrent STT/TTS separately.

Add only when measured