KenyaBiz AI is a multi-agent AI business assistant designed to support common customer and sales operations for Kenyan small and medium-sized enterprises (SMEs).
The system uses LangGraph to orchestrate specialized AI agents for customer support, product sales, order processing, invoice generation, and simulated M-PESA payment processing. A lightweight retrieval component provides company-specific information from a curated business knowledge base, while structured application logic manages products, orders, invoices, and payment states.
The project demonstrates how multiple specialized agents can collaborate through a shared state and controlled workflow rather than relying on a single general-purpose chatbot.
The complete source code, tests, configuration template, and documentation are available in the linked GitHub repository.
Small businesses frequently handle customer questions, product enquiries, quotations, orders, invoices, and payment-related communication through manual processes.
KenyaBiz AI explores how an agentic AI system can automate these interactions while maintaining a clear separation between different business responsibilities.
The project was developed as a practical multi-agent application for Kenyan SMEs. It combines retrieval, LLM-based routing, deterministic business logic, shared conversation state, database persistence, document generation, and automated testing.
The goal is not simply to create a conversational chatbot, but to demonstrate an end-to-end business workflow in which specialized agents cooperate to complete a customer request.
A typical SME customer interaction can involve several related activities:
Handling these activities independently can result in fragmented workflows and inconsistent customer experiences.
KenyaBiz AI addresses this problem by coordinating specialized agents through a shared workflow.
The main objectives are to:
KenyaBiz AI receives a customer's natural-language request and determines which business capability should handle it.
The system contains the following major components:
| Component | Responsibility |
|---|---|
| Supervisor Agent | Determines the appropriate business destination |
| Support Agent | Answers company and policy-related questions |
| Sales Agent | Handles products, prices, stock, recommendations, and quotations |
| Order Agent | Validates and creates customer orders |
| Invoice Agent | Generates invoices for confirmed orders |
| Payment Agent | Handles simulated payment requests, completion, and status |
| Retriever | Retrieves relevant information from the business knowledge base |
| Product Tool | Provides product and stock information |
| Quotation Tool | Calculates quotations and delivery charges |
| Order Tool | Creates and retrieves order information |
| Invoice Tool | Generates PDF invoices |
| Payment Tool | Manages simulated payment records |
| SQLite Database | Stores application transaction data |
| LangGraph | Orchestrates the overall workflow |
The system uses a supervisor-based multi-agent architecture.
The supervisor analyzes the customer's request and routes it to the appropriate specialized agent.
Conceptually, the workflow is:
Customer
|
v
+----------------+
| Supervisor |
+----------------+
|
+--------------+--------------+
| | |
v v v
+---------+ +---------+ +---------+
| Support | | Sales | | Order |
+---------+ +---------+ +---------+
| | |
| | |
+--------------+--------------+
|
v
+---------------+
| Invoice |
+---------------+
|
v
+---------------+
| Payment |
+---------------+
|
v
Customer
The actual workflow also uses deterministic routing rules for important transaction states. This prevents an ongoing order, invoice, or payment workflow from being incorrectly treated as a new general question.
This combination of LLM-based routing and deterministic workflow control provides a balance between natural-language flexibility and predictable business operations.
The Supervisor Agent is responsible for identifying the business intent of the customer's request.
It can route requests to:
Examples:
"What services does KenyaBiz provide?"
→ Support
"How much is an office chair?"
→ Sales
"I want to order 2 office chairs."
→ Order
"Generate an invoice for KBA-20261002-XHZL."
→ Invoice
"I want to pay for KBA-20261002-XHZL."
→ Payment
The supervisor uses structured output to produce a destination and routing reasoning.
The Support Agent handles informational questions about the business.
Typical questions include:
The agent uses the company's knowledge base to provide business-specific responses.
The Sales Agent handles product-related interactions.
It supports:
For example:
5 Office Chairs
+
2 Office Desks
can be processed into a quotation containing the subtotal and applicable delivery fee.
The Order Agent manages the ordering workflow.
It validates:
Once the customer confirms the order and provides the required customer information, an order reference is generated.
Example:
Order reference: KBA-20261002-XHZL
The Invoice Agent generates a PDF invoice from a confirmed order.
The workflow uses the order reference to retrieve the transaction information and generate an invoice in the local invoices/ directory.
Example:
invoice_KBA-20261002-XHZL.pdf
The Payment Agent supports a simulated M-PESA payment workflow.
It can:
Example:
Payment reference: MPSOB4HUUFW
Amount: KES 19,500.00
Payment status: PENDING
After simulated completion:
Payment status: PAID
The payment implementation is intentionally a simulation. It does not connect to the live Safaricom M-PESA API and does not process real financial transactions.
KenyaBiz AI includes a lightweight retrieval component for company-specific information.
The knowledge base currently contains documents covering:
The retriever loads the documents and identifies relevant content using lightweight keyword-based matching.
This approach was intentionally selected for the current capstone implementation because it keeps the system simple, transparent, and easy to run locally.
The current implementation does not depend on FAISS or Sentence Transformers.
Future versions could introduce semantic embeddings and a vector database for larger knowledge bases.
A central feature of KenyaBiz AI is shared state management.
The LangGraph workflow maintains information such as:
This allows the system to maintain continuity across multiple turns.
For example:
Customer:
I want to order 2 office chairs.
System:
Your requested products are available.
Please confirm that you would like to proceed.
Customer:
Yes.
System:
Please provide your name.
Customer:
Ambrose Lengerpei.
System:
Order created successfully.
Order reference: KBA-20261002-XHZL
The conversation can then continue using the generated order reference:
Generate an invoice for KBA-20261002-XHZL.
followed by:
I want to pay for KBA-20261002-XHZL.
and:
I have paid.
This demonstrates how state allows multiple specialized capabilities to participate in one continuous business workflow.
A complete transaction can follow this sequence:
Customer Request | v Supervisor Routing | v Sales / Order Processing | v Customer Confirmation | v Customer Details | v Order Creation | v Order Reference | v Invoice Generation | v Payment Request | v Simulated Payment Completion | v Payment Status The system therefore demonstrates an end-to-end business process rather than isolated agent responses. # 10. Example End-to-End Transaction A verified workflow was executed locally using the CLI. ### Step 1 — Create Order Customer: I want to order 2 office chairs.
The system confirms product availability and requests confirmation.
Customer:
yes
The system requests the customer's name.
Customer:
Ambrose Lengerpei
The system creates the order:
Order reference: KBA-20261002-XHZL
Customer: Ambrose Lengerpei
Office Chair x 2: KES 17,000.00
Subtotal: KES 17,000.00
Delivery fee: KES 2,500.00
Total: KES 19,500.00
Generate an invoice for KBA-20261002-XHZL
The system generates a PDF invoice.
I want to pay for KBA-20261002-XHZL
The system creates a simulated payment:
Payment reference: MPSOB4HUUFW
Amount: KES 19,500.00
Payment status: PENDING
I have paid
The simulated transaction is marked as:
Payment status: PAID
Check payment status
The system returns the stored payment information.
This demonstrates the integration of multiple agents and business tools within one continuous workflow.
| Technology | Purpose |
|---|---|
| Python 3.12 | Application development |
| LangGraph | Multi-agent orchestration |
| LangChain | LLM integration |
| LangChain-Groq | Groq LLM integration |
| Groq | Supervisor LLM |
| Pydantic | Structured output validation |
| SQLite | Local transaction database |
| Pandas | Product data processing |
| ReportLab | PDF invoice generation |
| Streamlit | Web interface |
| Pytest | Automated testing |
| python-dotenv | Environment configuration |
The Supervisor currently uses:
openai/gpt-oss-120b
through the Groq integration.
The application uses a local SQLite database for transaction-related data.
Product information is maintained separately in a CSV dataset.
The application therefore separates:
This separation makes the system easier to maintain and extend.
The system includes validation and controlled error responses for common situations, including:
Intermediate workflow states are explicitly handled so that incomplete transactions can continue instead of being incorrectly routed as unrelated requests.
The project includes an automated test suite using Pytest.
The final test run produced:
200 passed in 52.63s
The tests cover multiple parts of the application, including:
In addition to automated tests, the complete order-to-payment workflow was manually executed through the CLI.
This combination provides both component-level validation and end-to-end workflow verification.
The project is designed to run locally using a Python virtual environment.
The repository includes:
requirements.txt
.env.example
README.md
LICENSE
API credentials are not stored in the repository.
Environment-specific configuration is loaded through .env, while .env.example provides the required configuration structure.
The repository also documents installation, configuration, CLI execution, Streamlit execution, testing, and example workflows.
Sensitive credentials are excluded from version control.
The project uses:
.env
for local secrets and:
.env.example
as a safe configuration template.
The actual .env file is excluded through .gitignore.
The current M-PESA implementation is a simulation and therefore does not store or process real payment credentials or execute real financial transactions.
The main project structure is:
KENYABIZ-AI/
│
├── data/
│ ├── company_profile.md
│ ├── delivery_policy.md
│ ├── faq.md
│ ├── payment_policy.md
│ └── products.csv
│
├── src/
│ ├── agents/
│ │ ├── supervisor.py
│ │ ├── support_agent.py
│ │ ├── sales_agent.py
│ │ ├── order_agent.py
│ │ ├── invoice_agent.py
│ │ └── payment_agent.py
│ │
│ ├── database/
│ ├── rag/
│ ├── tools/
│ ├── utils/
│ ├── graph.py
│ ├── main.py
│ ├── state.py
│ └── streamlit_app.py
│
├── tests/
│ ├── test_agents.py
│ ├── test_products.py
│ ├── test_quotation.py
│ └── test_workflow.py
│
├── .env.example
├── .gitignore
├── LICENSE
├── README.md
└── requirements.txt
After cloning the repository, create a virtual environment and install the dependencies:
bash
python -m venv .venv
Windows:
powershell
..venv\Scripts\Activate.ps1
Install dependencies:
powershell
pip install -r requirements.txt
Create a local .env file based on .env.example and configure the required API key.
Run the CLI:
powershell
python -m src.main
Run the tests:
powershell
pytest tests -q
Run the Streamlit interface:
powershell
streamlit run src/streamlit_app.py
KenyaBiz AI can support interactions such as:
What services does KenyaBiz provide?
How much is an office chair?
Do you have office desks in stock?
Give me a quotation for 5 office chairs and 2 office desks.
I want to order 2 office chairs
Generate an invoice for KBA-20261002-XHZL.
I want to pay for KBA-20261002-XHZL.
Check payment status.
The current implementation has been validated through:
The test suite and documented workflow provide evidence that the implemented components operate together as an integrated application.
The project follows several software engineering principles:
Each agent has a clearly defined business responsibility.
LangGraph state enables agents to participate in a continuous workflow.
Critical business operations such as order validation, invoice generation, and payment state transitions use application logic rather than relying entirely on LLM responses.
Secrets and environment-specific settings are separated from source code.
Core functionality is covered by an automated test suite.
Agents, tools, retrieval, database operations, and orchestration are separated into dedicated modules.
The current implementation is a capstone prototype and has several limitations.
The current knowledge retrieval approach uses keyword-based matching rather than a semantic vector database.
M-PESA functionality is simulated and does not connect to a live payment provider.
The application currently uses a local SQLite database rather than a production database service.
The primary workflow has been validated in a local Windows development environment.
The project includes logging, but does not yet provide a full production monitoring and tracing platform.
Product availability is validated during ordering, but the current prototype does not implement a complete production inventory-management system.
Potential future improvements include:
These improvements would allow the prototype to evolve toward a production-oriented SME business platform.
KenyaBiz AI demonstrates how agentic AI can be applied to practical SME operations in a Kenyan business context.
Instead of treating every customer request as a generic question-answering problem, the system separates responsibilities and coordinates specialized capabilities.
The project therefore demonstrates several important agentic AI concepts:
The complete order → invoice → payment workflow provides a practical example of how these components can work together.
KenyaBiz AI is a functional multi-agent business assistant prototype for Kenyan SMEs.
It combines LangGraph orchestration, specialized agents, retrieval, business tools, shared state, SQLite persistence, PDF invoice generation, simulated M-PESA payments, and automated testing into one integrated workflow.
The project demonstrates that a multi-agent architecture can be used to divide complex business interactions into specialized responsibilities while maintaining continuity across the customer's journey.
The implementation is intentionally modular and provides a foundation for future improvements such as semantic retrieval, persistent memory, production databases, live payment integration, monitoring, and cloud deployment.
The complete implementation, tests, documentation, configuration template, and project instructions are available in the GitHub repository:
https://github.com/Lengerpei/KENYABIZ-AI
This project is released under the MIT License.
KenyaBiz AI was developed as a practical project applying concepts from the Agentic AI Developer learning program.
The project applies multi-agent orchestration, retrieval, tool integration, state management, and software engineering practices to a Kenyan SME business use case.