Most AI agent frameworks make you write Python glue code. Lots of it. Connect this model to that prompt. Route the output here. Add retry logic. Handle errors. Set up quality gates. By the time you've orchestrated three agents, you've written hundreds of lines of boilerplate that has nothing to do with your actual problem.
The aqm framework takes a different approach. You define your entire multi-agent workflow in a single YAML file. No Python required unless you want it. Quality gates, token optimization, multi-LLM routing - all declarative. And it's open source.
This isn't about removing code for the sake of it. It's about moving orchestration logic out of imperative scripts and into configuration where it's easier to reason about, version, and modify.
What Actually Lives in the YAML
An aqm workflow file describes agents, their capabilities, how they talk to each other, and what quality standards they need to meet. Here's what you can specify declaratively: which LLM each agent uses (Claude for reasoning, GPT-4 for synthesis, local Llama for classification - whatever makes sense), routing rules between agents, retry strategies when something fails, quality gates that check output before passing it downstream, token budgets to prevent runaway costs.
Normally, this is all imperative code. You write functions that call APIs, check responses, route messages, handle errors. It works, but it's verbose and hard to modify. Change the routing logic and you're editing try-catch blocks. Add a quality gate and you're refactoring conditionals.
In YAML, the same changes are config edits. Swap a model? Change one line. Add a validation step? Insert a block. The structure stays readable because it's declarative - you're describing what should happen, not how to make it happen.
Built-In Quality Gates (The Underrated Bit)
One feature that stands out: quality gates are first-class citizens. You can define validation rules inline - check for specific formats, verify outputs meet criteria, ensure responses stay under token limits. If a gate fails, the framework handles retries automatically.
This matters more than it sounds. Most AI workflows break in production because of inconsistent outputs. A model returns JSON when you expect markdown. Or exceeds a token budget. Or gives a 'good enough' answer that causes downstream problems. You end up wrapping everything in validation code, which obscures the actual workflow.
With built-in gates, validation is part of the workflow definition. You can see at a glance what quality standards each agent is held to. And when something fails, the retry logic is already there - you've defined how many attempts, what backoff strategy, whether to route to a fallback agent.
Token Optimization Without Manual Tracking
Token costs add up fast in multi-agent systems. You send a 5,000-token context to three agents, they each add output, suddenly you're burning through budget. Most frameworks make you track this manually - check token counts, truncate context, decide what to keep.
aqm handles this declaratively. You set token budgets per agent or per workflow. The framework optimizes context automatically - prioritizes recent messages, summarizes older context, drops low-priority information. You're not writing the optimization logic. You're specifying the constraints.
For anyone running agents at scale, this is the kind of feature that saves hours of debugging why costs suddenly spiked. The budget is visible in the config. Breaches are logged. You can audit token usage without tracing through Python.
When This Approach Makes Sense
YAML-based orchestration isn't always the right tool. If your logic is genuinely complex - dynamic routing based on runtime analysis, heavy integration with external systems, custom algorithms - you probably want code. The flexibility matters more than the convenience.
But if you're building workflows where the structure is mostly static, where agents have clear roles and predictable interactions, where the complexity is in coordination rather than computation... declarative config wins. It's easier to understand, easier to version control, easier to hand off to someone else.
And crucially, it's easier to test. You can validate a YAML workflow without executing it - check that agents are properly connected, gates are correctly configured, token budgets make sense. With imperative code, you have to run it to know if it works. With config, static analysis catches most problems.
The Open Source Angle
aqm being open source matters here. Agent frameworks tend to lock you into specific providers or patterns. If the maintainer decides to pivot, your workflows break. If they add features you don't need, you're stuck with the bloat.
With open source, you can fork it, strip it down, extend it, audit it. For businesses building production systems on AI agents, that's not ideological - it's practical. You need to know the orchestration layer isn't going to become a dependency nightmare.
And because the config is just YAML, you're not locked into aqm either. Worst case, you can write a parser that reads your workflow files and executes them differently. Try doing that with a codebase full of framework-specific decorators and abstractions.
What This Signals
The shift from code-based to config-based orchestration is happening across the AI tooling space. Not because code is bad, but because orchestration logic is fundamentally declarative. You're describing a graph of agents and data flows. That's naturally a config problem, not a programming problem.
As multi-agent systems become standard - customer support workflows, content pipelines, data processing chains - the tooling is moving toward declarative patterns. Less boilerplate, more structure. Easier to reason about, easier to modify, easier to audit.
aqm is one implementation of this shift. The interesting bit isn't the specific syntax. It's the recognition that orchestration belongs in config, and code should handle the parts that actually need logic. Separation of concerns, applied to AI workflows.
If you're currently maintaining 500 lines of Python that mostly just connects agents and handles retries, this approach is worth testing. Not because YAML is inherently better than Python. But because the structure you're building is fundamentally a graph, and graphs are clearer when you can see them whole.