Teams

Bot Squad

Analytics Agent
6 updates
KL
Kyrylo Litvynov
May 12, 03:02 PM
!!!Attention!!! Here is our presentation for the solution: https://fairmarkit.slack.com/files/U08MR296K42/F0B33T1QVSN/ai_event_analyst_____fairmarkit_hackathon.pdf
?
KL
Kyrylo Litvynov Final
May 11, 10:01 PM
Sourcing teams should not have to wait until after an Event is closed to understand why it moved faster or slower than expected. Fairmarkit Events contain the answer, but the signals are scattered across line items, worksheets, lots, questionnaires, evaluation, approvals, supplier behavior, and timeline data. We built the AI Event Analyst: an event performance explanation agent that turns a selected sourcing Event into a clear, evidence-backed analysis report. It compares the Event against similar awarded Events, identifies the biggest drivers of cycle time, explains the “why” at the module level, recommends concrete next actions, and lets users ask grounded follow-up questions without handing them a blank chatbot. The problem. Event performance is hard to diagnose manually. A delayed award might be caused by supplier response friction, too many line items, complex worksheet structures, long questionnaires, slow evaluation, approval latency, or a combination of all of them. Those signals live in different modules, and teams often have to inspect them one by one. The result is slow, inconsistent analysis: buyers know an Event was late, but not what changed, what mattered, or what to do differently next time. The solution. The AI Event Analyst gives sourcing teams a repeatable post-event explanation workflow. A user selects an Event, chooses an analysis goal and focus area, and receives a structured report instead of an empty chat box. The system gathers Event context, compares it with similar awarded Events, runs module-specific analysis, returns top drivers, evidence, recommendations, charts, and follow-up prompts, and persists the result as a thread-backed report. AI is used where it adds judgment and explanation, but the experience is constrained by structured backend contracts, tenant-scoped data, typed schemas, and report-grounded context. How it works. Guided analysis setup. Users select an Event, intent, focus area, and optional custom instruction, so they do not need to write the perfect prompt from scratch. Event and module context gathering. The backend loads Event details, suppliers, line items, questionnaires, evaluation, approvals, comparable awarded Events, and available module data. Module-specific analysis. Specialized agents analyze Event details, line items, worksheets, questionnaire, evaluation, and approvals, producing structured module results with impact, evidence, and recommendations. Structured report generation. The result is not just prose. It includes a headline, benchmark stats, top drivers, module cards, recommendations, charts, suggested prompts, and reasoning trace blocks that the frontend can render directly. Report-grounded chat. Follow-up questions are scoped to the completed report and selected Event. The system can pull targeted source context and answer with evidence instead of acting like a generic chatbot. What-if simulation and action drafting. Teams can explore scenario controls, estimate likely cycle-time impact, and turn recommendations into structured action drafts with findings, prioritized actions, risks, and next steps. Operational readiness. Reports are tenant-scoped, persisted, streamed over WebSockets, observable through LangGraph/LangSmith traces, and backed by FastAPI, PostgreSQL, Redis, Pydantic models, and a React client with typed API contracts. Why it wins. Buyers get a clear explanation of what made an Event faster or slower. Managers get repeatable insight across sourcing activity instead of one-off manual review. Implementation and product teams get a contract-first experience that can stream progress, persist reports, render rich modules, and support follow-up exploration. The product turns scattered sourcing data into an embedded procurement analyst: one that explains what happened, why it mattered, and what to improve next time. Full source code: https://gitlab.fmdev.io/kyrylo.litvynov/fairmarkit-hackathon-squad-bot Frontend: https://gitlab.fmdev.io/kyrylo.litvynov/fairmarkit-hackathon-squad-bot/-/tree/master/src/client/app Backend: https://gitlab.fmdev.io/kyrylo.litvynov/fairmarkit-hackathon-squad-bot/-/tree/master/src/app App Architecture: https://gitlab.fmdev.io/kyrylo.litvynov/fairmarkit-hackathon-squad-bot/-/blob/master/src/client/API%20Architecture.md

Application URL: https://frontend-production-356a2.up.railway.app/
?
KL
Kyrylo Litvynov
May 11, 12:25 PM
We are finalizing/polishing our solution By numbers: 57 k+ lines of code Fully migrated to Lang Graph + LangSmith with routing on decision + proper tracing
VK
Viktar Kushch
sticker
May 11, 04:34 PM
VK
Viktar Kushch

Can not wait to see in action. I feel analytics will be one of the hottest battles!

May 11, 04:35 PM
?
KL
Kyrylo Litvynov
May 8, 02:34 PM
our current agentic graph orchestrator flow
AL
Aliaksandr Layuk
sticker
May 8, 03:03 PM
VK
Viktar Kushch
sticker
May 9, 01:01 AM
?
KL
Kyrylo Litvynov
May 7, 02:15 PM
Defined user flow + some insides of our app
AL
Aliaksandr Layuk
sticker
May 8, 03:04 PM
DA
Denis Atyasov
sticker
May 10, 08:55 PM
?
KL
Kyrylo Litvynov
May 6, 06:19 PM
We ran several brainstorms, synced with Product on key pain points, established the repo structure and made the initial commits. We also delivered the design system and make mockup for the main screen.
AL
Aliaksandr Layuk
sticker
May 8, 03:05 PM
DA
Denis Atyasov
sticker
May 10, 08:54 PM
?