Over several months, I helped build a production backend for oversized-load logistics operations. The work covered AI agents, document extraction, email intake automation, external APIs, security layers, logging, and deployment. This page only explains the useful project work and deliberately removes private personal and company-identifying details.
AI order support agentMultilingual estimate assistantInternal RAG knowledge searchVoice conversation transcriptionTranscript cleaning pipelineAgentic Gmail intake workflowFront desk operations dashboard
13
Major systems
5
Document types automated
/api/v1/order
Core endpoint
3
Support languages
Problem
What the system needed to solve
Operations teams had to read long email threads, PDF documents, registrations, permits, and order notes manually.
Drivers and employees needed quick answers about orders, routes, rules, pricing, and compliance without waiting for someone to search records.
External TMS platforms needed a clean way to submit order data and track status programmatically.
The business needed stronger security, logs, lifecycle notifications, and deployment practices around these AI workflows.
Build sequence
What I built, in order
The work grew from core workflow mapping into AI support, then document automation, then partner APIs, and finally production reliability.
1. I mapped the logistics workflow and designed the backend architecture
I first studied how oversized-load orders move through the business: intake, document collection, route details, permit checks, order creation, team handoff, status updates, and notifications. From that flow, I designed a modular Flask backend with route blueprints, controllers, MongoDB models, middleware, utility layers, and clean response contracts.
Separated the platform into clear domains such as chat, permits, document onboarding, TMS registration, API updates, admin operations, and LiveKit authentication.
Used MongoDB collections for orders, sessions, TMS clients, state rules, trucks, trailers, carriers, and users so the system could evolve without rigid relational migrations.
Designed the system as a production-oriented modular monolith, which kept deployment simple while still keeping each feature area maintainable.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
2. I built an AI order support agent for drivers and internal teams
The first user-facing AI feature was a support bot that answers order-related questions. The user provides an order reference, and the agent retrieves order context, checks rules, and explains the result conversationally instead of forcing a staff member to search database records manually.
Added tool-calling functions for order fields, permit rules, load compliance, journey compliance, provision files, and pricing details.
Connected the agent to fast LLM inference for responsive chat behavior and grounded each answer in retrieved operational data.
Added a dark chat widget, voice input path, speech response support, active-order context display, and feedback hooks for response quality review.
3. I created a multilingual estimator assistant
After support automation, I built a customer-facing estimator flow. It lets a user enter route details and load dimensions, then starts an assisted session that can explain estimated costs and requirements in a simpler conversational format.
Captured origin, destination, route states, length, width, height, weight, and overhang information for better estimation context.
Added English, Spanish, and Romanian support so the workflow could serve a wider logistics workforce.
Implemented selectable agent voices and a clean session-start flow so non-technical users could begin quickly.
4. I built a RAG knowledge system for employee support
The company had repeated questions about internal process, state rules, and operational decisions. I built a Retrieval-Augmented Generation system so employees could ask questions and receive answers grounded in internal knowledge instead of relying only on generic LLM memory.
Chunked and indexed internal conversation data and regulatory text so relevant context could be retrieved for each query.
Connected state-specific regulation files to the answer flow, including permit provisions and compliance context.
Improved consistency for new employees by preserving practical knowledge in a searchable support layer.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
5. I developed a Discord voice transcription bot
To grow the internal knowledge base, I built a bot that joins voice channels, listens to operational discussions, converts speech to text, and stores daily transcripts for later analysis and training data preparation.
Used Discord.js for voice-channel handling and Deepgram for speech-to-text transcription.
Implemented one transcript per day, per server, per voice channel, with automatic finalization at the configured end-of-day time.
Handled restarts safely by appending to the existing daily transcript instead of producing duplicate files.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
6. I cleaned raw transcripts into AI-ready data
Raw transcripts are noisy. I built a cleanup pipeline that normalizes the captured conversations so they can become useful retrieval and training material instead of messy text dumps.
Used spaCy English and Spanish models for language-aware text processing.
Removed noise artifacts, standardized formatting, and prepared cleaner chunks for downstream search and RAG ingestion.
Designed the process for batch cleanup so large transcript collections could be processed repeatedly as more data arrived.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
7. I automated front desk Gmail intake with an agentic workflow
A major operational bottleneck was email-based order intake. I designed a LangGraph workflow where specialized agents monitor email threads, classify relevant requests, extract useful details, and prepare structured order data for the team.
Built the workflow as a multi-step graph: monitor, classify, extract, consolidate, and prepare order-ready output.
Created a dashboard that shows intake stages, aging alerts, assignments, source links, order-building status, and ready-for-routing queues.
Reduced repetitive reading and copying work while giving the team a clearer operational view of the inbox pipeline.
8. I built external APIs for partner TMS platforms
Once internal flows were stable, I built public-facing API workflows so external transportation management systems could submit orders programmatically. The key endpoint accepts structured order data, document references, and multipart uploads, then returns an asynchronous acknowledgement.
Designed nested payload support for contacts, carrier data, truck data, trailer data, route stops, commodity dimensions, and documents.
Added field validation for driver and client emails, VINs, MC/DOT numbers, route stop dates, and dimensional data.
Implemented route-state inference, UTC route-date normalization, status polling, and callback support for downstream completion events.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
9. I added self-service API registration and secure key provisioning
To make partner onboarding practical, I built a registration page that collects workspace details, validates human users, verifies work email ownership, and then provisions API access in a controlled way.
Added CAPTCHA before registration to reduce automated abuse.
Added email OTP verification with expiration and attempt controls before key generation.
Stored client records with activation state, API key metadata, and admin controls for future access management.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
10. I built multi-document extraction for operational documents
I automated extraction from the documents that repeatedly appear in logistics orders: rate confirmations, truck registrations, trailer registrations, IFTA certificates, and insurance documents. The goal was to reduce manual reading and prepare order-ready data faster.
Rendered PDFs into images and sent them to vision-language models with document-specific prompts.
Processed multiple document URLs in parallel using ThreadPoolExecutor, then merged extracted values into a normalized payload.
Added VIN decoding and enrichment for truck and trailer records where useful.
11. I implemented the async order lifecycle and downstream handoff
Document extraction and downstream order creation can take time, so I moved the intake flow to an asynchronous lifecycle. Clients receive a fast acceptance response, while processing continues safely in the background.
Returned 202 Accepted with a generated order ID after validation and initial persistence.
Tracked lifecycle states such as received, processing, forwarded, created, and failed.
Added status polling and callback endpoints so external systems can follow the order without blocking their own workflows.
Backend and automation work: no public screenshot shown here because the original evidence includes private operational details.
12. I added security, notifications, observability, and deployment work
The final layer was reliability. I added practical controls around authentication, rate limits, callbacks, email notifications, structured logs, audit metadata, Docker deployment, and production runtime troubleshooting.
