Mariam AI
Mariam is for call center employees at a mobile operator, and for subscribers who write in or send voice notes about billing or connection problems. Today an employee handles every ticket by hand. They read or listen, check the account, find the policy rule, decide, and reply. We estimate this takes about 12 minutes per case. At about 0.40 AZN per minute for a call center employee, that is roughly 4.80 AZN per case. Customers mix Azerbaijani, Russian and English, and voice notes have to be heard in full. Two employees can decide the same case differently, with no record of the policy rule behind the decision. Keyword rules only sort tickets into queues, so cost rises with every new ticket.
Preliminary score
- Value for the user20.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI21.5 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing14.5 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility11.5 / 15
Data requirements, running costs and a clear next step.
- Originality6.5 / 10
A meaningful difference from common solutions.
What the judges wrote
- Claude Opus 5.5Preliminary73/100
- Strengths
- Your scope is tight: one workflow (telecom billing and connectivity disputes), a named user, and a cost-per-case metric of 4.80 AZN versus about 0.017 AZN that a buyer can check. Your split between AI and code is well reasoned: the LLM handles mixed AZ/RU/EN understanding, tool selection, retrieval and explanation, while 20 deterministic detectors, a capped policy engine and idempotent refunds decide money. Your testing is honest. Expected outcomes were written before any runs, the policy engine and retrieval were measured (63/63, recall@4 = 0.98), and you report concrete failures with root causes and fixes (U02, H06, T08, the 16 s latency, the 404s after restart). Your next step, a 2-week shadow pilot with explicit success thresholds, is realistic and measurable.
- To improve
- Your deck and your written submission disagree. The deck's agent-vs-baselines table (56/63 against 34/63 and 15/63) is marked PRELIM, while the submission says the full agent has only run on 8 cases. Run the agent and both baselines on all 63 cases, then publish the measured numbers with the per-case results. Your current-process figures (12 minutes, 30% transfers, 0.40 AZN/min) are estimates, so one interview or call-centre data point would make the value case much stronger. Clean up the repository before the final: the README still contains unresolved git merge-conflict markers, and it names Railway/Netlify while the deck says AWS App Runner. Also give a cost breakdown per case that includes voice (ElevenLabs STT/TTS minutes), because $0.01 looks low for Sonnet plus voice.
- GPT-6 AstraPreliminary75/100
- Strengths
- Your project targets a concrete telecom workflow and clearly separates multilingual AI investigation from deterministic refund decisions. Your reported component tests and specific retrieval, confirmation and session-persistence failures show meaningful engineering iteration. Your proposed two-week shadow pilot has measurable acceptance criteria and keeps a specialist responsible for approval.
- To improve
- Reconcile the submission’s 7/8 completed agent cases with the deck’s preliminary 56/63 result, providing case-level outputs, held-out results and baseline configurations. Include reproducible chat and voice traces showing account evidence, policy selection and ledger changes; zero observed wrong refunds is not a guarantee of correctness. Validate the estimated 12-minute human baseline and include speech, hosting, retries and human review in your cost comparison. Resolve the README merge conflicts and deployment mismatch, and document authenticated access to operator data before the pilot.
The team
Taleh SadigovLead
business