Building SIBYL SYSTEM with Qwen Cloud — an engineer’s journey
Short summary: SIBYL SYSTEM is a modular multi‑agent platform that helps welfare and public‑safety teams triage, track, and act on cases with explainable AI, persistent memory, and human‑in‑the‑loop checkpoints. This post documents why we built it, how we integrated Qwen Cloud into the stack, the architecture we shipped for the hackathon, and the lessons we learned along the way.
Why we built SIBYL SYSTEM
Public‑service workflows are often fragmented: multiple teams, slow handoffs, and limited context when a case is escalated. We wanted an agent‑first system that:
- Remembers relevant case history across sessions without exposing sensitive data.
- Triages incoming reports automatically and routes them to the right team.
- Explains recommendations so human reviewers can trust and override decisions.
The hackathon prompt to build on Qwen Cloud gave us the perfect opportunity to prototype a production‑grade agent that combines cloud inference with robust memory and auditability. We submitted the project to the Global AI Hackathon with Qwen Cloud and documented our demo and proof artifacts as part of the submission.
The core idea
SIBYL SYSTEM is an Agent Society: multiple specialized agents (Ingest, Triage, Policy, Outreach, and a coordinating “Sibyl Hive Mind”) that negotiate task ownership, consult a shared memory layer, and escalate to humans when needed. The system emphasizes:
- Persistent memory with selective forgetting and consented scopes.
- Human‑in‑the‑loop checkpoints for high‑risk decisions.
- Tamper‑evident audit trails for every recommendation.
Architecture (high level)
Layers and components
- AI / Inference (Qwen Cloud): model calls for classification, summarization, and policy reasoning.
- Edge functions / Cloud gateway: Supabase Edge Functions and Alibaba Cloud microservices handle secure API routing and proof of deployment.
- Backend microservices: agent orchestration, memory manager, policy engine, outreach service.
- Message bus: RabbitMQ / Kafka for agent coordination.
- Data layer: Supabase Postgres for structured case data; Vector DB (Pinecone/FAISS/Milvus) for semantic memory; Redis for caching.
- Frontend: React + Vite dashboard for reviewers and administrators.
- Edge devices: Raspberry Pi / Edge TPU for local sensing and offline sync.
- CI/CD & Observability: GitHub Actions, Prometheus/Grafana, Sentry/OpenTelemetry.
A diagram and exportable PNG were created for the submission and included with our repo and demo.
How Qwen Cloud fits in
- Inference endpoint: Agents call Qwen Cloud for tasks that require deep language understanding (case summarization, policy‑aware recommendations, multi‑turn reasoning).
- Token budget management: we compress reasoning into structured templates to stay within token limits while preserving explainability.
- Multimodal potential: the architecture leaves room for future video/audio inputs (e.g., short incident clips) to be processed by Qwen or other multimodal models.
How we built it — practical steps
- Scaffold and repo: created a monorepo with frontend (Vite + React + TypeScript) and backend microservices (Node.js / FastAPI prototypes). The repo includes a Supabase functions folder used to demonstrate Alibaba Cloud integration.
- Agent prototypes: implemented lightweight agents as independent services that communicate over a message bus. Each agent exposes a small REST/gRPC surface for orchestration.
- Memory layer: hybrid approach — vector embeddings for semantic recall and relational rows for structured metadata. We used approximate nearest neighbor indexing to keep retrieval performant; naive retrieval is (O(n)) while indexed retrieval is approximately (O(\log n)). [ \text{Naive retrieval: } O(n) \quad\text{Indexed retrieval: } O(\log n) ]
- Human UX: built a reviewer dashboard where each recommendation includes a short rationale, confidence score, and one‑click override that updates memory and audit logs.
- Deployment proof: deployed backend services to Alibaba Cloud and added a proof file in the repo to satisfy hackathon requirements.
Challenges we faced
- Memory policy design: deciding what to store, for how long, and how to redact sensitive fields required policy work as much as engineering.
- Agent coordination: without explicit arbitration rules, agents can duplicate work or produce conflicting outputs; we implemented a lightweight lock/claim protocol on the message bus.
- Explainability vs token limits: compressing justifications into concise, structured templates while preserving enough context for human reviewers.
- Edge resilience: ensuring critical checks run locally when connectivity is poor required building smaller fallback models and sync logic.
What we’re proud of
- A working multi‑agent pipeline that completes end‑to‑end demo scenarios.
- Persistent memory with consented scopes and selective forgetting.
- A reviewer UX that makes it trivial to accept, modify, or reject agent recommendations while preserving audit trails.
- A complete submission package (repo, architecture diagram, demo) for the Qwen Cloud hackathon.
Lessons learned
- Design for trust: small UX details (clear rationales, easy overrides) are the difference between adoption and rejection.
- Memory is product work: it’s not just technical; it’s policy, privacy, and UX.
- Explicit conflict resolution is essential in multi‑agent systems.
- Operational constraints shape architecture early — token budgets, latency, and deployment targets matter.
How to try SIBYL SYSTEM
- Demo: view the running demo.
https://app-c7vje3odisxt.appmedo.com
(Demo link included in our submission.)
- Repository & proof: the repo contains the Supabase function used as proof of Alibaba Cloud deployment.
https://github.com/MiChaelinzo/SIBYL-SYSTEM/blob/main/supabase/functions/alibaba-cloud-proof/index.ts
(See the alibaba-cloud-proof function for the deployment proof file.)
TL;DR for the Blog Post Prize
- What to include: a public blog post or social post that explains your journey building with Qwen Cloud, links to your repo, and a short demo video. We included all required artifacts in our Devpost submission and repo.
Final notes and next steps
We plan to:
- Run a controlled pilot with a partner welfare agency to validate real‑world impact.
- Add adaptive forgetting and consented cross‑agency sharing policies.
- Publish the core repo and reproducible demos so other builders can extend SIBYL for different civic domains.
Top comments (0)