Open Questions and Decision Points
Seven decisions still open and one now resolved (the LLM provider) — intentionally deferred until build time, with current preferences noted.
These decisions are open because they require production data, cost modelling, or regulatory sign-off before they can be finalised. The architecture is designed so that none of these decisions require significant rework once made — the interfaces are stable, the options are equivalent at the SDK or API level.
Decision Table
| # | Question | Options | Current Preference | Impact |
|---|---|---|---|---|
| 1 | LLM provider for AI Assistant ✅ | Anthropic Claude — Anthropic API or Amazon Bedrock (Claude) | RESOLVED — Anthropic Claude | Hosting channel is a deployment detail behind a provider abstraction; Claude tool use + MCP drive the agent tool layer |
| 2 | Temporal Cloud vs self-hosted on EKS | Temporal Cloud (SaaS) · Self-hosted on EKS | No preference — both use the same Java SDK | Operational burden vs control; same SDK means code is portable |
| 3 | Agentic framework | Anthropic SDK (native tool use / MCP) · LangGraph · LangChain | No preference — Python + FastAPI confirmed; provider locked to Anthropic Claude (Decision 1), framework TBD among Claude-compatible options | Agent capability design is framework-agnostic (see tool catalogue) |
| 4 | Monorepo vs polyrepo | Monorepo (all services in one repo) · Polyrepo (one repo per service) | Monorepo — small team, shared CI/CD, shared type definitions, easier refactoring | Developer experience, CI/CD complexity, cross-service versioning |
| 5 | Aurora Serverless v2 vs provisioned | Serverless v2 (auto-scale) · Provisioned (fixed capacity) | Serverless v2 for temporal-db (bursty write load during workflow history replay); provisioned for platform-db (predictable OLTP load) |
Cost predictability vs operational simplicity |
| 6 | Document AI provider | AWS Textract + custom NLP · Azure Document Intelligence · Google Document AI | AWS Textract — stays in-cloud with EKS; native S3 event integration; no data leaves AWS boundary | OCR accuracy, cost per page, multi-format support |
| 7 | React UI component library | Ant Design · MUI (Material UI) · Shadcn/ui · Custom | Ant Design — enterprise table/form components are production-grade; large ecosystem; proven in banking UIs | Development speed, licensing, bundle size, design system coherence |
| 8 | Mobile scope: Phase 1 or later? | Mobile alongside web (Phase 1) · Mobile after MEDIUM is live (Phase 2+) | After Phase 2 — banker/RM mobile value peaks when MEDIUM segment is live; Document Review Agent makes the mobile AI features meaningful | Go-live timeline, engineering bandwidth, user adoption |
Decision Notes
LLM Provider (Decision 1) — ✅ Resolved: Anthropic Claude
The provider is locked to Anthropic’s Claude model family. What stays flexible is the hosting channel, not the model:
- Anthropic API direct — simplest path; first-class access to the newest Claude models, native tool use, and the Model Context Protocol (MCP).
- Amazon Bedrock (Claude) — keeps inference inside the AWS boundary for data residency, with IAM-based auth and no API keys in secrets — the better fit for a regulated production deployment.
The agent service codes against a thin provider abstraction, so moving between the Anthropic API and Bedrock changes only configuration, not agent code. Claude’s native tool use and MCP (see Agentic AI) are what the agent tool layer is built on — which is why the model family, not merely “an LLM”, is the thing that is fixed.
Temporal Cloud vs Self-Hosted (Decision 2)
Both options use the identical Java SDK — io.temporal:temporal-sdk. Workflow, activity, and signal code is 100% portable. The only difference is:
- Temporal Cloud: SaaS; Temporal Inc. manages the server;
namespace.account.tmprl.cloud:7233as the connection endpoint - Self-hosted: Helm chart deployed to the
temporalEKS namespace; team manages upgrades and availability
Given that Temporal is the most operationally complex component in the platform, Temporal Cloud is worth serious consideration — but the decision is deferred until infrastructure cost modelling is complete.
Monorepo (Decision 4)
The monorepo preference is firm for the early stages of the project. A small team benefits significantly from:
- Shared TypeScript type definitions between the React workspace and the REST API spec
- Single CI/CD pipeline with cross-service integration tests
- Atomic commits that span service boundaries (e.g., a new GraphQL field + the React component that uses it)
Polyrepo migration is possible later if team size warrants it — the service boundaries are already clean.