u/Tutyfruiity

So njan oru textile shop ill partime job nokanu(4hr/day 4days off monthly)and they asked "whats the expected salary that im looking?". idk what to say pls help me 😭🙏🏽🙏🏽

I've been building a multi-agent personal finance tracker in n8n (Telegram → main agent → sub-agents → MongoDB). The sub-agent responsible for DB retrieval is giving me wrong/hallucinated results

Architecture:

Main agent — classifies user intent, picks the correct sub-agent, passes structured instructions (intent type, user_id, date range, filters)

MongoDB sub-agent — receives that structured input, builds + runs an aggregation pipeline, returns structured JSON back to main agent

DB: MongoDB, collection: transactions

What I've already done in the sub-agent system prompt

1. Full schema provided — every field, its type, allowed values, and constraints (e.g. amount_paise is the only money field, divide by 100 for INR, user_id is always an integer)
2. 15 intent types defined with explicit routing rules (e.g. monthly_summary, person_cash_flow, investment_tracking, savings_rate, comparison, etc.) and clear disambiguation rules like "if a specific person's name appears → always person_cash_flow, never any other transfer intent"
3. Pre-built pipeline templates for every intent — the agent isn't meant to write pipelines from scratch. Pipeline A through O are all written out. It just fills in variables like user_id, year, month
4. Hard arithmetic rules — the agent is forbidden from doing any INR math itself. All division happens inside $divide:["$amount_paise",100] within the pipeline. Only 3 post-pipeline calculations are permitted (savings_rate, savings_inr, comparison delta)
5. Strict $match ordering — user_id must always be the first field in every $match
6. Timeframe rules — agent uses pre-computed year/month/day/week_key integer fields, never parses date strings
7. Empty result handling — explicit fallback rules for every pipeline type (empty [] → return zeroed-out JSON, not an error or hallucination)
8. Strict output format — output is JSON only, schema defined per intent, no markdown, no explanation
9. Optional filter injection rules — how to handle amount ranges, platform normalization (always lowercase), regex for item_name/note search, etc.

Despite all this, the agent still:

• Reports transactions as non-existent when they clearly exist
• Returns wrong totals (e.g. investments total comes back as 0 when there are matching records)
• Occasionally returns a well-formatted JSON response with numbers it just made up
• Sometimes runs the right pipeline intent but with a broken $match (my suspicion)

Example(a valid case):

Main agent passes:

Find total investment transactions for May 2026, user_id, aggregation type: monthly_summary, filter: type=investment, date range: 2026-05-01 to 2026-05-31

Sub-agent returns a valid-looking monthly_summary JSON with investments: {total_inr: 6798, count: 1}

I've been building a multi-agent personal finance tracker in n8n (Telegram → main agent → sub-agents → MongoDB). The sub-agent responsible for DB retrieval is giving me wrong/hallucinated results

Architecture:

Main agent — classifies user intent, picks the correct sub-agent, passes structured instructions (intent type, user_id, date range, filters)

MongoDB sub-agent — receives that structured input, builds + runs an aggregation pipeline, returns structured JSON back to main agent

DB: MongoDB, collection: transactions

What I've already done in the sub-agent system prompt

1. Full schema provided — every field, its type, allowed values, and constraints (e.g. amount_paise is the only money field, divide by 100 for INR, user_id is always an integer)
2. 15 intent types defined with explicit routing rules (e.g. monthly_summary, person_cash_flow, investment_tracking, savings_rate, comparison, etc.) and clear disambiguation rules like "if a specific person's name appears → always person_cash_flow, never any other transfer intent"
3. Pre-built pipeline templates for every intent — the agent isn't meant to write pipelines from scratch. Pipeline A through O are all written out. It just fills in variables like user_id, year, month
4. Hard arithmetic rules — the agent is forbidden from doing any INR math itself. All division happens inside $divide:["$amount_paise",100] within the pipeline. Only 3 post-pipeline calculations are permitted (savings_rate, savings_inr, comparison delta)
5. Strict $match ordering — user_id must always be the first field in every $match
6. Timeframe rules — agent uses pre-computed year/month/day/week_key integer fields, never parses date strings
7. Empty result handling — explicit fallback rules for every pipeline type (empty [] → return zeroed-out JSON, not an error or hallucination)
8. Strict output format — output is JSON only, schema defined per intent, no markdown, no explanation
9. Optional filter injection rules — how to handle amount ranges, platform normalization (always lowercase), regex for item_name/note search, etc.

Despite all this, the agent still:

• Reports transactions as non-existent when they clearly exist
• Returns wrong totals (e.g. investments total comes back as 0 when there are matching records)
• Occasionally returns a well-formatted JSON response with numbers it just made up
• Sometimes runs the right pipeline intent but with a broken $match (my suspicion)

Example(a valid case):

Main agent passes:

Find total investment transactions for May 2026, user_id, aggregation type: monthly_summary, filter: type=investment, date range: 2026-05-01 to 2026-05-31

Sub-agent returns a valid-looking monthly_summary JSON with investments: {total_inr: 6798, count: 1}

Guys os exam change akkile 17th in? Circular onnum kandilalo🥲