Zalyx Agent Society

Multi-agent merchant underwriting where Qwen agents debate risk and explain financing decisions.

Comment

Inspiration

Zalyx Agent Society was inspired by a real underwriting problem: small merchants often have transaction data that is too nuanced for a simple yes/no model decision. A school may look inactive in the last 30 days because school payments are seasonal. A freelancer may have strong receivables but weak recent platform activity. A merchant may look healthy from revenue alone but risky when default-rate evidence is considered.

I wanted to build an underwriting system that does not behave like a black box. Instead of one model giving one answer, Zalyx Agent Society uses multiple specialized agents that review the same merchant from different perspectives, challenge each other, and produce a decision a human underwriter can inspect.

What it does

Zalyx Agent Society runs a five-agent underwriting review for merchant financing:

  • Data Quality Agent checks completeness, consistency, and compliance signals.
  • Business Analysis Agent reviews merchant health, revenue patterns, and sector context.
  • Risk Assessment Agent challenges the business case using default-rate evidence.
  • Financing Structure Agent explains Murabaha-compliant investment terms.
  • Human Review Agent synthesizes the full debate into a final decision.

The app shows merchant workspaces, streams agent progress in real time, stores decision history, and creates permanent report pages. It also compares the multi-agent result against a single-agent baseline so the difference in decision quality is visible.

The financing output is a monthly investment range rather than a random model-picked amount. Qwen explains the reasoning and conditions, while deterministic policy code computes the approved minimum and maximum range from merchant GTV, risk tier, affordability caps, and review-window rules.

How we built it

The backend is built with Node.js, Express, and TypeScript. The frontend is built with React and Vite. The app uses server-sent events so the frontend can show each underwriting stage as it completes.

All model-backed agents call Qwen Cloud through DashScope-compatible chat completions. Each agent returns structured output through typed tool calls, so the system reads scores, risk factors, decisions, and conditions from JSON instead of scraping prose.

I also built an MCP server with three underwriting tools:

  • check_cbn_compliance
  • get_industry_benchmarks
  • get_sector_default_rate

These tools give agents compliance, sector benchmark, and risk evidence during reasoning.

For deployment, the app runs in Docker on Alibaba Cloud ECS. Production persistence uses Alibaba Cloud Tablestore with merchant and decision tables. Local development uses file-based merchant snapshots and local decision history, while the cloud environment stores merchants and underwriting results in Tablestore.

Challenges we ran into

One major challenge was making the output feel realistic for a financial product. Early versions could return slightly different amounts for the same merchant on repeated runs. That felt wrong: a merchant offer should not feel like guesswork. I changed the design so Qwen handles reasoning and explanation, while the approved Murabaha range is computed deterministically by policy code.

Another challenge was separating local development behavior from cloud behavior. Locally, the app should load demo merchants from files and store decisions locally. In production, it should preload merchants into Alibaba Cloud Tablestore and store decisions there. Getting that boundary clean made the project much easier to explain and test.

Cloud deployment also took work: Docker build issues, environment variables, frontend serving paths, Tablestore setup, and health-check proof all had to line up before the live app could honestly report Qwen Cloud and Tablestore with mock mode disabled.

Accomplishments that I'm proud of

I am proud that the project is not just a chatbot UI. It has a real backend, structured agent outputs, MCP tool use, deterministic financing logic, persistent decision history, and a live Alibaba Cloud deployment.

The conditional debate flow is also important. The system does not force every merchant through unnecessary debate. It only opens the debate round when the business and risk agents meaningfully disagree, which makes the multi-agent workflow more practical.

I am also proud of the Murabaha structure. The system avoids interest-based loan language and instead models a fixed sale-price financing range with transparent profit margin, tenor, and affordability constraints.

What we learned

The biggest lesson was that AI systems need clear boundaries. Qwen is very useful for reasoning, comparison, explanation, and agent debate, but financial amounts should be controlled by deterministic policy. That split made the system feel more trustworthy.

I also learned that multi-agent systems are most valuable when each agent has a distinct job and a reason to disagree. The goal is not to make agents talk endlessly. The goal is to produce a better decision artifact: evidence, disagreement, resolution, and a final recommendation that a human can audit.

What's next for Zalyx Agent Society

Next, I would connect Zalyx Agent Society to live merchant transaction feeds so monthly review windows are based on continuously refreshed business data. I would also add an underwriter approval queue, customer-selectable offer amounts inside the approved range, repayment tracking, and stronger portfolio analytics across merchants.

Longer term, the goal is to make underwriting more explainable for small businesses: not just “approved” or “rejected,” but a clear view of what the business needs to improve before it can qualify for better financing terms.

Built With

Share this project:

Updates