Rejecting LangChain: Why Direct AI Contracts Are More Maintainable Over Decades

By mid-2026, LangChain had become the dominant AI orchestration framework for Python-based AI applications. Most LLM application tutorials use it. Many companies' AI stacks are built on it. For a new AI project, using LangChain would have been the path of least resistance.

VANI's technology strategy chose the opposite path.

Should VANI use LangChain (or similar AI framework) for AI orchestration, or implement its own abstraction layer?

From docs/architecture/TECHNOLOGY_STRATEGY.md, Section 19.3 (Frameworks Explicitly Rejected):

LangChain — "Rapid abstraction churn, heavy dependencies, abstractions that leak. Direct API calls + custom contracts are more maintainable long-term."

The alternative: every AI capability is accessed through a typed Python Protocol contract defined by VANI's architecture. One adapter per provider. The cognitive core calls the contract, not the framework.

class AIPort(Protocol):
    async def complete(self, request: CompletionRequest) -> CompletionResponse: ...
    async def embed(self, texts: list[str]) -> list[list[float]]: ...
    def capabilities(self) -> ProviderCapabilities: ...

1. Rapid abstraction churn

LangChain's API surface changed substantially between versions 0.0.x, 0.1.x, 0.2.x, and 0.3.x — breaking changes within months. For a 50-year project, adopting a framework that requires significant code changes every 6 months creates a compounding maintenance burden.

2. Heavy dependencies

LangChain's dependency tree is substantial. Each added dependency is a potential security vulnerability, a licensing concern, and a future upgrade burden. VANI's constraint of 15 total external dependencies (across 9 phases) is fundamentally incompatible with adopting a framework with dozens of transitive dependencies.

3. Abstractions that leak

LangChain's abstractions expose provider-specific behaviors through their "universal" interface — tool calling conventions, streaming behaviors, context window handling, and structured output vary significantly between providers. The abstraction doesn't fully hide the differences; you still end up writing provider-specific code.

The AIPort protocol is the only AI integration point in VANI's cognitive core. Each provider implementation:

• Implements AIPort
• Maps provider-specific API calls to CompletionRequest/CompletionResponse
• Handles provider-specific errors internally
• Exposes ProviderCapabilities (what this provider can do)

The cognitive architecture never calls openai.ChatCompletion.create() directly. It calls ai_port.complete(request).

• docs/architecture/TECHNOLOGY_STRATEGY.md — Section 19.3 "Frameworks Explicitly Rejected" (LangChain entry)
• docs/architecture/TECHNOLOGY_STRATEGY.md — Section 4.3 "Provider Abstraction" (AIPort protocol definition)
• docs/architecture/AI_MODELS.md — P3 (Contracts Over APIs): "Every AI capability is accessed through a port contract that defines input/output without specifying the provider. The cognitive core asks 'reason about this situation' — not 'call GPT-4.'"

Established: LangChain is explicitly rejected. The three reasons are documented. The AIPort protocol is the documented alternative.

Established: The rejection is consistent with the broader technology selection framework: LangChain fails the "can it be replaced in <2 weeks?" test (its abstractions permeate application code), the "has it existed 5+ years?" test (LangChain was released in October 2022), and possibly the "can a single person maintain it?" test given the complexity.

Observation: The "rapid abstraction churn" criticism is specifically accurate for LangChain's 2023–2024 development trajectory. Whether this criticism remains valid in 2026 (when the strategy was written) is not established from the document.

Unknown: Whether VANI considered any alternative AI orchestration frameworks (LlamaIndex, Haystack, etc.) or only LangChain. The rejection section lists only LangChain.

The 50-year horizon makes framework adoption decisions different from typical software projects. For a 1–2 year project, LangChain's productivity benefits might outweigh the maintenance costs. For a 50-year project, any framework that has already broken its API multiple times in 2 years is a poor long-term bet.

The "leaky abstraction" problem is specifically important for AI provider abstractions because the differences between providers (different context window sizes, different tool calling APIs, different streaming behaviors, different rate limits) are not incidental — they represent fundamental capability differences that a good abstraction must either expose or consciously hide.

When deciding whether to adopt an orchestration framework vs. build a custom abstraction layer:

• If your codebase will last <3 years: use the framework, save development time
• If your codebase will last 10+ years: implement narrow port contracts, accept the development overhead, preserve control over your abstraction boundaries

The custom AIPort protocol is a smaller investment than LangChain adoption, but produces more stable, maintainable code over decades because the abstraction boundary is under your control.

• docs/architecture/TECHNOLOGY_STRATEGY.md — Section 19.3 (LangChain rejection)
• docs/architecture/TECHNOLOGY_STRATEGY.md — Section 4.3 (AIPort protocol)
• docs/architecture/AI_MODELS.md — P3 (Contracts Over APIs)
• docs/architecture/TECHNOLOGY_STRATEGY.md — Section 14 (Replacement Strategy)