Friday, 4 September 2026

Beyond the Chatbot: Why Voice AI Could Be the Next Major Interface

Standard

For three years, the face of artificial intelligence (AI) was a text box. Type a prompt, read a reply, copy the output somewhere useful. That pattern scaled fast because it was easy to ship. It also trained us to treat AI like a search engine with better grammar.

Voice is breaking that habit. Not voice as a gimmick bolted onto chat, but voice as the primary way people talk to machines: hands-free, eyes-free, interruptible, and fast enough to feel live. Consumer behavior moved first. Enterprise software is catching up slowly. That gap is why voice AI looks less like a feature request and more like the next interface shift (Voices, 2026; Forbes Technology Council, 2026).

The One-Minute Version

Chatbots excel when the task is reading, editing, and precision. Voice excels when the task is speed, mobility, and continuous dialogue. The technology finally supports the second case:

  • Speech-to-speech models cut the old Speech-to-Text (STT) → Large Language Model (LLM) → Text-to-Speech (TTS) chain that added latency and killed natural interruptions (OpenAI, 2026).
  • Full-duplex audio lets the system listen and speak at once, like a phone call instead of a walkie-talkie (OpenAI, 2026; Hacker Noon, 2026).
  • Async tool use lets a voice layer keep talking while deeper reasoning, search, or enterprise actions run in the background (OpenAI, 2026; tblocks, 2026).

Result: AI stops feeling like a form you fill out and starts feeling like a collaborator you talk through a problem with.

Why Chat Hit a Ceiling

Text chat won the first wave for good reasons. It is cheap to host, easy to log, works in open offices, and maps cleanly to Application Programming Interface (API) design. But it carries friction humans tolerate in software and reject in conversation:

  • Typing is slow. Average speaking rate beats typing by a wide margin in most real tasks.
  • Context is fragmented. Each message is a discrete turn. Long threads become hard to navigate on mobile.
  • Hands and eyes are busy. Drivers, clinicians, warehouse staff, and field technicians cannot live inside a chat bubble.
  • Emotional bandwidth is thin. Text flattens tone. Support, coaching, and sales often need pacing, pauses, and backchannel cues ("mhmm," "got it") that text mimics poorly.

Chat is not going away. It remains the best interface for code, documents, and audit trails. The shift is that chat stops being the default front door to AI (Medium, 2026).

From Chat Bubble to Voice Operating Layer 2020-2022 FAQ bots text only 2023-2024 LLM chat type and read 2025 STT + LLM + TTS turn-based voice 2026+ Full-duplex voice listen + act + tools Old pipeline (fragile) Speech-to-Text to LLM to Text-to-Speech High latency, awkward interruptions Feels like a phone tree with AI Chat bubble on the side New stack (conversational) Speech-to-speech + async tools Sub-800 ms turns, barge-in support Voice is the primary interface Hands-free, eyes-free, mobile-native

What Makes Voice Different Now

Latency crossed the trust threshold

Humans expect roughly 200 milliseconds (ms) in face-to-face reply timing. Above 800 ms, voice AI starts feeling laggy. Above 1.2 seconds, users talk over the agent (ForaSoft, 2026). Old chained pipelines often blew that budget before the first word played.

New Realtime and GPT-Live-class systems stream audio in both directions and target sub-800 ms voice-to-voice turns in production with explicit latency budgets across capture, uplink, inference, downlink, and playback (OpenAI, 2026; Mengboy Tech Notes, 2026).

Full-duplex changed the conversation model

Turn-based voice waited for you to stop speaking, then responded. Full-duplex models can listen while speaking, handle overlap, stay quiet when appropriate, and use backchannel phrases that signal attention (OpenAI, 2026). That is a social interface detail, but social details are what make voice feel human instead of robotic.

Voice became an execution layer, not a readout

The next generation is not "speak your question, hear the answer." It is "talk through the task while the system acts." Conversational AI in enterprise settings now opens cases, pulls customer relationship management (CRM) context, drafts responses, requests approval, triggers refunds, and logs outcomes across systems (tblocks, 2026). Voice is the fastest path into that workflow when the user cannot sit at a keyboard.

The Adoption Gap Nobody Is Talking About Enough

Voices' Amplified 2026 report surveyed 700 business leaders and consumers. The numbers are stark (Voices, 2026; Unite.AI, 2026):

  • 55% of consumers use voice as their primary interface for AI interactions.
  • 29% of companies have deployed customer-facing voice AI.
  • 32% more are stuck in pilot or testing.

Consumers moved voice-first. Brands are still treating it as a science project. That is the same pattern we saw with mobile web before responsive design became mandatory. The interface shift happens in user behavior first. Software catches up later, and laggards pay for it in churn.

Use Cases: Problem, Cause, Effect

1. Customer support on the phone

Problem: Callers waited through rigid interactive voice response (IVR) trees, then repeated their story to a human agent. Satisfaction scores flatlined even after a chatbot was added to the website.

Cause: Text chat and phone were separate channels. The chatbot could not hear tone, could not handle barge-in, and could not access telephony session state. Agents still re-keyed data the customer already gave the bot (tblocks, 2026).

Effect with voice AI: A Realtime voice agent answers with sub-second responsiveness, verifies identity through tools on a server-side "sideband" connection, and updates the CRM while the caller speaks. The call feels conversational; the backend stays governed and auditable (OpenAI, n.d.-b).

2. Field service and logistics

Problem: Technicians in vans skipped the internal support portal because typing while carrying equipment was unsafe. Issues escalated by radio instead of being logged.

Cause: The official AI interface was text-first. Mobile chat worked in demos, not on a loading dock with gloves and glare (Forbes Technology Council, 2026).

Effect with voice AI: Hands-free status updates, parts lookup, and ticket creation by voice. The interface matches the environment. Adoption rises because the worker never has to context-switch into a chat window.

3. Coaching, training, and language learning

