By Reva Kale
A small business rarely runs on a single application. Customer conversations happen on WhatsApp, important emails sit in Gmail, invoices are created separately, receipts get buried in folders, and vendor details, stock updates and financial records live in yet more places. The problem isn't a lack of software. It's that these tools don't work together.
We started building MSME-360 around one question: what if a business could run its everyday operations from one connected platform, with an AI assistant that understands the information behind them?
I worked on the AI side of the platform: the chatbot, document retrieval, contextual search and persistent memory. The biggest lesson was that a useful assistant takes more than connecting an LLM to a database. It needs the right business information, an understanding of how that business operates, and strict boundaries around whose data it can access. This is how we approached it.
1. What We Wanted MSME-360 to Solve
MSME-360 is an AI-powered business management platform that brings everyday workflows together. Instead of treating communication, invoices, documents, vendors and finances as separate chores, we wanted them to work as parts of one system.
A unified inbox for business conversations
Businesses talk to customers and partners across many channels, and tracking those conversations separately makes it hard to keep context. MSME-360 brings supported channels such as Gmail, WhatsApp, Facebook and Instagram into a single inbox, so conversations are easier to find and manage without constantly switching apps.
The AI assistant also helps draft replies. Instead of starting every message from scratch, users get context-aware drafts based on the conversation and relevant business information. The goal isn't to replace the owner's judgment. It's to reduce the repetitive work of everyday communication.
Invoices and document processing
Invoices and receipts hold information that businesses need again and again: amounts, dates, customer details, tax information and payment records. MSME-360 combines OCR and document processing with invoice workflows, so users can extract useful data from receipts and business documents and manage GST invoices in one place.
The assistant makes that information easy to retrieve. A business owner shouldn't have to remember which folder holds a particular bill just to answer a question about it.
Customers, vendors and inventory
Running a business depends on maintaining relationships and knowing what is happening with stock. MSME-360 keeps customer and vendor records alongside inventory information, which gives both the assistant and the dashboard far more useful context. An invoice isn't just a PDF; it relates to a customer, a transaction and a larger workflow. Vendor and inventory records become more valuable the moment they can be read alongside everything else.
Where inventory is headed: an agent that drafts, and an owner who decides. Our vision is to let owners embed their inventory Google Sheets directly into the platform. When a customer message arrives, the AI agent checks the sheet and drafts an appropriate reply. The owner then reviews it and can edit, delete or send it. Escalation stays manual: the agent only drafts, and the human decides.
The flow we are building towards looks like this:
- A customer message arrives in the unified inbox.
- The agent checks the embedded inventory sheet and drafts a suitable reply.
- The owner reviews the draft and edits, deletes or sends it.
- If it is sent, the delivery process starts and the agent updates the sheet record.
- If stock ends up low, the agent suggests a vendor from the owner's own vendor list, based on past delivery experience, ratings and product quality.
Not all of this is built yet. It reflects our vision for a more automated business platform, with the owner always in control of what gets sent.
A financial hub
Financial information is far more useful when it isn't scattered across separate records. MSME-360 includes a financial dashboard that brings it into one accessible view. Combined with invoices, receipts and other business records, it helps owners understand their operations without manually searching through multiple sources.
An AI assistant connecting everything
The chatbot ties the platform together by offering a conversational way to work with business information. Rather than navigating every section by hand, users can ask questions, retrieve records, get help with invoices and draft business messages.
This raised a much more interesting engineering problem: how do you make an AI assistant understand both a business's records and the way that business operates? That question led us to two different retrieval systems.
2. One Assistant, Two Kinds of Knowledge
I initially thought one retrieval system would be enough. It wasn't. Consider two questions a business owner might ask:
- "What was our highest invoice last month?"
- "Make this invoice like the previous ones."
The first needs factual information from business records. The second needs an understanding of the owner's preferences and earlier instructions. These are different kinds of knowledge.
Vector search is good at finding relevant documents and records, but retrieving an invoice doesn't tell the assistant that the owner prefers a particular payment term. Persistent memory can hold those preferences and decisions, but it shouldn't become a storage system for every uploaded receipt.
So we separated the responsibilities:
- MongoDB vector search finds relevant business records and document information.
- Hindsight retains useful preferences, instructions and decisions across interactions.
This separation became one of the most important architectural decisions in the AI layer.
3. Part One: Retrieving the Right Business Information
When a user uploads a receipt, bill or invoice, the document is processed into text, summarised and converted into a 384-dimensional embedding. These embeddings are stored in MongoDB Atlas in the DecisionEvent collection, using a vector index named vector_index with cosine similarity.
When the user asks a question, we generate an embedding for the query and search for semantically relevant records. We also use a keyword-based fallback when vector search doesn't return sufficiently useful matches. This matters because exact names, invoice numbers and amounts don't behave like ordinary semantic searches. Looking up a customer name or an invoice number should never depend entirely on semantic similarity.
Tenant isolation at the retrieval layer
One of our most important decisions was making sure a user's search can never retrieve another business's records. We scope retrieval using the authenticated user's identity, rather than trusting the language model to remember what it is allowed to access.
A simplified version of the retrieval pipeline looks like this:
const pipeline = [
{
$vectorSearch: {
index: "vector_index",
path: "embedding",
queryVector,
numCandidates: 100,
limit: 3,
filter: {
userId: authenticatedUserId
}
}
}
];
The exact configuration depends on the index and the query, but the key detail is the user-level filter. We apply the same principle to ordinary database queries: access control belongs in the data layer, not just in the prompt.
The result is a small set of relevant records that can be passed to the assistant as factual context.
4. Part Two: Giving the Assistant Persistent Memory
Finding a document tells you what happened. It doesn't explain how the owner wants things done. For that, we integrated Hindsight, an open-source agent memory system from Vectorize. It gives an agent a persistent memory layer to retain and recall useful information across interactions.
We use it for things like:
- Business preferences and recurring instructions
- Decisions made in earlier conversations
- Preferred invoice and payment conventions
- Context that makes future interactions more useful
The assistant recalls relevant memories before generating a response, and after interactions, useful information can be retained for next time.
The important part is being selective. We don't want every sentence of every conversation to become permanent memory; we want to keep what genuinely improves future interactions. If an owner keeps explaining how invoices should be prepared, that instruction is worth far more as persistent memory than a passing question about a single receipt.
Memory access also respects the relevant user's or business's boundaries. One tenant's preferences must never become another tenant's context.
5. Bringing Retrieval and Memory Together
With both systems in place, the model receives two complementary sources of context: factual records from vector search, and relevant preferences and past decisions from memory. The overall flow looks like this:
This is what makes the assistant more context-aware than a chatbot that simply retrieves documents and generates an answer.
6. A Practical Example: From Repeated Instructions to Remembered Preferences
Imagine a business owner creating an invoice. On the first interaction, they ask for an invoice for Acme Corp worth ₹25,000. The assistant needs more information, and the owner explains:
- Always apply 18% GST on this business's standard invoices.
- Use 15-day payment terms.
These instructions are retained as useful business preferences. A few days later, the owner creates an invoice for a different customer. Instead of asking the same questions again, the assistant recalls the relevant preferences and applies them while preparing the new invoice.
The difference is simple:
- Without persistent memory, every new interaction risks starting from zero.
- With persistent memory, previous decisions can inform future workflows.
This matters in a business, where the same instructions are repeated across invoices, messages and everyday tasks. The assistant still has to respect the context of the current request and let the owner override a preference whenever necessary.
7. Making AI Actions Reliable
An assistant becomes far more useful when it can do more than generate text. In MSME-360 it supports workflows such as invoice generation and message drafting, using function calling: the model recognises when a supported operation is needed and supplies the information required to perform it.
Function calling isn't always predictable, though. While working with Groq models, including llama-3.3-70b and openai/gpt-oss-120b, we ran into tool calls that were malformed or incomplete. A response that reads well as text isn't necessarily a valid function call.
We added handling for malformed calls so that failures are caught and retried instead of surfacing a confusing error to the user. It taught me something important: an AI workflow needs the same attention to failure handling as any other backend integration. You cannot assume every model response is valid just because the prompt is clear.
8. Security and Multi-Tenant Boundaries
A platform that brings conversations, financial information, documents and records together needs strong isolation. The assistant may touch information that must never be visible to another business, so we built tenant-aware data access from the start:
- Business records are tied to authenticated users.
- Database queries are scoped to the appropriate tenant.
- Vector retrieval applies user-level filtering.
- Persistent memory retrieval respects tenant boundaries.
- Third-party integration credentials are encrypted with AES-256-GCM.
The larger lesson is that security can't be a final layer added once the AI features are done. A prompt saying "only use this user's data" is not an access-control mechanism. The backend has to enforce that boundary independently of the model.
9. What Took Longer Than Expected
Not every challenge was about picking the right model or database. One of the hardest decisions was what the assistant should remember. Retaining everything creates noise; retaining too little makes memory ineffective. We learned to separate what belongs in document retrieval from what belongs in persistent memory. A receipt should stay a retrievable business record, while a recurring instruction about how the owner wants invoices prepared is a much better candidate for memory.
Reliability across workflows was the other challenge. An assistant that answers questions correctly but fails when generating an invoice isn't much use to a business owner. That meant looking beyond the model's response to input validation, tenant checks, tool-call handling and integration failures.
10. What We Would Reuse in Another AI Project
A few lessons from building MSME-360 stand out:
- Build around real workflows, not just chatbot features. An assistant is more valuable when it helps users finish everyday tasks.
- Separate document retrieval from persistent memory. Finding a record and remembering a preference are different problems.
- Enforce tenant isolation in the backend. Never rely on prompts to protect private business information.
- Keep exact-match fallbacks. Vector search is powerful, but names, numbers and identifiers need extra handling.
- Retain selectively. Useful memory is about relevance, not storing everything.
- Treat tool calls as fallible. Validate model outputs and handle failures gracefully.
- Connect business context across modules. An invoice, a customer conversation and a vendor record become more useful when they work together.
11. The Technology Behind MSME-360
| Layer | Technology |
|---|---|
| Frontend | React |
| Backend | Node.js and Express |
| Database | MongoDB Atlas |
| AI and LLMs | Groq |
| Persistent agent memory | Hindsight |
| Document processing | Tesseract.js |
| Authentication | JWT |
| Integrations | Gmail, WhatsApp, Facebook, Instagram and Google Sheets |
| Document generation | PDFKit |
We also explored Hindsight Cloud while building the memory layer, and its documentation and community resources were useful along the way:
Final Thoughts
Building MSME-360 changed how I think about AI assistants. I started out believing the main challenge was getting a model to retrieve the right information and write a useful answer. A real business needs much more. It needs its conversations, documents, customers, vendors, inventory, invoices and finances to work together. It needs an assistant that uses that context without asking the same questions again and again. And it needs the security and reliability expected of any platform that handles business data.
That is the direction we want to take MSME-360: towards an automated business platform where the agent drafts, checks stock, updates records and even suggests the right vendor, while the owner stays in control of every decision that matters.
The goal isn't just to build a chatbot for small businesses. It's to build a business assistant that understands the workflows behind the business. Retrieval helps it find what happened. Memory helps it understand how the business prefers to work. Connecting both to real business operations is what makes it useful.
Explore MSME-360

Top comments (0)