AI Frameworks Without Lock-In

Key jargon

Term	Plain-language meaning
Framework	Reusable abstractions and components for building an application.
Vendor lock-in	The cost or difficulty of changing a provider or technology.
Port	An application-owned interface describing what a component must do.
Adapter	Provider-specific code implementing a port.

Key concepts

Keep domain logic and evaluation datasets outside framework-specific objects.
Framework replacement becomes manageable when provider code is confined to adapters and behavior is protected by contract tests.

Concept map

flowchart LR
    A["Define application-owned ports"] --> B["Implement framework adapters"]
    B --> C["Run shared contract tests"]
    C --> D["Replace without changing domain logic"]

Frameworks can provide model adapters, prompt templates, retrieval, tool wiring, graphs, checkpoints, tracing, and integrations. They also add abstraction, rapid version churn, hidden defaults, and provider-specific leakage.

Stable seams

Application task schema.
Model adapter interface.
Tool schemas and authorization gateway.
Retrieval interface and document identifiers.
Run-state/checkpoint schema.
Trace and evaluation record.

Keep these under your control. Wrap framework objects at boundaries and test the wrapper.

Selection questions

Can the team debug a raw request? Export state? Pin versions? Replace the model or vector store? Test each node? Understand retries? Enforce authorization outside the model?

Exercise

Implement one conceptual two-step workflow in plain pseudocode and then map it to a framework. Identify which framework features save work and which create coupling.

Staleness warning

Framework APIs change quickly. Use current official documentation and locked dependencies; do not teach old sample code as architecture truth.