Problem: Learners read AI feedback but did not practice out loud. Skill transfer stayed low compared to human tutoring.

Cause: Chat interfaces optimize for written answers. They underweight pacing, pronunciation, hesitation, and emotional encouragement, the parts of teaching that happen in speech (Forbes Technology Council, 2026).

Effect with voice AI: Continuous spoken dialogue builds continuous context. The system hears patterns across sessions, not just isolated prompts. For coaching and education products, conversation becomes the product, not a wrapper around a text model.

4. Executive "swivel-chair" workflows

Problem: Leaders asked an AI assistant to summarize a quarter, then manually opened email, calendar, and enterprise resource planning (ERP) tools to act on it. The assistant saved reading time but not execution time.

Cause: Chat lived in a sidebar. It was not wired as the front door to systems of record. Each action still meant switching apps (tblocks, 2026).

Effect with voice AI: Spoken commands trigger bounded agent workflows: pull metrics, draft a note, schedule a follow-up, wait for approval, log the outcome. Voice is the thinnest interface layer over agentic execution, especially on desktop and in cars where typing is inconvenient.

Chat vs Voice: When Each Wins

Dimension Text chat Voice AI
Speed of input Slow on mobile; fine at desk Fast, hands-free
Precision tasks Code, legal text, copy editing Weaker for exact strings
Audit and search Excellent transcript trail Needs recording and logging policy
Environment Open offices, public spaces Private, mobile, field work
Emotional fidelity Flat Tone, pacing, backchannel cues
Latency sensitivity Forgiving Unforgiving below ~800 ms
Best 2026 stack Chat completions + tools Speech-to-speech Realtime + sideband tools

What Production Voice AI Actually Requires

Demos hide the hard parts. Shipping voice in production means engineering, not model selection alone (ForaSoft, 2026; Mengboy Tech Notes, 2026):

  1. Interruption state machines. When the user barges in, cancel the in-flight response cleanly. Treat it as protocol logic, not a user interface hack.
  2. Session rotation. Long calls accumulate context and latency. Reseed summaries into fresh sessions on extended conversations.
  3. Sideband control. Keep tools, business rules, and secrets on your server while audio runs over Web Real-Time Communication (WebRTC) to the client (OpenAI, n.d.-b).
  4. Latency budgets per stage. Measure capture, uplink, inference, downlink, and playback. Optimizing only model time misses half the story.
  5. Compliance and brand voice. Health Insurance Portability and Accountability Act (HIPAA), call recording laws, and voice rights matter at enterprise scale (Voices, 2026).

Skip these and your voice agent sounds fine in a demo, then like an angry walkie-talkie in week two.

When Text Still Wins

Voice is not a replacement for every interface. Stay text-first when:

  • Users need exact copy, code, or legal language they can paste.
  • Privacy rules forbid spoken data in shared spaces.
  • Workflows require rich formatting, tables, or side-by-side comparison.
  • Your audience includes users who depend on screen readers and structured text (multimodal design should offer both).

The winning products in 2026 offer choice and continuity: start a task by voice, refine it in chat, execute it through agents, without losing context (Medium, 2026).

Bottom Line

The chatbot era taught the world that AI could answer questions. The voice era teaches that AI can participate in work as it happens: while you drive, while you walk a floor, while you talk a customer down, while you rehearse a pitch out loud.

That is why voice AI is not "chat with a microphone." It is a different interface contract: continuous, interruptible, embodied in time instead of frozen in a thread. The models finally caught up. Consumer behavior already did. The open question is which teams treat voice as a skin on their chatbot and which treat it as the next operating layer for how humans and software collaborate.

If you are building in 2026, assume multimodal from day one. Ship text because it is easy to debug. Invest in voice where your users already live without a keyboard. Measure latency like you measure uptime. The chat bubble is not dead. It is just no longer the whole story.

References

  • Forbes Technology Council. (2026, August 27). The voice revolution: Why voice AI will become the default interface for artificial intelligence. Forbes. https://www.forbes.com/councils/forbestechcouncil/2026/08/27/the-voice-revolution-why-voice-ai-will-become-the-default-interface-for-artificial-intelligence/
  • ForaSoft. (2026). OpenAI Realtime API: Production voice agents. https://www.forasoft.com/blog/article/openai-realtime-api-voice-agent-production-guide-2026
  • Hacker Noon. (2026). How modern voice-to-voice AI models work. https://hackernoon.com/how-modern-voice-to-voice-ai-models-work
  • Mengboy Tech Notes. (2026, March 9). OpenAI Realtime + Go in production: WebRTC token rotation, interruption recovery, and end-to-end latency budgets. https://www.mfun.ink/en/2026/03/09/openai-realtime-go-webrtc-auth-recovery-latency-budget/
  • Medium. (2026). Beyond the chat bubble: The rise of conversational interfaces in 2026. https://medium.com/@nithin_94885/beyond-the-chat-bubble-the-rise-of-conversational-interfaces-in-2026-a271ad034c92
  • OpenAI. (2026). Continuous voice interaction with GPT-Live. https://openai.com/index/continuous-voice-interaction-with-gpt-live/
  • OpenAI. (2026). Introducing GPT-Live. https://openai.com/index/introducing-gpt-live/
  • OpenAI. (n.d.-b). Webhooks and server-side controls. OpenAI API. https://developers.openai.com/api/docs/guides/realtime-server-controls
  • tblocks. (2026). Conversational AI trends in 2026: From chatbots to execution. https://tblocks.com/articles/conversational-ai-trends/
  • Unite.AI. (2026). Consumer voice AI is here — enterprise readiness isn't. https://www.unite.ai/consumer-voice-ai-is-here-enterprise-readiness-isnt/
  • Voices. (2026). Amplified 2026: The annual state of voice report. https://www.voices.com/landing/amplified-report
  • Voices. (2026, January 28). The new interface era: Voice AI becomes dominant while most enterprises lag behind [Press release]. https://www.voices.com/company/press/press-releases/amplified-state-of-voice-2026

