Everyone is building **multi-agent systems. Nobody agrees on how to describe them.
I've been building with LLMs for the past two years. I've used LangChain, CrewAI, AutoGen, and a dozen smaller AI agent frameworks. Every single time, the experience follows the same arc: excitement, followed by a slow descent into configuration hell, vendor lock-in, and code that nobody on my team can actually read without opening a Python debugger.
At some point, I started asking a different question. Not "which agent framework should I use?" but "why do we keep building frameworks at all?"
Think about it. When you want to query a database, you don't write a Java class that wraps a PostgreSQL driver that wraps a connection pool that wraps a query builder. You write SQL. A few lines, declarative, portable, readable by literally everyone on the team, from the junior dev to the DBA to the PM who just wants to understand what data we're pulling.
We never got that for agentic workflows. And I think it's the single biggest bottleneck holding multi-agent AI systems back from real adoption.
The Reproducibility Crisis in AI Agent Orchestration
There's a dirty secret in the AI agent space: most multi-agent workflows are not reproducible. Not across teams, not across providers, not even across time.
You build something in CrewAI. Your colleague prefers LangGraph. Your client uses AutoGen. Each framework has its own way of defining agents, its own execution model, its own opinions about how data flows between steps. The workflow itself, the actual logic of "this agent researches, that agent analyzes, a third one reviews," gets buried under layers of SDK boilerplate.
This means three things. First, you can't share workflows without also sharing your entire stack. Second, switching LLM providers (or even models) requires rewriting code, not just changing a config line. Third, non-developers are completely locked out. Your PM can't read a CrewAI pipeline. Your domain expert can't verify that the agent flow matches what they described in the meeting. The workflow becomes a black box owned by whoever wrote it.
I kept running into this wall. I'd sketch a multi-agent flow on a whiteboard, everyone would nod, and then translating that whiteboard sketch into running code would take days. The sketch was simple. The code was not. Something was fundamentally wrong with the abstraction layer.
What SQL Taught Us About Declarative Languages (And We Forgot)
SQL was invented in the 1970s. Before SQL, if you wanted to query data, you wrote procedural code. You iterated over records, applied filters manually, joined tables in loops. It worked, but it was slow to write, hard to read, and impossible to port between database systems.
SQL changed everything not because it was more powerful than procedural code. It was actually less powerful. You can't write a web server in SQL. That's the point. It was a constrained, declarative language that did one thing well: describe what data you want, not how to get it.
The consequences were enormous. Suddenly anyone could read a query. DBAs, analysts, product managers. Suddenly queries were portable across databases (mostly). Suddenly tools could optimize execution because the language described intent, not implementation.
I believe agentic workflows are at the exact same inflection point. We're in the "procedural code" era. Everyone is writing imperative, framework-specific agent code. What we need is the declarative orchestration layer. A language that describes what agents should do and how they coordinate, independent of any runtime, any provider, any programming language.
Introducing SLANG: A Declarative Language for Multi-Agent Orchestration
SLANG stands for Super Language for Agent Negotiation & Governance. It's a minimal, declarative meta-language for multi-agent workflows. And it fits on a napkin.
The entire language has three primitives. stake means "produce something and send it somewhere." await means "wait until someone sends you something." commit means "I'm done, here's my result." That's it. Everything else, conditionals, loops, variables, structured output, those are built on top of these three operations.
Here's what a real agent workflow looks like:
flow "research" {
agent Researcher {
tools: [web_search]
stake gather(topic: "quantum computing") -> @Analyst
}
agent Analyst {
await data <- @Researcher
stake analyze(data) -> @out
commit
}
converge when: all_committed
}
Read it out loud. The Researcher gathers information about quantum computing and sends it to the Analyst. The Analyst waits for that data, analyzes it, outputs the result, and commits. The flow ends when everyone has committed.
Your PM can read this. Your designer can read this. An LLM can read this. And more importantly, an LLM can execute this, with zero tooling, zero installation, zero configuration.
Zero-Setup Mode: Run Agent Workflows in Any LLM Chat
Here's the thing I'm most excited about, and the part that took the longest to get right.
The same .slang file works in two completely different ways. You can paste it into ChatGPT, Claude, or Gemini with a system prompt, and the LLM becomes your runtime. It reads the flow, simulates each agent, passes data between them, and produces real output. No install. No API key. No SDK. I call this zero-setup mode.
Or you can run it with the SLANG CLI or API, and you get a full production runtime. Parallel agent execution, real tool handlers, checkpoint and resume, structured output contracts, deadlock detection, and support for 300+ models through OpenRouter. Different agents in the same flow can even use different LLM providers.
The same file. Both ways. Start by prototyping in ChatGPT, move to production when you're ready. This isn't something you can do with a framework, because a framework is, by definition, tied to a specific runtime. A language isn't.
Why JSON and YAML Fail as Agent Workflow Standards
I know what some of you are thinking. "Why not just use JSON or YAML to describe workflows?" I tried that. Everyone tries that. It doesn't work, and the reason is subtle.
JSON and YAML are data formats, not languages. They don't have semantics. When you write {"action": "research", "send_to": "analyst"}, that blob means nothing without a runtime that interprets it. And every runtime interprets it differently. You haven't created a standard, you've created a configuration file for one specific tool.
A language has grammar. It has a parser that validates structure. It has defined execution semantics. It has error codes and static analysis. SLANG has all of these. You can parse a .slang file, build a dependency graph, detect deadlocks before running anything, and get real-time diagnostics in your editor through LSP support. Try doing that with a JSON config.
More importantly, a language is something LLMs can learn, generate, and reason about. SLANG's syntax was designed from day one to be LLM-native. Function names are semantic labels, not code references. stake gather(topic: "AI trends") tells the LLM what to do in natural language. The structure tells it how to coordinate. This means you can literally ask an LLM to "write me a SLANG flow that does X," and it produces working code. Text-to-SLANG works the same way text-to-SQL works.
Lessons From Building an Open Source Agent Language
I shipped the first version of SLANG about six months ago. Since then, I've iterated through seven minor releases, adding variables, loops, conditionals, structured output, retry logic, a web playground, IDE support with full Language Server Protocol, and an MCP server that integrates with Claude Code and Claude Desktop.
A few lessons stood out.
Constraints are features. SLANG is deliberately not Turing-complete. You can't write arbitrary logic in it. That's by design. The limited surface area means the language is easy to learn, easy to parse, and easy for LLMs to generate correctly. Every time I was tempted to add a general-purpose feature, I asked myself: "Can this be handled by the LLM inside a stake call instead?" The answer was almost always yes.
The execution model matters more than syntax. The hardest part wasn't designing keywords. It was defining what a "round" means, how parallel execution works, when agents block, how data flows through mailboxes. Getting the execution model right meant that advanced patterns like iterative review loops, competitive analysis, and hierarchical delegation fell out naturally from the three primitives.
Zero-setup mode is the killer feature. I originally built it as a demo gimmick. But it turned out to be the thing people use most. Being able to paste a workflow into any LLM chat and have it execute immediately, that removes every single adoption barrier. No install, no signup, no configuration. Just paste and go. When I see someone go from "what is this" to "this is running" in under sixty seconds, I know the abstraction is working.
The Future of Declarative Agent Orchestration
I don't think SLANG is the final answer. I think it's the right question, phrased as code. The question is: can we separate the description of what agents should do from the mechanics of how they do it?
If the answer is yes, and I believe it is, then the implications are significant. Workflows become shareable artifacts, like SQL queries or Docker images. Teams can collaborate on agent logic without agreeing on a tech stack. LLMs can generate, modify, and optimize workflows directly. And the entire ecosystem can move faster because the orchestration layer is standardized.
SLANG is open source and available on npm. You can install it with npm install -g @riktar/slang, open the playground with slang playground, or just grab the zero-setup prompt and paste it into your favorite LLM right now. The spec, grammar, and full documentation are all on the GitHub repo.
I built this because I got tired of rewriting the same agent coordination logic in different frameworks. If you've ever felt that frustration, I think you'll find something useful here.
The SQL of AI agents. That's the bet. Let's see where it goes.
SLANG is **open source* under MIT license. Star the repo, open issues, contribute. The language is young and there's a lot of surface area to cover. If you're building multi-agent systems and want to help shape what this becomes, I'd love to hear from you.*
Find everything at: github.com/riktar/slang
Top comments (2)
SQL worked because it abstracted the data, not the engine. SLANG abstracts the intent, not the agent. That's the right layer. The frameworks you're replacing all optimize for the developer writing the code. You're optimizing for the person who has to read it six months later including the LLM.
The SQL analogy is compelling, but SQL succeeded partly because relational algebra gave it a formal foundation. What’s the equivalent formal model for agent coordination — does SLANG have one, or is it more convention-based?