-
-
Real qualification thresholds and restock approval logic, based on actual price data, not placeholder numbers.
-
Current scope, stated plainly — what's fully supported today vs. deliberately deferred, rather than silently guessed
-
System architecture: two agents, four core tools, and the ₦100,000 auto-approve/escalate decision path
-
The real enquiries table the restock agent queries: live data, not a mock dataset
Inspiration
I run O.C. Manjos, an electrical merchant with 300+ products at Dei Dei International Market in Abuja. Like most small merchants here, we track customer demand informally, WhatsApp messages, phone calls, memory. There's no digital stock system. When enquiries spike for a product, that signal is often invisible until we're already out of stock and losing sales we didn't even know we were missing. I wanted to build something that actually watches for that pattern, using data I already have, instead of pretending I have inventory software I don't.
What it does
This project uses two coordinated Strands agents:
Intake & Qualification Agent: Takes a raw customer enquiry, extracts the product being asked about (including size and phase for Distribution Boards), looks up the real price from our worksheet, and determines whether it's a high-value enquiry worth following up on. If a customer names a brand we haven't priced into the system yet, it says so plainly rather than guessing a price.
Restock Recommendation Agent: Since we have no stock-level data, this agent is built with a two-tier fallback: check real stock data if it exists, and if not (our actual situation), analyze enquiry volume over the last 7 days instead. If demand for a category crosses a threshold, it recommends a restock. Orders under ₦100,000 are auto-approvable; orders at or above that are escalated to me, no purchase happens without a human decision on anything significant.
How i built it
I used the Strands Agents SDK (Python) with Groq models via LiteLLM for inference, and Supabase for enquiry storage. The same enquiry data I was already collecting for a separate lead-qualification project. The core deterministic logic (price lookups, tier mapping, threshold checks) is implemented as plain Python functions wrapped as Strands tools, so the LLM's job is orchestration and communication, not arithmetic it could get wrong.
Challenges i ran into
Model and provider mismatches. Strands defaults to Bedrock; I wanted to use Groq, which meant routing through LiteLLM and getting the model ID naming right (Groq's own model names needed a doubled provider prefix to resolve correctly through LiteLLM). Tool-call reliability. Early on, letting the LLM re-type extracted values between separate tool calls caused it to invent shorthand that silently broke the pipeline — it once matched a completely wrong product because it passed "D8" instead of the full extracted keyword. I fixed this by collapsing the multi-step chain into a single deterministic tool, removing the LLM's ability to mangle data between steps. A quiet pricing bug. When testing a different brand (ABB vs. our supported A&B), the agent initially matched it to A&B's pricing anyway and only caught the mismatch through the model's own reasoning — not reliably. I fixed the extraction logic itself to explicitly detect unsupported brands and refuse to guess, rather than depending on the LLM to self-correct. Realistic demand thresholds. I initially guessed a restock threshold without checking it against real enquiry volume, and it would have made the restock agent almost never fire. Checking actual Supabase data (real Distribution Board enquiry counts) let me set a threshold that reflects real demand patterns instead of a guess.
Accomplishments that we're proud of
What we learned
That "agentic" doesn't mean "let the LLM do everything." The most reliable parts of this system are the deterministic Python functions; the LLM's real value is in orchestrating them and communicating results clearly. I also learned to distrust my own memory for business numbers — more than once, a price or threshold I was confident about from memory turned out to be different from what the actual data showed.
What's next for O.C Manjos Enquiry Agent
This build is deliberately scoped to one product category and one brand for the hackathon. The architecture is designed to extend, adding real stock-level data, other brands, and other product categories — with the eventual goal of generalizing this into a tool other small merchants could configure for their own businesses.
Log in or sign up for Devpost to join the conversation.