CSA LangGraph Pipeline Architecture

1

LangGraph Platform Deployment Strategy

The pipeline supports local CLI, FastAPI webhook, and Claude Code bridge. LangGraph Platform enables Docker-based deployment with Studio UI for visual debugging. Where should the pipeline run in production?

A — Docker on VPS Recommended Deploy as container alongside existing PM2 services. Full control, co-located with existing infra, Studio UI available.

B — LangGraph Cloud LangChain-hosted managed infrastructure. Zero-ops, auto-scaling, but vendor lock-in and recurring cost.

C — Local-only Trigger via Claude Code bridge as needed. Zero infrastructure, but no API access, no webhook triggers.

2

Checkpointer Migration Path

Currently using SqliteSaver for single-machine persistence. PostgresSaver is a one-line code change but requires a running PostgreSQL instance. What persistence backend for pipeline state?

A — Stay on SQLite Recommended No change until multi-user access is needed. Zero infrastructure, sufficient for single-operator use.

B — PostgresSaver now Migrate immediately for future-proofing. Concurrent access, shared state, but requires PostgreSQL instance.

C — Hybrid MemorySaver for dev, SQLite for production. Fast dev cycles but two code paths to maintain.

3

Webhook Integration Priority

Three webhook integrations are built and tested but not yet wired to live services. Enabling them determines how the pipeline gets triggered automatically. Which to enable first?

A — Form-response first Recommended Enable submit.php → webhook callback. Closes the flywheel loop: client responds → new CSA run automatically.

B — Slack webhook first Auto-capture from Slack channel discussions. Broadest trigger surface but needs noise filtering.

C — All simultaneously Enable all three webhook integrations at once. Complete automation but higher integration risk.

D — Manual-only Keep current state, revisit when client volume increases. Zero risk but no automation.

CSA LangGraph Pipeline Architecture

Response Summary