DEV Community

Shubham Vernekar
Shubham Vernekar

Posted on

Building Revenue Desk: A Multi-Agent Financial Operations Platform with Switch

#agents #ai #architecture

What happens when an AI agent analyzes financial data, gets the numbers wrong, and recommends a business decision based on that incorrect analysis?

In a normal chatbot, the conversation might end there. But in financial operations, an incorrect recommendation can have real consequences.

I wanted to explore a different approach: what if one AI agent could analyze business data while another independently checked its findings before a human manager made a decision?

That idea led me to build Revenue Desk, a multi-agent financial operations platform using Switch.

In this article, I'll walk through the problem, architecture, agent workflow, database integration, and some of the engineering decisions behind the project.

Project links:

1. The Problem: Can We Trust a Single AI Agent?

Imagine a sales manager asking:

"Why did repeat purchases drop in the West region last month?"

A single AI agent might:

  1. Query the sales database.
  2. Find a decrease in order volume.
  3. Assume customers are leaving.
  4. Recommend an aggressive discount campaign.

But what if the problem isn't customer churn?

What if refunds, cancelled orders, or payment discrepancies are affecting the numbers?

This is where I saw an opportunity to improve the workflow.

Instead of allowing one agent to analyze the data and make recommendations independently, I wanted a second agent to verify the findings using its own database queries.

The objective was simple:

Analyze first. Verify independently. Let humans make the final decision.

2. Introducing Revenue Desk

Revenue Desk brings two specialized AI agents and a human manager into a shared collaborative workflow.

The application has three main participants:

Analyst Agent

The Analyst handles the initial investigation. It:

  • Understands questions written in natural language.
  • Generates SQL queries.
  • Executes queries against the sales database.
  • Interprets the returned database records.
  • Suggests possible business actions.

Reviewer Agent

The Reviewer has a different responsibility. It independently checks the Analyst's findings.

It:

  • Generates its own verification SQL.
  • Checks refunds and cancelled orders.
  • Compares the results with the Analyst's findings.
  • Flags discrepancies for further review.

Human Manager

The manager remains responsible for the final decision.

They can inspect the analysis, review discrepancies, approve a proposed campaign, modify its parameters, or reject it.

3. Why I Chose Switch

I wanted the agents to operate as collaborators rather than separate AI chat interfaces.

Switch provided the room-based collaboration concept that suited this approach.

I configured a shared room called:

#revenue-desk

The idea is to keep the manager, Analyst, and Reviewer within the same conversation context.

For the integration, I implemented a Python bridge using matrix-nio. It connects separate Matrix bot accounts for the Analyst and Reviewer, listens for messages in the room, and routes incoming questions to the workflow orchestrator.

The application also provides a dedicated React dashboard for following the investigation and reviewing decisions.

This gave me a practical way to experiment with multi-agent collaboration while keeping the application interface accessible.

4. Architecture and Technology Stack

The project combines a Python backend, a database layer, an LLM integration, and a React dashboard.

Technology stack:

Component Technology
Frontend React 18, Vite, CSS
Backend Python
Database SQLite
Agent communication Matrix, matrix-nio
LLM integration Multi-provider Python client
Application server Node.js / Python
Collaboration Switch-compatible room integration

The LLM client supports Gemini, Groq, Anthropic, OpenAI, and a mock mode for testing without API credentials.

The Analyst and Reviewer have separate prompts, responsibilities, and execution paths.

Workflow overview 

          Human Manager
                |
                v
       Revenue Desk Room
                |
                v
         Analyst Agent
                |
        Generate SQL Query
                |
        Execute on SQLite
                |
        Analyze Real Results
                |
                v
         Reviewer Agent
                |
      Generate Independent SQL
                |
       Execute Verification
                |
       Compare Database Data
                |
          +-----+-----+
          |           |
       Verified    Discrepancy
          |           |
          +-----+-----+
                |
                v
        Proposed Business Action
                |
                v
         Human Approval Gate
                |
          +-----+-----+
          |           |
        Approve     Reject
          |           |
          v           v
       Execute     Record Decision
          |
          v
       Decision Log
Enter fullscreen mode Exit fullscreen mode

5. How the Two Agents Actually Work

One of the important implementation decisions was separating SQL generation from SQL execution.

I didn't want the model to simply generate numbers and present them as database results.

Step 1: Analyst generates SQL

The Analyst receives a natural-language question and generates an SQL query.

Step 2: Execute against the database