Sunday, 30 August 2026

Stateless MCP: What Changed, Why It Matters, and How to Build for Scale

Standard

 


If you deployed a remote MCP server in 2025, you probably hit the same wall I did: it worked fine on localhost, then fell apart behind a load balancer. Request two landed on a different pod and came back with a session error. The fix was always some combination of sticky sessions, Redis, or a custom gateway. That was not a bug in your code. It was the protocol.

The 2026-07-28 Model Context Protocol (MCP) specification changes that. MCP is now stateless at the transport layer. Each Hypertext Transfer Protocol (HTTP) request carries everything the server needs. Any replica can answer it. For teams treating MCP as production infrastructure, not a local dev trick, this is the biggest shift since remote MCP launched.

Key abbreviations in this post

  • API — Application Programming Interface
  • AWS — Amazon Web Services
  • HTTP — Hypertext Transfer Protocol
  • JSON — JavaScript Object Notation
  • JSON-RPC — JSON Remote Procedure Call
  • K8s — Kubernetes
  • LLM — Large Language Model
  • MCP — Model Context Protocol
  • MRTR — Multi Round-Trip Requests
  • OAuth — Open Authorization
  • OpenTelemetry — open standard for traces, metrics, and logs
  • PEP — Python Enhancement Proposal
  • REST — Representational State Transfer
  • RFC — Request for Comments
  • RPC — Remote Procedure Call
  • SaaS — Software as a Service
  • SDK — Software Development Kit
  • SEP — Specification Enhancement Proposal
  • SSE — Server-Sent Events
  • SKU — Stock Keeping Unit
  • stdio — standard input/output

MCP in 60 Seconds

The Model Context Protocol (MCP) is an open standard for connecting AI applications to external tools, data, and prompts. Think of it as a structured Application Programming Interface (API) layer built for Large Language Model (LLM) hosts rather than generic Representational State Transfer (REST) clients.

The architecture has three roles (Model Context Protocol, n.d.):

  • Host — the AI app you actually use (Cursor, Claude Desktop, an internal agent platform).
  • Client — one client per server connection, living inside the host. It speaks JSON Remote Procedure Call (JSON-RPC) 2.0 on behalf of the host.
  • Server — your integration. It exposes tools (callable functions), resources (readable data), and prompts (templates).

Local servers usually run over stdio (standard input/output): the host spawns a subprocess and talks over stdin/stdout. Remote servers use Streamable HTTP (Hypertext Transfer Protocol) on a real port. That is the deployment path that needed statelessness.

That is the whole stack in brief. The rest of this post is about what changed when MCP stopped pretending every HTTP (Hypertext Transfer Protocol) deployment was a single long-lived conversation.

What "Stateless MCP" Actually Means

Before spec version 2026-07-28, a remote MCP client had to:

  1. Send an initialize request with protocol version and capabilities.
  2. Receive an Mcp-Session-Id header from the server.
  3. Include that session ID on every later call, often over a held-open Server-Sent Events (SSE) stream.

The server kept session state in memory (or Redis). The client was pinned to whichever instance created that session. Scale-out required sticky routing and shared session stores (Model Context Protocol, 2026; Van Gent & Blount, 2026).

Stateless MCP removes that contract entirely. Each change below is tracked as a numbered Specification Enhancement Proposal (SEP), MCP's formal design document for spec changes (similar to a Python Enhancement Proposal (PEP) in Python or a Request for Comments (RFC) on the web):

  • SEP-2575 (Specification Enhancement Proposal) retires the initialize / initialized handshake.
  • SEP-2567 (Specification Enhancement Proposal) removes the Mcp-Session-Id header.
  • Every request includes client identity and capabilities in a _meta object.
  • Optional server/discover Remote Procedure Call (RPC) replaces "connect first, then ask what you can do."
  • SEP-2243 (Specification Enhancement Proposal) puts Mcp-Method and Mcp-Name in HTTP (Hypertext Transfer Protocol) headers so gateways can route without parsing JSON (JavaScript Object Notation) bodies.
Stateless MCP Request Flow (2026-07-28) MCP Client Inside AI host Load Balancer Round-robin Pod A Pod B Pod C Any pod handles any request Self-contained POST /mcp HTTP headers: MCP-Protocol-Version: 2026-07-28 Mcp-Method: tools/call Mcp-Name: search_inventory JSON body includes: method, params, arguments, _meta (clientInfo, capabilities) No initialize handshake. No Mcp-Session-Id.

Working process step by step

  1. The host decides to call a tool (for example, search_inventory with a Stock Keeping Unit (SKU)).
  2. The MCP client builds a JSON Remote Procedure Call (JSON-RPC) tools/call payload and attaches _meta with protocol version, client name, and capabilities.
  3. The client POSTs to /mcp with headers MCP-Protocol-Version, Mcp-Method, and Mcp-Name.
  4. A load balancer forwards the request to any healthy server instance.
  5. The server validates headers against the body, runs the tool handler, and returns a JSON response. No session lookup.
  6. If the tool needs user input mid-flight, the server returns a Multi Round-Trip Requests (MRTR) inputRequired result with a requestState blob. The client retries on any instance with answers attached (Model Context Protocol, 2026).

One nuance worth stating clearly: stateless protocol does not forbid application state. If your workflow spans multiple tool calls, mint an explicit handle (a task ID, a draft ID) from the first tool and pass it back as an argument. That is visible to the model and survives load balancing. Hidden session state in the transport was the part that had to go.

Why We Needed This

MCP exploded as the default way to wire agents to Software as a Service (SaaS) APIs, databases, and internal services. Downloads across Tier 1 Software Development Kits (SDKs) crossed into the hundreds of millions per month (Model Context Protocol, 2026). Most of that growth pointed at remote HTTP (Hypertext Transfer Protocol) servers, not local stdio (standard input/output) subprocesses.

