Mamba is a new large language model (LLM) architecture introduced in late 2023 by researchers from Carnegie Mellon and Princeton. It’s built on Structured State Space (S4) models and aims to overcome transformers’ inefficiencies on long sequences by using a selective, input-dependent state space mechanism.
Key Innovations
Selective State Spaces (SSM):
Mamba’s core block dynamically filters information, keeping what’s relevant and discarding the rest as it processes each token.
Simplified block design:
It replaces the transformer’s heavy attention + MLP blocks with a single, cohesive SSM block, reducing complexity.
Hardware-aware parallelism:
Uses a parallel scan algorithm tuned for GPUs, optimizing memory usage and throughput.
Linear-time scaling:
Training and inference scale linearly with sequence length, unlike transformers’ quadratic attention cost.
Architecture Highlights
Mamba introduces a selected SSM layer that:
Focuses on relevant info:
Weights inputs differently so predictive signals dominate.
Adapts to inputs:
Parameters change per token (time-varying), enabling flexible sequence modeling.
It’s designed to fit GPU high-bandwidth memory and exploit parallel compute,
improving speed and memory efficiency.
Mamba vs Transformers
Transformers
Mamba
Attention-based; excellent at capturing global relationships
but suffer from high memory/compute as sequences grow
(quadratic scaling).
SSM-based; uses a fixed-size hidden state that compresses
history, enabling much faster inference and lower memory on long contexts.
Trade-offs noted in broader research (and acknowledged in the article’s context):
transformers can still outperform on some retrieval/copying tasks and may need less data
to learn certain behaviors, despite Mamba’s efficiency gains.
Usage
Requirements:
Linux, NVIDIA GPU, PyTorch 1.12+, CUDA 11.6+.
Install:
pip install causal-conv1d
(optional) and
pip install mamba-ssm
from the official repo; can also build from source.
Usage:
Instantiate a Mamba module with parameters like
d_model,
d_state,
d_conv,
and
expand,
then pass tensors of shape
(batch, length, dim)
.
Applications
Because it handles long sequences efficiently, Mamba is positioned for:
Long-form text analysis and content generation
Speech/audio and time-series modeling
Real-time translation and chatbots that track long conversations
Domain impacts highlighted include healthcare (genomic data),
finance (long-term trends), and customer service (long-context dialogues).
Bottom Line
Mamba reframes sequence modeling by replacing attention with
selective state spaces, delivering linear-time scaling and
major efficiency gains for long contexts—making it a strong alternative
(and potential complement) to transformers in future AI systems.
A semantic layer is an intermediary between raw data sources
(data warehouses, lakes, etc.) and business users/tools. It translates technical
schemas into business-friendly terms, defines shared vocabulary and rules, and
provides a consistent, governed view of data for analytics.
Why Organizations Need It
Eliminates silos and inconsistency:
Unifies data from many systems under one business vocabulary so
“sales,” “revenue,” etc., mean the same thing across teams.
Improves accessibility:
Lets non-technical users explore data via self-service without deep
SQL or schema knowledge.
Speeds insights:
Predefined metrics and relationships let analysts build reports faster
and make decisions more quickly.
Types of Semantic Layers
Universal:
Standalone, enterprise-wide layer acting as a single source of truth;
great for governance and flexibility but costlier.
Data warehouse semantic layer:
Lives inside the warehouse; focuses on naming, data model organization,
and lineage.
Data lake semantic layer:
Organizes schemas and meanings for unstructured/semi-structured data
in lakes.
BI semantic layer:
Sits between warehouses/lakes and tools like Power BI/Tableau; defines
business concepts, relationships, and prebuilt metrics.
How It Works (Key Components)
Data sources:
Raw repositories (warehouses, lakes).
Data integration:
Extracts and transforms data into consistent formats.
Metadata repository:
Stores definitions, models, and relationships.
Semantic model:
Encodes business logic, hierarchies, metrics, and calculations.
Query engine:
Translates user queries into source-specific queries.
Identify business requirements with analysts and domain experts.
Assess existing data sources for format and quality.
Design the semantic model using sound modeling techniques.
Implement using BI/data modeling tools (views, calculated fields, hierarchies).
Integrate with sources via connectors/APIs and ETL/ELT processes.
Test, validate (including UAT), then deploy and maintain with ongoing monitoring.
Challenges to Watch
Complex initial setup and integration.
Scalability as data volume/variety grows.
Maintaining consistency across sources.
Ongoing cost, resources, and change management/user adoption.
Common Implementation Architectures
Architecture
Description
Metadata-first
Logical, metadata-driven unification without physical consolidation;
balances standardization and agility.
Ontology modeling language (OML)
Uses a shared ontology (e.g., UFO) to build a knowledge graph for
federated data.
Built-for-purpose
Decentralized, leveraging semantics inside individual tools
(CRM, BI) per business unit.
Centralized
Consolidates definitions/logic in an EDW/DL; strong governance
but heavy upfront investment.
Tools with Sematic-Layer Capabilities
Cube.js, MetricFlow, dbt, Tableau, and Power BI,
highlighting features like data modeling, metrics layers, caching, APIs,
and visualization/integration strengths.
While the Model Context Protocol (MCP) 2026-07-28
specification removed protocol-level sessions
(Mcp-Session-Id
and the
initialize
handshake) to make the protocol stateless, the
Context object in FastMCP remains a core feature,
though its underlying scope and behavior have changed.
How the Context Object Has Changed
From Session-Scoped to Request-Scoped
Previously, the Context
object was tied directly to a persistent, long-lived client session.
In the new stateless era,
each individual MCP request receives a brand new, isolated
Context
object.
State Isolation
Any state you set dynamically inside a tool via
ctx.set_state()
is strictly scoped to that single, specific request execution.
It does not leak or persist into subsequent tool calls or requests.
Protocol Era Coexistence
The Context
object is backward-compatible. Inside your handlers, you can check
ctx.request_context.protocol_version
to determine if a call arrived via the legacy handshake era
(session-backed) or the modern stateless era.
Ambient Cleanup
The ambient
server.request_context
global
ContextVar
has been entirely removed in favor of strict, clean parameter injection
(ctx: Context)
passed directly into your functions.
Why the Context Object Is Still Needed
The Context
object does not exist just to manage sessions; it acts as your tool's
gateway to operational sub-systems. It is still heavily used for:
Logging & Progress:
Dispatching real-time
ctx.info(),
ctx.error(),
and
ctx.report_progress()
updates back to the client UI.
Client Sampling:
Allowing the server to request completions from the client LLM dynamically
using
ctx.sample().
Lifespan Management:
Providing access to persistent backend resources initialized at startup
(like database drivers or external APIs) via
ctx.request_context.lifespan_context.
Note
As part of the same v2 stateless transition, the high-level framework class
FastMCP
has been renamed to
MCPServer
in the official Python SDK.
Migration Details
Old Import (v1):from mcp.server.fastmcp import FastMCP
New Import (v2):from mcp.server.mcpserver import MCPServer
Context Property:ctx.fastmcp changed to ctx.mcp_server
Using older version of langchain-mcp-adapters produces the following error:
ImportError: cannot import name 'streamablehttp_client' from 'mcp.client.streamable_http' (/usr/local/lib/python3.12/dist-packages/mcp/client/streamable_http.py). Did you mean: 'streamable_http_client'?
This is the error of version mismatch of langchain-mcp-adapters package, not an error of importing wrong package.
You can just updgrade langchain-mcp-adapters and check back:
!pip install --upgrade mcp langchain-mcp-adapters
This error was caused at the statement:
from langchain_mcp_adapters.client import MultiServerMCPClient
A revolutionary change was announced on 28/July/2026 in the MCP specifications. It announced specifications for stateless MCP, making it fit to the era of distributed computing.This redesign addresses one of the biggest barriers to deploying AI agents at production scale—scalability. By making MCP stateless, developers can now deploy AI agents using the same cloud-native infrastructure and scaling techniques that power modern web applications.
Background: Why MCP Matters
The Model Context Protocol (MCP) has emerged as the standard interface that allows AI models and agents to communicate with external tools, APIs, databases, and services.
Instead of building custom integrations between every model and every tool, MCP provides a common protocol that standardizes discovery and invocation.
However, the original MCP protocol maintained server-side session state. Once a client initialized a session with an MCP server, subsequent requests had to reach the same server instance because that instance stored the conversation and capability state.
While this worked well for local development and small deployments, it introduced serious challenges in production environments.
Problems with Stateful MCP
The article explains several operational limitations caused by maintaining sessions on the server.
1. Sticky Sessions
Because each server instance stored client state, load balancers had to route every request from a client back to the same server.
This prevented true horizontal scaling and made infrastructure more complex.
2. Difficult Autoscaling
Cloud-native platforms such as Kubernetes, Cloud Run, and serverless functions continuously add and remove instances based on demand.
With stateful MCP:
Removing an instance could disconnect active sessions.
Scaling required session replication or external session stores.
Infrastructure became significantly more complicated.
3. Reduced Reliability
If the server maintaining a client's session crashed, the session was lost.
Even rolling deployments could interrupt connected clients because session ownership was tied to a particular server.
These issues made production deployments unnecessarily difficult despite MCP itself being conceptually simple.
The Shift to Stateless MCP
The central idea of the update is simple:
Every request contains all of the information required to process it, in a new field called "_meta". It will include "capabilities" and "clientInfo" fields, which were earlier exchanged only in the beginning, in the "initialize" request. The "intialize" request itself is deprecated now.
Instead of relying on previously established server-side state, each request becomes self-contained.
This aligns MCP with how REST APIs and modern HTTP services already operate.
Now any server instance can process any incoming request.
The server no longer needs to remember earlier interactions.
Infrastructure Benefits
The article highlights several operational improvements.
Horizontal Scaling
Since every request is independent:
requests can go to any replica,
standard load balancers work correctly,
no sticky routing is necessary.
This greatly simplifies Kubernetes and cloud deployments.
Serverless Compatibility
Stateless services are ideal for:
Cloud Run
AWS Lambda
Azure Functions
edge computing platforms
Instances can start, handle a request, and shut down without preserving client state.
Improved Reliability
If one server fails:
another instance immediately handles subsequent requests,
clients experience fewer disruptions,
deployments become safer.
This improves availability while simplifying operations.
Self-Describing Requests
One of the major protocol changes is that requests now include metadata describing:
supported protocol version,
capabilities,
context needed for execution.
Previously, servers had to remember these details from an initialization handshake.
Now they travel with every request.
As a result:
requests become portable,
servers remain stateless,
infrastructure becomes easier to manage.
HTTP-Friendly Design
The new protocol is intentionally designed around standard HTTP infrastructure.
Several protocol elements now map directly to HTTP concepts.
For example:
methods appear in HTTP headers,
tool names can be exposed through headers,
gateways can inspect requests without parsing JSON payloads.
This enables existing API gateways and reverse proxies to perform:
routing,
authentication,
authorization,
logging,
monitoring.
Organizations can therefore reuse their existing networking infrastructure rather than deploying MCP-specific components.
Important Note
Because MCP now aligns closely with standard HTTP semantics, existing cloud infrastructure—including API gateways, reverse proxies, service meshes, and load balancers—can operate without requiring protocol-specific customization.
Caching Improvements
The article also introduces cacheable discovery responses.
Operations like:
listing tools,
discovering capabilities,
retrieving metadata
typically change infrequently.
The updated protocol allows servers to specify cache lifetimes.
Clients can therefore reuse cached information instead of repeatedly requesting identical data.
Benefits include:
reduced latency,
lower bandwidth,
fewer server requests,
improved scalability.
Large deployments especially benefit because discovery operations often represent a significant portion of traffic.
Multi-Round Interactions
A concern with stateless systems is supporting workflows that naturally span multiple interactions.
Rather than relying on persistent bidirectional sessions, MCP introduces mechanisms for Multi Round-Trip Requests (MRTR).
This allows:
clarification requests,
user input,
long-running operations,
asynchronous workflows
without requiring permanently open connections.
The protocol separates application workflow from transport-layer state.
Applications may still maintain business state (such as task IDs or workflow progress), but the transport itself remains stateless.
Security Improvements
The protocol update also strengthens authorization.
The article references improvements that align MCP more closely with OAuth and OpenID Connect best practices.
Security enhancements include:
stronger issuer validation,
improved authorization handling,
enterprise-friendly authentication mechanisms.
These changes make MCP easier to integrate into existing enterprise identity systems while reducing security risks associated with session management.
Important Note
The security model focuses on standards-based authentication and authorization, allowing organizations to integrate MCP with existing enterprise identity providers and security infrastructure.
Developer Impact
For developers building MCP servers, the migration requires some architectural adjustments.
Previously, developers often stored:
session objects,
client capabilities,
negotiated protocol versions,
temporary context
inside server memory.
With stateless MCP:
servers should treat each request independently,
persistent application state should live in databases or external storage when necessary,
infrastructure no longer manages conversational state.
Although this may require code changes, it dramatically simplifies deployment.
Tip
Stateless application servers should only process requests. Long-lived application state should be stored in external databases, distributed caches, or workflow engines rather than server memory.
Cloud-Native Alignment
A recurring message throughout the article is that AI infrastructure should leverage decades of cloud engineering rather than inventing new operational models.
Stateless MCP allows AI agent infrastructure to inherit proven practices such as:
autoscaling,
rolling deployments,
health checks,
CDN caching,
standard load balancing,
serverless execution,
edge deployment.
This makes MCP servers behave like conventional HTTP services rather than specialized stateful applications.
Why This Matters
The article argues that the stateless redesign is less about changing how developers invoke tools and more about changing how AI systems can scale in production.
As organizations deploy thousands or millions of AI-agent requests, infrastructure complexity—not model quality—often becomes the bottleneck.
Removing protocol-level session state enables:
simpler deployments,
better resilience,
lower operational costs,
easier scaling,
improved compatibility with modern cloud platforms.
In essence, MCP evolves from a protocol optimized for developer convenience into one optimized for enterprise-scale AI infrastructure.
Important Note
The primary motivation behind the stateless redesign is not to change the programming model, but to eliminate infrastructure bottlenecks that arise when AI systems are deployed at production scale.
Conclusion
The stateless MCP update represents a foundational architectural shift. Instead of tying clients to individual server instances, every request is now self-contained, allowing AI agent infrastructure to operate like any modern distributed web service. This eliminates sticky sessions, enables seamless autoscaling, improves reliability, and integrates naturally with existing HTTP infrastructure, gateways, caches, and serverless platforms. Combined with enhancements such as cacheable discovery, multi-round request handling, and stronger authorization, these updates position MCP as a protocol capable of supporting large-scale, production-grade AI agent ecosystems rather than just local development or small deployments.
Summary
Area
Stateless MCP Improvement
Architecture
Every request is self-contained.
Scaling
Supports true horizontal scaling without sticky sessions.
Reliability
Server failures no longer terminate protocol sessions.
Cloud Support
Compatible with Kubernetes, serverless platforms, and edge deployments.
Performance
Cacheable discovery reduces latency and server load.
Security
Improved authorization aligned with OAuth and OpenID Connect.
Developer Experience
Application state moves to external storage while infrastructure remains stateless.