Inspiration
O.C. Manjos is a 300+ product electrical merchant at Dei Dei International Market, Abuja. Like most small merchants, it has no digital inventory system, stock knowledge lives with the owner, and customer demand is tracked informally through WhatsApp. Busy product lines can quietly run out between manual checks, costing real sales. I wanted to see if a multi-agent system could turn that informal signal enquiry volume into an actual operational decision, without pretending we have inventory data we don't.
What it does
Three agents handle the pipeline end to end:
- Agent 1 & 2 (Intake + Qualification) extract the product from a raw customer enquiry, look up its real price against our worksheet, and check it against a qualification threshold.
- Agent 3 (Restock Recommendation) watches weekly enquiry volume per category. When volume crosses a threshold, it calculates the real order value quantity × unit price and makes a decision: orders under ₦100,000 are auto-approved, orders at or above ₦100,000 are escalated to the owner for manual approval. No purchase is ever placed autonomously.
A live dashboard shows the pipeline in real time, enquiry counts by stage, and restock decisions the owner can approve or reject with one click.
How I built it
Built with the Strands Agents SDK for orchestration, Groq (via LiteLLM) for inference, Supabase for enquiry and restock data, and a lightweight HTML/JS dashboard reading directly off Supabase with realtime updates. Pricing is parsed from our actual product worksheet, not mocked data. The dashboard HTML in this repo ships with placeholder Supabase credentials rather than real keys: a deliberate choice, since this is a public repository and the anon key currently has broad read/write access under our MVP-stage security policies. The demo video shows the dashboard running with real credentials locally; anyone wanting to run it live would substitute their own Supabase project's URL and anon key at the top of the script.
Challenges I ran into
The biggest one: my first version of the restock logic never actually calculated an order value, it only flagged that demand crossed a threshold, with no connection to real ₦ cost. Escalation at ₦100,000 was in my design docs but not in my code. Catching that gap and rebuilding the price lookup and value calculation properly was the real engineering work of this build, more than the initial pipeline itself.
I also had to be honest about scope: real inventory data doesn't exist yet, so this system is explicitly built on enquiry volume as a demand proxy, not a claim of tracking actual stock. Where the system can't confidently match a price, it says so rather than guessing.
What's next
Replacing the enquiry-volume proxy with real stock-level data once that's digitized, generalizing thresholds and categories so other small merchants could configure their own, and hardening the dashboard's access control beyond this MVP's open policies.
Built With
- groq
- html
- javascript
- litellm
- pandas
- postgresql
- python
- strands-agents
- supabase

Log in or sign up for Devpost to join the conversation.