Configuration, versioning & memory

What this looks like in practice

It's Friday afternoon. Your CRO wants you to A/B test two variants of the customer- service agent's opening prompt. With a code-defined agent, you ship two builds and a feature flag — every prompt change is a code change, a code review, a deploy. With a prompt-registry like LangChain Hub, you push a new prompt version, route 10% of traffic to it via the dashboard, and roll back from the same dashboard if metrics regress. With Genkit's .prompt files, you swap a file in your repo, the dev server hot-reloads, and a deploy ships the change — no separate registry but clean file-level versioning. The other frameworks land between these poles.

What this means in practice

Three patterns dominate. Code-first (LangChain, LangGraph, CrewAI, SK, Mastra, Rig) is the most common — agents are Python / TypeScript / Rust objects, versioning is whatever VCS you use. Declarative YAML (ADK, MS Agent Framework) treats agent definitions as data files — same VCS-versioned story but with a clearer separation between "what the agent is" and "what surrounds it." Interface-based (LangChain4j) is unique to the JVM — agents are Java interfaces with annotations, and the framework synthesises the implementation at runtime.

On prompt versioning as a separate artifact: LangChain Hub is the most feature-rich — named prompts with version tags and dashboard-driven A/B routing. Genkit Go's .prompt files are file-based but hot-reload aware, which is a nicer dev experience than a registry but lacks the runtime A/B story. Everyone else treats prompts as code: change the prompt, ship a new build.

What this looks like in practice

Your production deployment reads a database password from AWS Secrets Manager, the OpenAI key from a Kubernetes Secret, the model name and timeout from a ConfigMap, and the tenant routing rules from a feature-flag service. With Spring Boot and LangChain4j or ASP.NET Core and MS Agent Framework, the host framework's config binder picks all of these up through its standard providers — secrets, configmaps, envs, and profiles compose into a single typed configuration. With most Python frameworks, your bootstrap code has to wire each source explicitly, often through Pydantic Settings or Hydra. The differences mostly reflect which host ecosystem each framework targets.

The other production concern is secrets: API keys for providers, credentials for vector stores, tokens for downstream tools. None of the ten frameworks ships a secrets-manager integration — they all read from environment variables and expect your platform layer (Vault, Kubernetes Secrets, AWS Secrets Manager, Azure Key Vault) to populate those vars before the process starts.

What this means in practice

Two frameworks inherit a complete config story from their host: LangChain4j (Spring Boot or Quarkus profiles) and MS Agent Framework (.NET appsettings + environments). ADK comes close with its YAML LlmAgentConfig. The other seven leave configuration to you — read env vars, pick the right values for the right environment, and wire it through. Python frameworks especially benefit from adding Pydantic Settings or Hydra; Mastra benefits from its deployer's per-target env handling.

What this looks like in practice

Your security team mandates that all vectors live in your internal vector database, not Pinecone. With a framework whose vector layer is an abstract base class with five-or-so methods (add, search, delete, etc.), you implement the interface against your internal DB, register your class, and the rest of the agent code never knows the swap happened — maybe an afternoon of work. With a framework where the vector layer is hard-coded inside agent internals, you're forking the framework, patching multiple files, and maintaining the diff forever.

Three things matter for swap-ability: (1) which abstractions are pluggable — LLM provider, memory store, vector store, session/checkpoint store, tool registry, tracing exporter, cache backend; (2) how the interface is shaped — a small clean interface is easier than a sprawling abstract class with assumptions baked in; (3) how you register a custom implementation — a global setter, DI registration, builder argument, or trait impl.

What this means in practice

Most frameworks land at "Low effort to swap a default." LangChain has the broadest abstraction surface, with abstract base classes for nearly every component and a large library of reference implementations to copy. LangChain4j is the JVM equivalent — clean interfaces and ~80 vendor modules to learn from. ADK has the most explicitly named service interfaces (Session, Memory, Artifact). Rig's trait-based design is idiomatic Rust and stays out of the way. MS Agent Framework leans on standard .NET DI, which makes registration trivial.

Two frameworks have moderate friction. CrewAI exposes fewer abstractions and routes the model layer through LiteLLM, which means swapping providers is easy (LiteLLM supports many) but swapping away from LiteLLM requires more plumbing. Semantic Kernel's service-registration model is consistent but requires more setup than a simple subclass-and-register. Genkit Go's plugin registry is powerful but expects you to learn its lifecycle first. None of these are show-stoppers; they're just more upfront learning.

What this looks like in practice

Two memory primitives matter most. Short-term: the running list of messages in this conversation, often capped by token count. Long-term: facts the agent should remember across sessions — user preferences, prior decisions, contextual details — typically backed by a vector store so the agent can semantically recall relevant items. A framework that ships both lets you write agent({ memory: Memory({...}) }); a framework without memory primitives leaves you to thread message history in/out per request and integrate a vector store yourself.

What this means in practice

Six frameworks ship first-class memory primitives: LangChain (broadest vector-store catalogue), LangGraph (state-as-memory via checkpointer), CrewAI (scoped memory with LanceDB-backed semantic recall), ADK (session service + memory service abstractions with multiple backends), Mastra (thread-scoped Memory with built-in semantic recall), and LangChain4j (window-based chat memory + ~30 embedding stores). Semantic Kernel and Rig provide chat-history primitives but no memory abstraction — you wire vector stores yourself. MS Agent Framework's memory story is backend-delegated when running on Azure Agent Service; Genkit Go is stateless by design.

What this looks like in practice

A multi-tenant SaaS agent serves 50 customer organisations. Each end-user within a customer has their own conversation history. With a thread-id pattern, your gateway passes thread_id="acme-org/jane-doe-session-42" in the request config; the agent runtime looks up state for that thread, runs the agent, persists state back. Different threads never see each other's data, and you can shard storage by thread prefix if scale demands. With no session primitive, you thread message history in/out manually and risk getting it wrong on a future code change.

What this means in practice

Eight frameworks expose a thread-id-shaped primitive — the names vary but the shape is the same: a string passed at request time that namespaces state and isolates one session from another. LangGraph (thread_id), Mastra (threadId), MS Agent Framework (conversationId), ADK (Session with user_id), CrewAI (memory scope or per-crew instance), LangChain (session_id callback), LangChain4j (chatMemoryProvider callback), and SK (per-kernel chat history). Genkit Go and Rig leave session isolation to your application code — they're stateless by design.