How NLSOM Lets AI Agents Coordinate in Plain Language

In 2026, according to McKinsey's State of AI 2024 report, 72% of organizations now use AI in at least one business function, up from 50% in previous years. Most of those deployments are single-model pipelines. The moment you add a second reasoning component, you hit the same wall every time: how do two separate models share state without a brittle, hand-coded interface between them?

Traditional multi-agent architectures solve this with explicit API contracts. One module calls another with a typed payload. The receiving module parses it, acts, and returns a structured response. This works until requirements change, a new capability needs to be added, or you scale past the point where a single orchestrator can track everything. Then the contracts become the bottleneck, and you spend more time maintaining the plumbing than building the actual logic.

Mindstorms, the open-source framework implementing Natural Language-Based Societies of Mind (NLSOM), takes a different position: if the models can read and write natural language, why not make that the coordination layer itself?

The core idea in NLSOM is that a collection of specialized models can self-organize around a shared task by passing natural language messages rather than typed data structures. Each participant in the system receives a description of the current problem state, reasons about its role, and contributes output in plain text. A lightweight orchestration layer routes those contributions, but it does not need to understand the content. It only needs to know who should speak next.

This matters because it decouples capability from interface. In a conventional pipeline, adding a new reasoning component means updating the schema every upstream and downstream module depends on. In an NLSOM-style build, you add a new participant, describe its role in natural language, and the existing components adapt. The coordination protocol is the language itself.

The framework also borrows from embodied AI research, specifically the idea that intelligence emerges from interaction with an environment rather than from a single monolithic reasoner. Each module in an NLSOM system maintains its own context window, its own memory, and its own reasoning loop. The "society" part is literal: you are designing a group of specialists who communicate, not a single system that routes subtasks internally. This connects directly to why specialized components consistently outperform monolithic designs in production builds.

Where NLSOM diverges from frameworks like LangChain or AutoGPT is in interpretability. Because every inter-module message is human-readable, you can inspect the full conversation history of a multi-model run and understand exactly why a decision was made. With typed API contracts, you see inputs and outputs. With natural language coordination, you see the reasoning chain.

I built our first Autonomous SDR on a flat three-component architecture: research, scoring, and writing all reported to a single orchestrator. It worked on 5 leads. At 50, the scoring module sat idle waiting on research that had nothing to do with scoring. Splitting into discrete components with explicit handoff contracts between them cut processing time and made each module independently testable. That is why every build we ship uses explicit inter-component schemas. Implicit data passing does not hold up past a certain volume, regardless of whether the coordination layer is typed JSON or natural language.

NLSOM does not eliminate this problem entirely. It shifts where the brittleness lives. Instead of a schema mismatch breaking your pipeline, you get a prompt interpretation mismatch. One module describes its output in terms the next module does not expect, and the reasoning goes sideways. The failure mode is softer and harder to catch in automated testing. You need evaluation harnesses that check semantic correctness, not just structural validity. That is a real cost, and it is worth naming before you commit to the approach. For a deeper look at how we think about managing these failure modes in long-running builds, see our notes on long-running process management for AI systems.

The practical starting point for NLSOM is defining roles before you write any prompts. Each participant needs a clear description of what it knows, what it is responsible for deciding, and what it should pass forward. Vague role definitions produce vague outputs, and in a natural language coordination layer, vague outputs compound across every subsequent step in the chain.

Memory is the second constraint. Natural language messages are verbose compared to typed payloads. In a long-running task with many participants, the shared context window fills quickly. You need an explicit strategy for summarization or retrieval, otherwise later participants in the chain receive truncated context and reason from incomplete information. This is not a theoretical concern. It surfaces in practice on tasks longer than a few dozen exchanges.

The third consideration is what ForgeWorkflows calls agentic logic: the decision about which participant acts next should itself be a reasoning step, not a hardcoded routing table. NLSOM supports dynamic routing, where the orchestrator uses an LLM to decide who speaks next based on the current state of the conversation. This is powerful, but it adds latency and a new failure surface. For most production builds, a hybrid approach works better: deterministic routing for well-understood task sequences, dynamic routing only for genuinely ambiguous handoffs.

As of mid-2026, the multi-component AI space is fragmenting. LangChain handles single-model chains well. CrewAI and AutoGen have made role-based multi-model orchestration more accessible. NLSOM occupies a different position: it is a research-originated framework that prioritizes interpretability and flexibility over deployment convenience. It is not the right choice if you need a production-hardened pipeline with minimal setup. It is the right choice if you are exploring coordination patterns that do not fit neatly into the role-assignment models that CrewAI and AutoGen assume.

The open-source availability matters here. Before frameworks like NLSOM, this kind of multi-model coordination research lived inside enterprise labs. Individual developers and small teams had no practical path to experimenting with society-of-mind architectures. That has changed, and the implications for what small teams can build are significant, even if the framework itself still requires meaningful engineering investment to use well.

One honest limitation: NLSOM is not a drop-in replacement for anything. It is a design philosophy with a reference implementation. You will need to build the scaffolding that connects it to your actual data sources, your memory layer, and your evaluation tooling. If you want to see how we structure that scaffolding in practice, the design-first approach to AI workflow architecture covers the principles we apply before writing a single node.

Natural language coordination is more interpretable than typed contracts. It is also less precise. A typed schema either matches or it does not. A natural language description can be partially correct, ambiguous, or subtly wrong in ways that only surface under specific conditions. Teams that adopt NLSOM need to invest in evaluation infrastructure that can catch semantic drift, not just structural errors. That investment is real, and it is ongoing.

This approach works well for exploratory tasks where flexibility matters more than predictability. It breaks down in high-stakes, low-tolerance pipelines where every output needs to be verifiable against a fixed specification. Know which kind of problem you are solving before you choose the coordination layer.

Start with two participants, not five. The temptation when adopting a society-of-mind architecture is to decompose aggressively. We would resist that. Two well-defined roles with a clean handoff teach you more about how natural language coordination actually behaves than five loosely defined ones. Add participants only when you have a specific capability gap that a new role would fill.

Build the evaluation harness before the pipeline. In typed-contract architectures, unit tests catch interface mismatches early. In natural language coordination, the equivalent is a semantic evaluation layer that checks whether each participant's output actually addresses the task it was given. We would build that first, not as an afterthought after the pipeline is already running.

Version your role descriptions like code. The prompts that define each participant's role are the specification for your system. Changing them without tracking the change is the equivalent of modifying a schema without a migration. We would treat every role description as a versioned artifact from day one, stored in the same repository as the pipeline code, with a changelog.