The old session model created real production pain (Van Gent & Blount, 2026; New Relic, 2026):

  • Broken round-robin. Standard load balancers sent the second request to a pod that never saw the session.
  • Sticky session tax. Affinity rules skew traffic and fight autoscaling.
  • Fragile deploys. Rolling updates dropped in-memory sessions and surfaced transient 400 errors to active chats.
  • Extra infrastructure. Teams bolted on Redis or gateway packet inspection just to keep MCP alive at scale.
  • Gateway blind spots. Rate limits and audit rules could not key off method or tool name without parsing JSON (JavaScript Object Notation) bodies.

Stateless MCP makes remote servers behave like normal HTTP (Hypertext Transfer Protocol) microservices. That sounds obvious. For a protocol born on stdio (standard input/output), it is a necessary maturation step.

Stateful vs Stateless MCP

Aspect Stateful MCP (pre-2026-07-28) Stateless MCP (2026-07-28)
Connection setup initialize handshake required No handshake; optional server/discover
Session tracking Mcp-Session-Id on every request No protocol-level session ID
Client context Sent once at connect time Sent in _meta on every request
Load balancing Sticky sessions or shared session store Plain round-robin across replicas
Serverless / scale-to-zero Poor fit; sessions die on cold start Natural fit (Cloud Run, Lambda, Workers)
Gateway routing Often requires JSON (JavaScript Object Notation) body inspection Mcp-Method and Mcp-Name headers
Mid-call user prompts Open bidirectional Server-Sent Events (SSE) stream Multi Round-Trip Requests (MRTR) with requestState retry
Long-running work Block connection or custom hacks Tasks extension with poll-based status
Payload size trade-off Smaller per-call payloads after handshake Slightly larger requests (metadata repeated)
Best transport locally stdio (standard input/output) still fine either way stdio (standard input/output) unchanged; HTTP (Hypertext Transfer Protocol) gains the most

Real Use Cases

Stateless MCP is not academic. It unlocks patterns teams were already hacking together:

  • Enterprise tool gateways. One MCP endpoint fronting dozens of internal APIs (Application Programming Interfaces), rate-limited per tool name at the edge (Microsoft Foundry, Amazon Web Services (AWS) Bedrock AgentCore, and others ship variations of this).
  • Multi-tenant SaaS (Software as a Service) MCP. GitHub and similar providers removed Redis session stores after upgrading, cutting latency on every call (Van Gent & Blount, 2026).
  • Global deployment. Any region, any replica, same request shape. No cross-region session replication.
  • Agent fleets at scale. Thousands of concurrent agent sessions hitting the same tool server without affinity tuning.
  • Serverless MCP. Spin down to zero between bursts; the next request is self-contained.
  • Compliance-friendly auditing. Log Mcp-Name and auth subject per request without holding connection state.

Deployment Architecture

A production layout looks familiar if you have shipped REST (Representational State Transfer) APIs before. The protocol no longer fights you.

Stateless MCP Deployment Architecture AI Hosts Cursor, Claude, agents API Gateway Auth, rate limit, route Reads Mcp-Method / Mcp-Name Horizontally scaled MCP servers Replica 1 Replica 2 Replica N Kubernetes (K8s), Cloud Run, Lambda, App Service Backend services (state lives here if needed) Database Task store External APIs Protocol layer: stateless. Application layer: state in database (DB) or explicit handles.

Benefits in this layout:

  • Horizontal pod autoscaling on Central Processing Unit (CPU) or request rate, not session count.
  • Zero-downtime deploys without draining sessions.
  • Open Authorization (OAuth) at the gateway with Request for Comments (RFC) 9207 issuer validation (SEP-2468 (Specification Enhancement Proposal)).
  • OpenTelemetry traces correlated per request, not per opaque session.
  • ttlMs (time-to-live in milliseconds) and cacheScope on list responses (SEP-2549 (Specification Enhancement Proposal)) so clients cache tool catalogs safely.

Example: Stateless MCP Server in Python

The v2 Python Software Development Kit (SDK) targets spec 2026-07-28. The high-level Application Programming Interface (API) is MCPServer. Transport options belong on run(), not the constructor (Model Context Protocol, n.d.-b).

# server.py — stateless inventory MCP server
from mcp.server import MCPServer

mcp = MCPServer(
    "InventoryTools",
    instructions="Look up product stock by SKU.",
)

@mcp.tool()
def search_inventory(sku: str) -> str:
    """Return stock level for a warehouse SKU."""
    # Replace with a real DB/API call in production.
    catalog = {"SKU-1001": 42, "SKU-2002": 0}
    qty = catalog.get(sku.upper())
    if qty is None:
        return f"No product found for {sku!r}."
    return f"{sku.upper()}: {qty} units in stock."

if __name__ == "__main__":
    mcp.run(
        transport="streamable-http",
        host="0.0.0.0",
        port=8000,
        stateless_http=True,
        json_response=True,
    )

Install and run:

pip install "mcp[cli]>=2.0.0"
python server.py
# or: uv run mcp dev server.py

What each piece does:

  • @mcp.tool() registers a callable the host can invoke. Docstrings become tool descriptions for the model.
  • transport="streamable-http" exposes the server on a port at /mcp for remote clients over Hypertext Transfer Protocol (HTTP).
  • stateless_http=True creates a fresh transport per request with no session tracking. This aligns the SDK (Software Development Kit) with the stateless protocol core.
  • json_response=True returns one JSON body per POST instead of a Server-Sent Events (SSE) stream. Good default for simple tool servers behind load balancers.

A client call (from the same Software Development Kit (SDK)) looks like this:

import asyncio
from mcp import Client

async def main() -> None:
    async with Client("http://localhost:8000/mcp") as client:
        result = await client.call_tool(
            "search_inventory",
            {"sku": "SKU-1001"},
        )
        print(result.structured_content)

