-
-
Live mission control after a code run: four specialists, 28 recorded events, and zero unresolved blockers.
-
Run recap links the rejected path, plan change, mind change, and evidence behind the final decision.
-
Verified code artifacts remain openable with source, tests, producer, SHA-256, and validation status.
-
A second mission uses the same society for an Atlas campaign, showing that the workflow is not code-only.
-
The generated Atlas hero opens inside its artifact record with producer, checksum, and independent validation.
-
The winning Atlas direction appears beside the rejected concept, reviewer critique, and material revision.
-
Work / Review shows ownership, the active brief, specialists, tools, and blockers as they arrive.
-
Architecture view: Qwen specialists, fixed tools, AgentBay execution, event ledger, and independent validation.
-
Final state remains inspectable: phase, event count, participants, blocker status, and working brief.
Inspiration
Most agent demos skip the part I care about: the work. You enter a prompt, wait, and get one polished answer. There is no way to tell who checked a claim, whether two approaches competed, what a tool actually returned, or why the system believes the result is ready.
The name is simple: Qwendom means Qwen Kingdom.
I built Qwendom for Track 3: Agent Society to make that missing process visible. The goal is a small working society, not a row of chatbots. Specialists share one room, answer one another directly, challenge risky assumptions, change position when evidence wins, and leave a trace a human can review.
What it does
A mission forms a temporary team around four core roles:
- Ada, Systems Architect keeps the boundary coherent.
- Ibn, Research Analyst grounds decisions in evidence.
- Lin, Implementation Engineer produces the actual deliverables.
- Noor, Adversarial Reviewer tries to break the work before it ships.
They do not return four parallel answers. They work in one causal Debate Ledger. A reply links to the claim it answers. A proposal can be challenged. A blocking objection pauses approval. When evidence changes an agent's position, the revision stays in the record.
Before execution, the team agrees on the goal, passes a readiness gate, elects a leader, and assigns bounded work. During execution, Qwendom records tool intent, results, failures, artifacts, and validation. The final answer is only one view of the run; Review, Recap, Dossier, and Artifacts reconstruct the same event history.
The demo follows two complete missions:
- Payment retry safety. The society narrows 1,284 failure records to 108 retryable cases, rejects a wider queue redesign, builds the adapter patch in AgentBay, fails an idempotency test, fixes the guard, and passes four tests with nine assertions.
- Atlas launch campaign. The society rejects a beautiful but generic postcard concept, chooses a product-led direction, generates a Lisbon hero and social variants, fails a mobile crop review, revises the composition, and validates the final image system.
How I built it
The control room is React. FastAPI provides the API and streams events to the interface over SSE. Agno runs the Qwen-backed specialists through the DashScope-compatible Qwen Cloud endpoint.
I kept orchestration policy outside the model. Team formation, readiness, leadership, tool grants, work dependencies, objections, votes, validation, and completion are typed runtime decisions. A model cannot silently grant itself a tool, invent an artifact, erase a blocker, or mark its own work as independently verified.
The main execution paths are:
- Qwen3.7-Plus and Qwen3.7-Max for reasoning, coordination, and synthesis.
- Context7 MCP for current technical documentation with recorded intent and provenance.
- AgentBay for isolated build, test, browser, and artifact-export workspaces.
- Qwen Image and Wan Video for media tasks.
- An append-only event ledger for the live room and every derived review surface.
The Builder never receives unrestricted host access. Qwendom opens a task-scoped AgentBay environment, stages only approved inputs, grants a narrow tool bundle, retrieves explicit outputs, hashes each artifact, and records cleanup. The producer and validator remain separate roles.
The specialist layer
The four named society roles govern the mission. After readiness and leader election, the leader selects from a fixed, repository-defined specialist catalog:
- Implementation Engineer works inside an isolated AgentBay sandbox, changes approved workspace files, runs code, and exports artifacts.
- Test Engineer independently reruns tests and acceptance checks. It does not change product files or approve work it produced.
- Image Creator generates, inspects, and publishes image artifacts for independent review.
- Frontend Engineer implements bounded UI work, renders it in a browser, and exports visual evidence from AgentBay.
Each specialist has a versioned capability profile, immutable tool bundle, resource policy, and artifact contract. The leader can select and sequence specialists, but cannot invent a new employee or grant extra tools through model output. A producer cannot validate its own artifact.
Society debates → leader selects fixed specialists → AgentBay execution → independent validation → synthesis.
The submission is deployed as containerized services on Alibaba Cloud, with Qwen models accessed through DashScope.
What makes it different
Visible coordination. Qwendom shows recorded contributions, direct replies, competing proposals, votes, objections, and mind changes instead of hiding the workflow behind one answer.
Bounded capabilities. Tools and specialist skills come from a repository-owned catalog. They are not invented by model output.
Independent completion. A producer cannot approve its own artifact. Failed checks and unresolved cleanup remain visible blockers.
Inspectable artifacts. Code, tests, images, reports, provenance, SHA-256 hashes, and validation status stay attached to the task.
Benchmark
I also ran a controlled benchmark. The single-agent path and Qwendom receive the same security-release audit, the same qwen3.7-plus model, identical evidence and tools, and the same deterministic 24-check evaluator. Discussion earns no points.
Across three controlled benchmark trials:
| Result | Single agent | Qwendom |
|---|---|---|
| Mean quality | 42.00 | 100.00 |
| Acceptance checks | 47/72 | 72/72 |
| Successful trials | 3/3 | 3/3 |
| Mean time | 18.40 s | 74.25 s |
| Qwen calls | 14 | 124 |
| Tokens | 921K | 3.9M |
Qwendom passed all 72 checks while the single agent passed 47, and scored 100 versus 42. The extra work is the point: Qwendom used 124 Qwen calls to let specialists challenge assumptions, turn objections into real blockers, revise failed work, and rerun validation; the single agent had 14 calls and no comparable review loop. Qwendom wins this benchmark because it can iterate until the evidence, artifact, and independent validator agree—not because coordination is free. That verification cost 3.9M tokens versus 921K, a deliberate trade-off for a substantially more complete result.
Challenges
The hardest problem was defining what “done” means. A sandbox starting is not proof that useful work happened. A file path is not proof that an artifact exists. A confident reviewer is not independent validation.
That led me to add typed blockers, task-owned artifacts, bounded retries, cancellation and cleanup events, redacted provider failures, and a pause/resume path for real human decisions. I also had to keep every UI surface honest: if the ledger cannot prove something, the interface must show it as missing rather than manufacture a clean success state.
What I learned
More agents do not automatically produce better work. Coordination earns its cost only when evidence changes a decision, a critic catches a real defect, or a revision improves the artifact. The most valuable agent in a society is often the one allowed to say “stop.”
What's next
I want to run the evaluator against more real provider executions, add broader multimodal missions, move durable events to Alibaba Cloud persistence, and keep improving the balance between quality, latency, and token cost.
Log in or sign up for Devpost to join the conversation.