Python executes that query against SQLite and retrieves actual database rows.

The returned records are then passed back to the LLM for interpretation.

This gives the application a clear distinction between generated SQL and actual database results.

Step 3: Reviewer performs an independent check

The Reviewer receives the original question and the Analyst's findings.

It generates a separate verification query rather than simply asking the same model to repeat its previous answer.

For example, it can investigate refund records and calculate net revenue separately.

Step 4: Compare the results

The Reviewer compares the returned records and reports whether the findings are consistent or whether a discrepancy exists.

This is particularly useful when gross revenue and net revenue tell very different stories.

6. A Practical Example: Investigating a Revenue Drop

I built a sample financial scenario into Revenue Desk to demonstrate why independent verification matters.

A query initially reports a concerning decline in repeat purchases in the West region.

The Analyst investigates the sales records and produces its findings.

The Reviewer then checks the refund records and identifies discrepancies in the sample dataset.

The investigation demonstrates how gross revenue can give a misleading picture when refunds are not accounted for.

Instead of immediately launching an aggressive discount campaign, the manager gets an opportunity to review the discrepancy and make a more informed decision.

The important part is not just identifying the issue. It is ensuring that the proposed action is based on the verified findings.

7. Human Approval: Keeping Business Decisions Under Control

I didn't want an AI agent to independently execute a campaign or modify business records.

Revenue Desk uses an explicit workflow state machine:

  • IDLE
  • ANALYZING
  • REVIEWING
  • PROPOSING
  • AWAITING_APPROVAL
  • EXECUTING
  • COMPLETE

Once the agents finish their analysis, the workflow moves into AWAITING_APPROVAL.

The manager can approve, reject, or modify the proposed action.

Only after approval does the application execute the campaign-related database operations and record the decision.

This was an important design choice because financial operations require accountability, not just automation.

8. Building the Dashboard

Alongside the agent workflow, I built a React-based dashboard to make the system easier to understand.

The dashboard brings together:

  • Revenue and sales metrics.
  • Analyst and Reviewer conversations.
  • SQL queries and verification results.
  • Workflow task tracking.
  • Campaign approval controls.
  • Decision history.
  • Database inspection.

I wanted the interface to show what the agents were doing instead of hiding everything behind a single chat input.

It also makes it easier for a manager to understand why a particular recommendation was generated.

9. Running the Project Locally

You can explore the implementation through the GitHub repository.

Clone the project:

git clone https://github.com/Shubhamver45/Revenue-Desk.git

cd Revenue-Desk
Enter fullscreen mode Exit fullscreen mode

Install the dependencies:

pip install -e .
npm install
Enter fullscreen mode Exit fullscreen mode

Configure your environment variables using the example file:

cp .env.example .env
Enter fullscreen mode Exit fullscreen mode

For a local demonstration without an external API key, the project supports mock mode. You can also configure a supported LLM provider.

Start the Python application:

python3 app.py
Enter fullscreen mode Exit fullscreen mode

Or start the Node.js application:

npm start
Enter fullscreen mode Exit fullscreen mode

Run the tests:

python3 -m unittest discover tests -v
Enter fullscreen mode Exit fullscreen mode

Check the README for additional configuration details.

10. What I Learned Building Revenue Desk

This project helped me explore a few important ideas around multi-agent application development.

First, specialization matters. Giving two agents different responsibilities is more useful than simply asking one agent to repeat its own answer.

Second, database execution matters. An LLM-generated SQL query is not the same as a verified database result. Separating query generation, execution, and interpretation makes the workflow easier to inspect.

Third, human approval should be part of the architecture. It shouldn't be an afterthought when agents are proposing actions that affect business records.

Finally, collaboration needs visibility. Managers should be able to understand what each agent investigated, what it found, and why an action was proposed.

Revenue Desk is a hackathon prototype, not a production financial system. There is still work to do around permissions, persistence, deployment, and stronger validation before using this approach with real financial data.

Conclusion

Building Revenue Desk was an interesting exercise in moving beyond the usual AI chatbot approach.

I wanted to explore how specialized agents could collaborate, independently verify data, and support decisions without taking control away from people.

Switch gave me a room-based collaboration approach to build around, while Python, SQLite, and React helped bring the workflow into an actual application.

I believe the next step for AI applications isn't simply making agents more autonomous. It's making them more useful, transparent, and accountable when they work together.

I'd be interested to hear how other developers are approaching multi-agent verification and human-in-the-loop workflows.

Try the project:

Top comments (0)