asyncio.run(main())

Each call_tool is an independent HTTP (Hypertext Transfer Protocol) round trip. Hit the server from three terminals at once and any replica can serve any call. That is the behavior you want in staging before you trust it in production.

Migration Checklist

If you are upgrading from MCP v1 SDKs (Software Development Kits) or pre-2026 HTTP (Hypertext Transfer Protocol) servers:

  1. Bump to Software Development Kit (SDK) v2 (Python mcp>=2.0, TypeScript @modelcontextprotocol/server@beta or later).
  2. Replace FastMCP imports with MCPServer.
  3. Move stateless_http and port settings from the constructor to run().
  4. Delete sticky-session config and shared Redis session stores used only for MCP transport.
  5. Replace session-keyed application state with explicit IDs returned from tools.
  6. Rewrite elicitation flows around Multi Round-Trip Requests (MRTR) instead of open back-channels.
  7. Add ttlMs (time-to-live in milliseconds) / cacheScope to list handlers where catalog caching helps.

Important Links and Repositories

Bottom Line

MCP started as a clean way to plug tools into a local AI assistant. Stateless HTTP (Hypertext Transfer Protocol) turns it into something you can run the way you run the rest of your stack: behind a load balancer, across regions, on serverless, with ordinary observability.

The trade is slightly larger requests and a migration sprint if you built on sessions. The payoff is boring scaling, which is exactly what you want once agents stop being a demo and start being a product surface.

If you are starting fresh, build on 2026-07-28 and skip the session workarounds entirely. If you are maintaining an existing remote server, treat this like any other protocol upgrade: staged rollout, benchmark your payload sizes, delete the Redis session layer when receipts prove you do not need it.

Bibliography

  • Model Context Protocol. (2026, July 28). The 2026-07-28 specification. Model Context Protocol Blog. https://blog.modelcontextprotocol.io/posts/2026-07-28/
  • Model Context Protocol. (n.d.). Architecture. https://modelcontextprotocol.org/docs/learn/architecture
  • Model Context Protocol. (n.d.-b). Running your server. MCP Python SDK. https://py.sdk.modelcontextprotocol.io/v2/run/
  • New Relic. (2026). MCP is going stateless: What the new spec means for AI agents. https://newrelic.com/blog/ai/mcp-is-going-stateless
  • Van Gent, K., & Blount, A. (2026, August 5). Scaling AI agent infrastructure with the MCP stateless updates. Google Developers Blog. https://developers.googleblog.com/scaling-ai-agent-infrastructure-with-the-mcp-stateless-updates/

Sunday, 23 August 2026

Rise of Biological Computers: A Plain-English Guide to Their Research

Standard


 

I stumbled on Cortical Labs research page after seeing a headline about brain cells playing Doom. My first reaction was the same as everyone else: okay, that sounds like a meme. Then I read the papers. It is weird. It is also serious science.

Melbourne-based Cortical Labs is trying to build computers from living neurons grown on silicon chips. Not a metaphor. Real cells. Real electrical pulses. Real learning, in a dish, while a digital game runs on the other side of the interface.

Their homepage calls this "Artificial Actual Intelligence." Cheesy label. Interesting point: silicon AI tries to imitate what biology already does. Cortical Labs starts with the biology.

The One-Minute Version

Here is the whole idea in one pass:

  1. Grow neurons on a multielectrode array (MEA).
  2. Convert game or task state into electrical stimulation patterns.
  3. Read neural spikes back out.
  4. Decode spikes into actions (move, shoot, paddle up, and so on).
  5. Send feedback so the network can adapt over time.

That closed loop is the heart of the work. Without it, you are just poking cells. With it, the culture is embodied in a task. That language comes straight from their landmark 2022 Neuron paper on DishBrain (Kagan et al., 2022).

From Pong to Doom: Why Games Keep Showing Up

In 2021 the team showed neurons learning Pong in a simulated environment. The 2022 paper formalized the setup and reported learning signatures within about five minutes of closed-loop play, which is wild when you remember these are cells in a petri dish, not a trained RL agent burning GPU hours (Kagan et al., 2022).

Internet being internet, people asked the only reasonable follow-up question: can it run Doom?

In 2026 Cortical Labs demonstrated Doom running through the CL1 platform, built with collaborator Sean Cole using their API and Cortical Cloud. Reports describe on the order of 200,000 living human neurons on the chip for that demo, with stimulation patterns encoding game state and spike patterns driving movement and firing. Is it esports-ready? No. Is it a useful stress test for adaptive biological control? Yes.

The game is not the product. The game is a benchmark you can score.

Cortical Labs Research Timeline 2021 DishBrain Pong demo 2022 Neuron paper Synthetic biological intelligence 2023 Organoid intelligence OI field outlined 2024 CL1 ships Code-deployable bio computer 2026 Doom on CL1 Cortical Cloud API From lab experiment to commercial platform to open API and harder game-world tests

What the CL1 Actually Is

The CL1 is what Cortical Labs calls the world's first code-deployable biological computer. Shipments were announced for researchers who want programmable access to living neural networks without building an entire wet lab stack from scratch.

Important pieces:

  • Hardware: neurons cultured on a custom high-density MEA inside a life-support system (Cortical Labs cites up to ~6 months viability).
  • biOS: their Biological Intelligence Operating System, which creates the simulated world the neurons interact with.
  • Closed-loop I/O: bi-directional stimulation and recording in real time.
  • Programmability: Python-accessible APIs so developers can treat the culture like a compute substrate, not a one-off experiment.
  • Cortical Cloud: remote access and scaling without every lab owning full infrastructure.
