It's Time to DisCo: The Case for Distributed Cognition in AI Agents.

Subtitle: Why we need to move beyond single-threaded loops and embrace event-driven cognitive architectures.

The "Single Loop" Trap

If you have built an AI agent in the last 18 months, your code probably looks something like this:

while not goal_achieved:

    observation = env.observe()

    thought = llm.think(observation)

    action = llm.act(thought)

    env.step(action)

This is the ReAct Loop. It is the foundation of Gen-1 agent frameworks like LangChain, AutoGen, and BabyAGI. It is brilliant for demos, simple to understand, and fundamentally unscalable for the enterprise.

Why? Because it is single-threaded cognition.

When you deploy this into production, you hit two walls:

1. The Human-in-the-Loop (HITL) Problem

Real-world enterprise processes rarely finish in milliseconds. Consider a "Procurement Agent" that drafts a purchase order but requires approval from a human manager.

In a single-threaded loop, the agent halts. It must spin and wait—potentially for hours or days—for that approval signal. If that script crashes or the server restarts while waiting, the context is lost. You cannot build a robust organization on software that has to "sleep" for three days.

2. The Framework Bloat Problem

We have spent the last year wrapping simple OpenAI API calls in increasingly complex "Agent Frameworks." But as many engineers are discovering, these frameworks often add more friction than value. You don't need a heavy, opinionated graph library just to call an LLM. Any competent engineer can write the logic to prompt GPT-4.

The hard problem isn't how to prompt. The hard problem is how to orchestrate state, history, and communication across 50 different agents running in parallel.

We are trying to build complex, asynchronous digital organizations using the synchronous architecture of a 1990s shell script.

Enter DisCo: Distributed Cognition

We need a new architecture. One that mirrors how human organizations actually work. We call it DisCo (Distributed Cognition).

DisCo is not a code framework; it is an architectural pattern. It decouples Cognition (the thinking) from Control (the flow).

In a DisCo architecture:

• 
  Agents are Services, not Scripts: They are long-lived "Workers" that react to events, rather than ephemeral loops.


• 
  Communication is Asynchronous: Agents don't "call" each other; they publish Intent ("I need this route optimized") and subscribe to Outcomes ("Route optimized by Agent B").


• 
  State is Durable: The state of the system lives in a shared, persistent ledger (the State Tracker), not in the Python memory of a single process.

The 4 Pillars of a DisCo Platform

To build this, you need more than just an LLM. You need a Cognitive Control Plane.

1. The Registry (Service Discovery)

In a monolithic script, you hardcode your tools. In DisCo, agents dynamically discover capabilities. A Planner doesn't need to know who will book the flight or where that code runs; it just queries the Registry for a worker with the book_flight capability. This allows you to hot-swap models (e.g., upgrading a worker from GPT-4o to Claude 3.5 Sonnet) without rewriting your orchestration logic.

2. The Event Service (Choreography over Orchestration)

Orchestration is a conductor waving a baton (central bottleneck). Choreography is dancers reacting to the music (distributed scale).

We use an Event Service (a smart proxy) to abstract the underlying message bus. Whether you run NATS JetStream locally for low latency, Google Pub/Sub in the cloud, or Kafka in the enterprise, your agents simply publish events. The Event Service handles the durability, fan-out, and protocol translation, ensuring thousands of agents can operate in parallel without a single point of failure.

3. The Tracker (Distributed State & HITL)

When Agent A hands off a task to Agent B, who tracks the deadline? The Tracker is a specialized state machine that monitors the lifecycle of distributed goals.

Crucially, this solves the Human-in-the-Loop problem. An agent can emit an ApprovalNeeded event and exit. The Tracker persists the state. Three days later, when a manager clicks "Approve" in a dashboard, the Tracker emits a TaskApproved event, waking up the next worker in the chain. No blocking. No wasted compute.

4. The Memory (Shared Context)

Agents need more than just their own conversation history. They need Episodic Memory (what happened yesterday across the fleet?) and Semantic Memory (what is our policy on refunds?). DisCo treats memory as a managed service, accessible to any authorized agent in the mesh.

Soorma: The Reference Implementation

This architecture sounds complex because distributed systems are complex. But you shouldn't have to build the plumbing from scratch.

That is why we are building Soorma.

Soorma is the open-source infrastructure for DisCo. We provide the control plane—the Gateway, Registry, Event Service, and Tracker—so you can focus on the logic.

Framework Agnostic

We believe you shouldn't be locked into a specific way of prompting.

• Want to use LangChain or CrewAI for your worker logic? Go ahead.


• Want to use raw OpenAI client calls? Perfect.


• Want to use a Rule-Based script for deterministic tasks? Even better.

You write the logic. Soorma handles the Connection, the State, and the Scale.

The Future is Asynchronous

The next generation of AI applications won't be chatbots. They will be Digital Organizations. They will run in the background, continuously optimizing supply chains, refactoring code, and monitoring security.

They won't run in a while loop. They will DisCo.

Join the movement.

We are building the foundation in the open.

Join the waitlist: soorma.ai

Star the repo: github.com/soorma-ai/soorma-core