02 · Applied AI in logistics and procurement
AI assistants that work inside the rules
Two assistants, in logistics and in procurement, that answer from documents, read live operational data, and take actions — while the application keeps control of identity, permissions, and business rules.
- Company
- Grupo Inlog · Stratesys
- Role
- Senior Full Stack Developer
- Period
- 2024 — present
- Stack
- LLMs
- RAG
- MCP
- NestJS
- pgvector
- Azure AI Search
- Zod
- SSE
01 · The problem
People who run operations spend a lot of time moving between screens to find a status, check a document, or make a small change. A conversational assistant can shorten that path — but only if it never invents operational data and never acts beyond what the user is allowed to do. I worked on this problem twice: first on a waste-collection logistics platform, then on an enterprise procurement platform.
02 · What I did
- Logistics: connected a Next.js chat interface to NestJS services, with GPT-4o and responses streamed over Server-Sent Events.
- Worked directly on the retrieval pipeline — LangChain.js for document processing and chunking, OpenAI embeddings, and PostgreSQL with pgvector — storing source and organization metadata for traceability and filtering.
- Implemented MCP tools with the official TypeScript SDK, such as a route-status lookup. Arguments are validated with Zod; the user and organization come from the authenticated session, never from the model.
- Procurement: integrated Azure OpenAI and Azure AI Search into the NestJS backend, using hybrid keyword and vector retrieval — supplier names and codes need exact matches as much as questions need meaning — filtered by purchasing process and user permissions.
- Built an MCP write tool that updates the justification on a purchasing draft. Arguments are validated, the service checks edit permission and process state, and the assistant reports success only after the backend confirms it.
03 · The key decision
Separate knowledge from live state — and keep authority in the services.
Documents go through retrieval. Current status and actions go through tools backed by the same APIs the product already uses. The vector index is never the source of truth for operational data, and the model never decides who the user is or what they may change. It interprets the request; the application authorizes and executes.
04 · Interactive diagram
Original illustration of the engineering idea — not a product screenshot.
One request, three possible paths
Live data
- 01Read tool with schema-validated arguments
- 02Service checks the user’s organization
- 03Current status comes from the API, not the index
Services enforce identity, permissions, and business rules
Live data: Read tool with schema-validated arguments. Service checks the user’s organization. Current status comes from the API, not the index.
05 · What changed
Users can ask questions and complete supported tasks in conversation instead of navigating several screens. Retrieval was validated with known questions, expected source documents, and answers grounded in the retrieved passages. Adoption and time saved weren’t formally measured — a metric I’d now define on day one.
06 · Scope, honestly
My contributions are listed above. On the procurement side, document extraction and the initial indexing setup were shared with the team. Both assistants are part of larger products built by many people.