Cortical Labs CL1 biological computer device
CL1 hardware image from Cortical Labs.
Closed-Loop: How CL1 Talks to Living Neurons Game / task Pong, Doom, assay Encoder state to stimulation Neurons on MEA human or rodent cells spike patterns out Decoder spikes to action Feedback (Free Energy / active inference idea) Predictable signal when behavior helps the task Chaotic stimulation when the culture misses Why closed-loop matters Open-loop stimulation teaches little. The culture needs to feel that its spikes changed the world. That embodiment idea is central to DishBrain (Kagan et al., 2022, Neuron).

The Science Behind the Headlines: Free Energy and Feedback

The DishBrain work did not use conventional reward labels like a reinforcement learning pipeline with explicit score tensors. It drew on active inference and the free energy principle (Friston, 2010; Kagan et al., 2022).

Plain English version: the system nudges neural cultures toward predictable sensory outcomes when they do something useful, and away from chaotic stimulation when they do not. Over time, activity reorganizes. Synapses shift. The culture behaves less randomly relative to the task.

That is why closed-loop structure matters so much. If the world never reacts to spikes, there is nothing to learn from.

Organoid Intelligence and the Bigger Picture

Cortical Labs sits inside a wider movement sometimes called organoid intelligence (OI) or synthetic biological intelligence (SBI).

The 2023 Frontiers in Science paper "Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish" outlines a roadmap for brain organoids as biological hardware, with richer 3D cultures, perfusion, MEAs, machine learning interfaces, and embedded ethics (Smirnova et al., 2023). Brett Kagan from Cortical Labs is among the authors, which tells you how connected these threads are.

Architecture diagram of an organoid intelligence wetware computing system
Organoid intelligence architecture diagram (CC BY 4.0, Smirnova et al., 2023). Kagan is a co-author. Source: Frontiers in Science.

CL1 today uses neural cultures on MEAs. OI tomorrow may push toward larger, more structured organoids with richer input/output. Same direction: biology as compute.

Walking Through the Research Library

The official research list is not one paper. It is a whole field guide. I grouped the published work the way I wish someone had grouped it for me.

Platform and tooling

  • CL API: Real-Time Closed-Loop Interactions with Biological Neural Networks - the software bridge developers actually use.
  • The CL1 as a platform technology to leverage biological neural system functions - why the hardware matters as infrastructure, not a one-off demo.

Learning in a game-world

  • In vitro neurons learn and exhibit sentience when embodied in a simulated game-world - the DishBrain / Pong paper in Neuron (Kagan et al., 2022).
  • Biological Neurons Compete with Deep Reinforcement Learning in Sample Efficiency in a Simulated Gameworld - sample efficiency comparison that gets cited a lot.
  • Dynamic Network Plasticity and Sample Efficiency in Biological Neural Cultures - follow-on comparative work with DRL.
  • Critical dynamics arise during structured information presentation within embodied in vitro neuronal networks - what happens inside the network when information arrives in structured bursts.

Synthetic biological intelligence as a field

  • A Computational Perspective on NeuroAI and Synthetic Biological Intelligence
  • Why AI Progress Will Necessitate Harnessing Synthetic Biology to Leverage the Ground Truth of Intelligence
  • Two roads diverged: Pathways toward harnessing intelligence in neural cell cultures
  • The technology, opportunities, and challenges of Synthetic Biological Intelligence
  • Harnessing Intelligence from Brain Cells In Vitro

Organoids, ethics, and definitions

  • Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish (Smirnova et al., 2023)
  • Intersection between the biological and digital: synthetic biological intelligence and organoid intelligence
  • Human Neural Organoid Microphysiological Systems Show the Building Blocks Necessary for Basic Learning and Memory
  • Neurons Embodied in a Virtual World: Evidence for Organoid Ethics?
  • Embodied Neural Systems Can Enable Iterative Investigations of Morally Relevant States
  • A Quantifiable Information-Processing Hierarchy Provides a Necessary Condition for Detecting Agency
  • Toward a nomenclature consensus for diverse intelligent systems: Call for collaboration

Methods and applications

  • A novel protocol for the efficient generation of all three major hippocampal neuronal sub-populations from human pluripotent stem cells - cell sourcing matters for reproducible cultures.
  • Drug treatment alters performance in a neural microphysiological system of information processing - one of the most practical near-term use cases: pharmacology on human-relevant neural hardware.
  • Active Inference and Intentional Behavior - theory tie-in for the feedback paradigm.
  • Starting a synthetic biological intelligence lab from scratch - practical guide for teams entering the space.

Key Papers Worth Reading First

Paper Year Why it matters
In vitro neurons learn and exhibit sentience when embodied in a simulated game-world 2022 Foundational DishBrain paper. Defines synthetic biological intelligence and closed-loop embodiment.
Organoid intelligence (OI): the new frontier in biocomputing and intelligence-in-a-dish 2023 Field roadmap for organoid-based biocomputing; connects to Cortical Labs via Kagan.
Biological Neurons Compete with Deep Reinforcement Learning in Sample Efficiency 2023 Direct comparison that makes the "biology learns fast" claim concrete.
The CL1 as a platform technology 2024+ Moves the story from experiment to productized research hardware.
Drug treatment alters performance in a neural microphysiological system 2023 Shows pharma-adjacent value beyond gaming demos.

Real Use Cases (Not Just Doom Memes)

Cortical Labs markets the CL1 for drug discovery, disease modeling, and understanding learning itself. That is more believable than "replace your laptop with a petri dish."

  • Neuropharmacology: test compounds on living human-relevant neural tissue and watch information processing change.
  • Disease models: compare healthy versus patient-derived neural cultures under identical closed-loop tasks.
  • Fundamental neuroscience: study plasticity with precise stimulation and readout at scale.
  • Hybrid AI research: pair biological networks with conventional ML encoders/decoders, as in the Doom work with PPO-style training on the digital side.
  • Reduced animal testing: Cortical Labs explicitly positions human cell-based systems as an ethically relevant alternative for certain experiments.

Ethics: The Part You Cannot Hand-Wave Away

