ADR-0005: Anthropic SDK direct, mitigation seam at llm.call

Status: Accepted (with explicit accepted risk)
Date: 2026-05-08
Deciders: Seth (Lead Architect), Blair (CEO sign-off REQUIRED)

Context

SPEC §8.4: “no LangChain in V1.” The cost review’s pushback trigger #10
named the Anthropic-dependency mitigation as a gap not to hand-wave.
Blair’s JD §3 (Architecture material choices) requires explicit signoff
on “the Anthropic dependency and any plan to mitigate it.”

Decision

Use the Anthropic SDK directly from src/memberintel/llm/call.py. No
LangChain, no Anthropic Agent SDK at the runtime layer. Internal dev
tooling under tools/ may use the Agent SDK for productivity (no
unit-economics consequence there).

Mitigation seam: llm.call(handle, operation, prompt, ...) is the only
place the SDK is invoked. If we ever need to portability-test a different
provider (or run an A/B between providers), this is the one file that
changes.

Consequences

Positive:

• Cost discipline guarantees (max_tokens enforcement, recorded cost) live in one file.
• Eval suite has a single boundary to test.
• Internal tooling can use Agent SDK for productivity.

Negative / costs:

• We forfeit Agent SDK’s tool-use orchestration at the runtime layer; we write the tool dispatch ourselves (~200 LoC in Slice 1+).
• Provider portability is a discipline we maintain, not a property the SDK gives us.

Mitigations:

• The wrapper’s signature (handle + operation + prompt + system) is provider-neutral.
• The cost record schema (tier, operation, usage) is provider-neutral.

Alternatives considered

• LangChain — rejected: explicit SPEC §8.4 ban; abstraction debt; max_tokens enforcement opaque.
• Anthropic Agent SDK at runtime — rejected: agent-loop and tool-use abstractions hide max_tokens and model selection (the two cost-discipline invariants).
• LiteLLM router — rejected for V1: adds a layer for cross-provider routing we don’t need yet; revisit if multi-provider becomes a real ask.