Problem
Operational knowledge was scattered across documents, email threads, and the point-of-sale system. Answering everyday questions meant digging through files and systems by hand, and the same questions came up again and again across locations.
Selected work
Full-stack & AI engineer (team delivery) · 2025
Client delivery · anonymized under NDAAI Operations Copilot
An AI operations copilot for a multi-location hospitality business - chat grounded in the company's own documents, emails, and point-of-sale data, built on a real retrieval pipeline and agentic workflows. Client project, shown anonymized under NDA.
01 Scope
The product context behind the work.
My role
- Built the retrieval pipeline: ingest and normalize documents, PDFs, and emails into chunked, embedded, searchable content (Supabase / pgvector)
- Implemented agentic chat workflows with LangChain + LangGraph so answers stay grounded in the company's own data, with chat sessions and auto-generated titles
- Connected point-of-sale context through an integration layer so the copilot could be designed around operational data, not only static documents
- Delivered multi-tenant organizations, locations, users, billing, insights, and a voice interface (speech-to-text / text-to-speech)
02 Approach
How the work was shaped.
This was delivered for a client under NDA, so it's shown here without identifying details - the focus is on what was built and how.
The product is an AI operations copilot for a multi-location hospitality business. The operating idea was simple: most operational knowledge already exists - in documents, email threads, and the point-of-sale system - it's just hard to reach. So the copilot was built around getting trustworthy answers out of the company's own data, not around a generic chatbot.
The foundation is the retrieval layer. Documents, PDFs, and emails are ingested, normalized, chunked, embedded, and stored for search (Supabase / pgvector). On top of that sits an agentic workflow built with LangChain and LangGraph, so a question is answered through grounded retrieval and controlled steps rather than a single open-ended prompt. Chat sessions are saved and auto-titled so the experience feels like a real product.
A key design thread was the point-of-sale integration layer. The goal was to let operational data sit beside static knowledge sources while keeping the public case study generic under NDA.
Around the core sit the things that make it operational rather than a demo: multi-tenant organizations and locations, user management, billing, insights, and a voice interface for speech-to-text and text-to-speech.
Gallery
Architecture and flow.
03 Outcome
What the work made clearer.
Qualitative outcomes
Grounding
Retrieval-backed (RAG) answers over the company's own files, email, and point-of-sale data - not an open-ended chatbot
Reach
One copilot across documents, email, and point-of-sale, for a multi-location, multi-tenant business
Scope
Ingestion pipeline, agentic backend, point-of-sale integration layer, voice, multi-tenant orgs, and billing
Stack
Next.jsTypeScriptSupabase / Postgres (pgvector)LangChainLangGraphOpenAIVercel AI SDKExpressStripe
Reflections
- The hard part wasn't the model - it was the data layer: clean ingestion, chunking, metadata, and grounding so answers stayed trustworthy.
- The point-of-sale path was framed as an integration layer so operational data could sit beside static documents without exposing client or vendor identity.
Next step
Have a similar project?
If this looks close to the product work you need, use the contact path and I will help scope the next step clearly.