Once neurons are trained in game-worlds and discussed using words like "sentience" and "agency," ethics stops being optional. Cortical Labs publishes on this directly, including work on organoid ethics, morally relevant states, and nomenclature for diverse intelligent systems.

The honest position: we do not fully know what these cultures experience, if anything. But the research community is already asking the right questions before the hardware gets cheap and widespread. That is better than the alternative.

How This Differs from Normal AI

Topic Silicon AI Cortical Labs / SBI
Hardware GPUs, TPUs, fixed weights in memory Living neurons on MEAs, physically rewiring over time
Learning Backprop, huge datasets, offline training Activity-dependent plasticity during closed-loop tasks
Energy Large for big models Biological systems can be far more efficient for some learning tasks
Programmability Exact, deterministic code paths Hybrid: digital encoder/decoder plus living substrate you steer, not fully control

What I Take Away

Cortical Labs is not claiming they shipped consciousness in a box. They shipped an interface to living neural computation that you can program. That alone is a category shift.

The research page is worth bookmarking because it spans the full stack: theory (active inference), experiments (Pong, Doom, drug response), platform engineering (CL1, CL API, Cortical Cloud), and ethics. Most labs pick one lane. Cortical Labs is trying to own the whole bridge between wetware and software.

If you are new here, start with the 2022 Neuron DishBrain paper, skim the OI roadmap paper from 2023, then watch the Doom demo with the understanding that the game is a test harness, not the end goal. After that, the rest of the library on corticallabs.com/research reads in order instead of like sci-fi fragments.

Still think biological computing is just a headline? Fair. Read the Neuron paper anyway. The methods section is where the hype goes to get audited.

Bibliography

Friday, 21 August 2026

Transfer Files Without Internet: How Decimen Sends Data Through a Screen and a Camera

Standard

 


I saw a headline about moving files with QR codes and no Wi-Fi and assumed it was a gimmick. Then I opened decimen.app, pointed one phone at another laptop screen, and watched a PDF rebuild itself from flashing squares. No cable. No Bluetooth pairing. No shared network. Just light.

The project is called Decimen, built by Evan Crawley (Bash Alarmist). Some articles spell it "Desimon," including a recent piece on Geeky Gadgets. Same idea. The real repo lives at github.com/bashalarmistalt/decimen-optical-transfer, where it has picked up thousands of stars for a reason: it solves a narrow problem very cleanly.

The One-Minute Version

Optical file transfer works like this:

  1. Device A encodes a file into a stream of animated QR codes on its screen.
  2. Device B points a camera at that screen and decodes each frame.
  3. After enough distinct frames arrive, the receiver reconstructs the original file.
  4. Nothing travels over Wi-Fi, cellular, USB, or Bluetooth between the two devices.

That last point is the whole pitch. You are not "offline syncing through the cloud." You are literally reading pixels. For air-gapped machines, embedded boards with only a camera, or situations where you do not trust any radio stack, that matters.

How Optical File Transfer Works Sender File + encoder Animated QR light QR frame stream Display camera Receiver Camera + decoder Rebuilt file No Wi-Fi, Bluetooth, USB, or network path Data moves only as pixels captured by a lens

Why Fountain Coding Changes Everything

Early QR transfer demos often chopped a file into numbered chunks. Frame 1, frame 2, frame 3. Miss frame 2 and you are stuck waiting for the loop to come back around. In bad lighting, with a cheap camera, or when the screen refresh rate and the camera shutter do not line up, dropped frames are normal.

Decimen uses fountain coding, specifically Luby transform codes (Crawley, 2026; Luby, 2002). Instead of shipping unique sequential slices, the sender emits mathematically mixed frames. The receiver needs roughly K × 1.15 distinct frames, in any order, to peel the file back out. A missed frame slows you down. It does not break correctness.

That design fits the channel. A screen-to-camera link has no back-channel. The sender cannot ask "did you get packet 47?" It can only keep flashing codes and hope the camera catches enough of them. Fountain codes were built for exactly that kind of one-way, lossy pipe.

Fountain Coding vs Sequential QR Chunks Sequential (fragile) 1 2 miss 4 One dropped frame breaks the chain Fountain (Decimen) A drop C D Any ~K x 1.15 distinct frames rebuild the file Luby transform frames are mathematically mixed Order does not matter. Lost frames cost time, not correctness. Sender has no back-channel, so redundancy is built into every frame.

The same fountain-code idea showed up earlier in Ivan Daniluk's txqr project (Divan, 2018), which is worth reading if you want the theory without the browser polish.

What Decimen Actually Ships

Decimen is not a research slide deck. It is a working web app plus open-source codebase (Crawley, 2026):

  • No install required. Open decimen.app on two devices. It can cache for offline use and install as a PWA on iOS and Android.
  • Files up to 64 MB, or pasted text, with filename and MIME type preserved.
  • SHA-256 verification before download is offered, so you know the rebuild matched the sender.
  • Optional gzip when compression helps.
  • Export as looping animation (APNG or PNG sequence), so a recorded video of the QR stream can be decoded later by any camera pointed at playback.
  • Twelve UI languages, with RTL layout where needed.

Important caveat straight from the README: neither mode is encrypted. Anyone with line of sight to the screen can read what is flashing. Decimen gives you isolation from networks, not secrecy from nearby eyes. Treat it like shouting a file across a room, not like end-to-end encryption.

How Fast Is It, Really?

When Geeky Gadgets covered the project, they cited roughly 128 KB/s as a practical ceiling (Horsey, 2026). That matched early impressions. The project has moved since then. Crawley publishes benchmark "receipts" in the repo, and the current records (August 2026, v0.4.0) look like this:

Device pair Sustained Peak 1 MB transfer
Desktop monitor to iPhone 418.5 KB/s 601.5 KB/s 2.5 s
Phone to phone 199.2 KB/s 340.8 KB/s 5.1 s

