backend-architecturelisted

# Split by what deploys independently, not by folder taste Karma is not one FastAPI app; it's a **gateway** (`api/`, FastAPI on Cloud Run) that talks to an **agent service** (`agents/`, the ADK agent system on Vertex AI Agent Engine) over its own task-invocation boundary. The two ship on separate GitHub Actions workflows — `deploy-api.yml` targets Cloud Run, `deploy-agents.yml` targets Agent Engine — each gated by a `paths:` filter (`api/**` and `agents/**` respectively) so a change to one only redeploys that one, not both, alongside the equally path-filtered web and synthetic-env deploys. The gateway owns HTTP concerns: routing, auth, request validation, Firestore reads/writes. The agent service owns long-running agent reasoning and holds its own state (Memory Bank). Neither redeploying the gateway nor a slow agent invocation blocks the other, because they are genuinely different deploy targets, not two folders sharing one process. The question worth asking before drawing this line: does this piece of logic have a different scaling shape, a different deploy cadence, or a different failure mode than the rest of the service? Karma's Learner runs as its own asynchronous phase in the service lifecycle (`registered → learning → ready`, tracked in Firestore rather than held in the HTTP request) and needs a durable runtime; the gateway needs to answer a dashboard request in milliseconds. That mismatch is the actual argument for the split — not "microservices are more architectura