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 (13)
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.
Thanks so much for this analysis! I'm looking for people to start experimenting with slang. If you'd like to try it and need support, you can find everything on the GitHub repo!
Alright I will take a look
I've been running a CrewAI setup with a RAG layer where Bright Data handles live web scraping, so the coordination problem is familiar territory. Going to give SLANG a shot.
For what it's worth, in my setup the coordination overhead was manageable once I got the crew structure right. The bigger blocker ended up being the context layer i.e what each agent actually knows, when it knows it, and how that degrades as you chain more steps. That might just be a function of my use case though.
Thanks for giving SLANG a shot!
Your point about the "context layer" and degradation across chained steps is spot on. That is arguably the hardest part of building reliable multi-agent systems right now. In frameworks that rely on a shared global state or automatic memory pooling, the context window bloat and the "telephone game" degradation happen incredibly fast.
SLANG tries to mitigate this by making data passing strictly explicit rather than implicit.
Because agents only receive exactly what is passed to them via a stake, and because you can enforce strict output: { ... } schemas at every step, you are naturally pushed to distill the context. Agent B doesn't inherit Agent A's entire messy scratchpad or full interaction history, it only receives the clean, structured payload Agent A was explicitly instructed to output. It forces a separation of concerns at the context level.
I'd really love to hear how this explicit routing feels compared to your CrewAI setup, especially once you hook up your Bright Data/RAG pipeline. Let me know if you run into any friction!
This resonates a lot.
The biggest pain I’ve seen isn’t building agents — it’s maintaining and sharing the workflow logic. Every framework ends up becoming its own “language”, but none of them are actually portable.
The SQL analogy is spot on. We don’t need more power — we need a constrained, readable layer that separates intent from execution.
Curious: how do you see this evolving alongside emerging standards like MCP or Agent Protocol? Do you think we’ll converge to one DSL, or multiple “interoperable” ones?
Hi! You can have a SLANG workflow where an agent uses an MCP server in its
tools: [...]array to fetch data, and the SLANG runtime handles routing that data to the next agent in the pipeline.My bet with SLANG is that a highly constrained, declarative, Actor-Model-style language is the right abstraction for 80% of business use cases.
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?
Instead of relational algebra, SLANG’s formal foundation is rooted strictly in the Actor Model of concurrent computation combined with Finite State Machines:
Message Passing: There is no shared memory or global state. Agents only communicate through explicit message passing (stake).
Mailboxes: The await primitive acts as the actor's mailbox, blocking execution until the required inputs (messages) arrive.
State Transitions: The workflow is essentially a directed graph (with cyclic capabilities). The strict output: { ... } schemas act as the typed contracts between the nodes in that graph.
So, while we don't have an "algebra for intelligence," SLANG enforces a strict, formal grammar (we have the EBNF spec in the repo) for how those probabilistic nodes interact. It prevents the system from entering undefined orchestration states, even if the node's output itself is generated by an LLM.
It's a formalization of the routing, not the reasoning.
Do you think the Actor Model provides a strong enough foundation for this kind of orchestration?
Love the 'zero-ghosting' philosophy. You've built more than an HR system—you've encoded empathy into workflow design. The MCP integration strategy (Slack for humans, Figma for design, AI for summaries) is elegant. One-command demo setup? Judges will love that. This is how HR tech should feel: human-first, not compliance-first.
i will steal this and add a layer to github.com/sebs/rewelo
What about self assembly?
Please steal it! That is exactly why the spec is open source. I’ll definitely check out rewelo.
Regarding self-assembly, this touches on a core design philosophy of SLANG: predictability over dynamic topology.
Right now, a .slang file defines a static, deterministic graph before execution starts. There is no native spawn() command for an agent to create another random agent mid-flight. This is intentional. Allowing unbounded self-assembly inside the runtime is the fastest way to get infinite loops and wake up to a massive API bill.
However, the "meta" self-assembly is completely possible.
Because SLANG is just plain text with a microscopic grammar, the easiest way to achieve self-assembly is to push it one layer up. You can simply have an "Architect" agent (or an initial prompt) whose exact task is to output a valid .slang string tailored to the user's specific problem.
User requests a complex task.
The Architect LLM generates a custom .slang workflow to solve it.
Your system intercepts that string, passes it to the interpreter, and executes the bespoke flow.
It keeps the execution layer safe and predictable, while still allowing the system to dynamically assemble workflows on the fly.
Let me know how the integration with rewelo goes, I'd love to see what you build with it!
Some comments may only be visible to logged-in visitors. Sign in to view all comments.