Those numbers are goodput for the whole transfer, not a cherry-picked burst. Still not USB territory. A 10 MB config bundle might take half a minute phone-to-phone. But for logs, keys, firmware patches, or a short video clip into an air-gapped box, that is often fine.

What moves the needle:

  • Screen size and brightness. A large, bright panel (the record run used a 49-inch Odyssey G9) gives the camera more pixels per module.
  • Camera quality. Better optics resolve denser QR modules, which means more bytes per frame.
  • Distance and alignment. Keep the camera square to the screen and close enough that modules stay sharp.
  • Refresh vs shutter. LCD ghosting and frame-rate mismatch still cause drops. Fountain coding absorbs the drops, but you pay in time.

Decimen vs LiveDrop and the Rest

Decimen is open source and browser-native. LiveDrop, covered by PetaPixel (Kritsonis, 2025), is a Dutch commercial product chasing the same optical channel with a mobile app and SDK. Both flash dynamic QR-like codes. Both work without Wi-Fi or Bluetooth between devices. The differences are mostly product shape and tuning.

Project Access Reported speed Notes
Decimen Free web app + AGPL source Up to ~419 KB/s sustained (published benchmarks) Fountain codes, SHA-256 check, 64 MB cap, no account
LiveDrop iOS/Android app, paid Windows tier, SDK ~700 kbps in 2025; testing 2.6 Mbps Long-range optics (hundreds of meters with telephoto lenses), optional encryption keys
txqr Open source (Go) Varies by setup Early animated QR + fountain code reference implementation
libcimbar Open source Higher density than QR Custom color barcode instead of standard QR modules

LiveDrop's team talks openly about optics as the bottleneck (Kritsonis, 2025). Phone cameras with wide apertures work well at short range. A 600 mm lens on a proper camera body can stretch the link to hundreds of meters. They are also experimenting with grey/blue tones and infrared for night transfers. Decimen stays pragmatic: standard QR modules, browser decoder built on ZXing, and reproducible benchmark JSON in the repo so skeptics can verify claims.

Crawley notes similar ideas arrived independently elsewhere, including airgapped-qr-code-transfer, which uses sequential chunking instead of fountain frames. Convergent evolution, not copying.

Where This Actually Gets Used

Most people will never need optical transfer. For the cases that do, it is oddly elegant:

  • Air-gapped systems. Push a patch or config onto a machine that never touches a network. The data path is visible light only.
  • Embedded and industrial gear. A laptop screen facing a controller with a camera module, no USB port exposed.
  • Remote or disconnected sites. Two laptops on a worksite with no router. Still faster than retyping hex.
  • Cross-platform friction. No Apple/Google ecosystem negotiation. If it has a browser and a camera, it can receive.
  • Pre-recorded drops. Export the QR animation, play it on a monitor in a lab video, and let receivers decode from the recording.

Geeky Gadgets frames the security angle as keeping data off external networks (Horsey, 2026). That is fair, with one correction: optical transfer is not automatically "secure." It is network-isolated. Shoulder surfers, cameras in the room, and recorded screens are all in scope.

Practical Tips If You Try It Today

I am not going to pretend setup is zero-friction. It is simple, not magic.

  1. Open decimen.app/send/ on the sending device and load your file.
  2. Open the receive page on the other device and grant camera access.
  3. Maximize brightness, kill night mode, and reduce glare if you can.
  4. Hold the receiver steady. Let the progress bar climb. Fountain coding means stutters are fine; giving up early is not.
  5. Wait for the SHA-256 check before saving.

Developers can clone the repo, run npm install and npm run dev, and hit the local HTTPS server from a phone on the same LAN for testing (Crawley, 2026). There is also a npm run benchmark path if you want to publish your own receipt.

Limits Worth Knowing Up Front

Optical transfer is a specialty tool, not a replacement for AirDrop or a cable:

  • Speed caps. Even hundreds of KB/s is tiny next to gigabit Ethernet.
  • No encryption by default. Decimen is explicit about this. LiveDrop can layer access keys, but the channel is still visible.
  • Hardware tuning. Ghosting on LCD panels, rolling shutter, and autofocus hunting all eat frames.
  • Line of sight. Obstructions and glare are failure modes, not edge cases.
  • Human patience. Large media works in theory (64 MB). In practice you will choose smaller files unless you are committed.

That is the honest trade. You gain a data diode made of photons. You lose bandwidth and confidentiality unless you add other layers.

Decimen turns a screen and a camera into a one-way file pipe with no network stack in the middle. Fountain coding is the reason it survives real-world frame drops. LiveDrop pushes the same idea toward commercial speed and long-range optics. Both sit in a growing family of optical exfiltration and sideload tools that sound like spy fiction until you need them on a factory floor.

If you have ten minutes and two devices, try the live demo. Watching a file materialize from blinking QR codes is the fastest way to decide whether this belongs in your toolkit or stays a neat party trick. For me, it crossed from gimmick to "oh, I would use this on an air-gapped laptop" somewhere around the first successful SHA-256 match.

Bibilography

  • Crawley, E. (2026). Decimen optical transfer: Fountain-coded QR file transfer [Computer software]. GitHub. https://github.com/bashalarmistalt/decimen-optical-transfer
  • Divan. (2018). txqr [Computer software]. GitHub. https://github.com/divan/txqr
  • Horsey, J. (2026, August 12). Transfer files without internet using optical QR codes. Geeky Gadgets. https://www.geeky-gadgets.com/transfer-files-without-internet/
  • Kritsonis, T. (2025, March 9). LiveDrop wirelessly moves data using dynamic QR codes and cameras. PetaPixel. https://petapixel.com/2025/03/09/livedrop-wirelessly-moves-data-using-dynamic-qr-codes-and-cameras/
  • Luby, M. (2002). LT codes. In Proceedings of the 43rd Annual IEEE Symposium on Foundations of Computer Science (pp. 271-280). IEEE.