Levy Rivers is the founder of Last Mile Driver Recruiting (LMDR) and an applied AI systems builder. He started LMDR in 2020 to fix the cost of bad decisions in trucking recruiting by building a working system around drivers, recruiters, and carriers.

LMDR (Last Mile Driver Recruiting) is an AI-native recruiting platform for CDL truck drivers. It pairs FMCSA carrier intelligence, agent orchestration, OCR document workflows, multi-provider model routing, and governed autonomy with a 24 to 48 hour driver match target.

What does Levy Rivers build at LMDR?

Levy designed and built LMDR as a working system: data pipelines, multi-model routing across Claude, Gemini, Groq, OpenAI, Perplexity, and Mistral, agent orchestration with role-aware copilots, voice and chat workflows, OCR document operations, FMCSA enrichment for over 25,000 carriers, AutoResearch experiments, and human approval where the action carries risk.

What is governed autonomy at LMDR?

Governed autonomy is the LMDR principle that any agent action must pass through policy, communication limits, audit logging, and human approval before reaching a driver, recruiter, or carrier. The platform includes a Soul layer of operating principles, a Heartbeat that sweeps surfaces on a schedule, and Memory with confidence-scored signals that can reinforce, expire, or decay.

What technical stack powers LMDR?

LMDR runs on Google Cloud Platform — Cloud Run, Cloud Tasks, Pub/Sub, Eventarc, Cloud Run Jobs, Cloud Workflows, Cloud Scheduler, and BigQuery — with PostgreSQL plus JSONB and pgvector as the source of truth, semantic retrieval for memory, and LRU caching to preserve high-performing response paths.

How can I contact Levy Rivers?

Email levy@lastmiledr.app or levynolanrivers3@gmail.com, call 214-531-3751, or reach Levy on LinkedIn at linkedin.com/in/levyrivers and on GitHub as LordKnowsBest.

LMDR driver-side founder profile

I build systems for the people carrying the load.

Q: Why did Levy Rivers build LMDR?

Trucking recruiting is high-volume, regulated, and operationally conservative. Levy built LMDR because the existing workflow made the cost of bad decisions invisible until people were already paying for them — drivers in the wrong job, recruiters losing the thread, carriers losing money on empty seats.

I built LMDR because driver recruiting was treating people like inputs. Drivers needed better matches. Recruiters needed cleaner decisions. Carriers needed proof before the seat went empty. The platform became the operating system for that work.

levy@lastmiledr.app 214-531-3751 LinkedIn GitHub

2020LMDR founded

0 to 1product architecture

6model provider routing

24-48hrdriver match target

Portrait of Levy Rivers, Founder of LMDR

Behind the build

“I built LMDR because the existing workflow made the cost of bad decisions invisible until people were already paying for them.”

Levy Rivers — Founder, Last Mile Driver Recruiting

Founder bio

A builder shaped by broken systems.

I came up in trucking recruiting. It is high-volume, regulated, and operationally conservative. Every bad workflow eventually lands on a person. A driver loses time. A recruiter loses trust. A carrier loses revenue.

I started Last Mile Driver Recruiting in 2020 after seeing the same failure repeat. Drivers were pushed into jobs they would leave. Recruiters were buried in manual follow-up. Carriers were making hiring decisions from stale, scattered data.

So I built LMDR as a working system. Data pipelines. Multi-model routing. Agent orchestration. Voice and chat workflows. Human approval where the action carries risk. A matching layer built around geography, compensation, experience, availability, engagement, and real outcomes.

The pattern has been consistent across my work. Diagnose the broken system. Redesign the framework. Train the people around it. Measure whether behavior changed.

AI only matters when people trust it enough to change how they work.

Explanation panel

Why I built what I built.

Trucking recruiting is a place where broken software does not stay abstract. A driver takes the wrong job. A recruiter loses the thread. A carrier loses money while a seat sits empty. I built LMDR because the existing workflow made the cost of bad decisions invisible until people were already paying for them.

The platform was designed to make the reasoning visible. A match score has to explain itself. A carrier dossier has to cite the source behind the claim. An agent action has to pass through policy before it reaches a driver, recruiter, or carrier. The point was never to make the system look intelligent. The point was to make the decision trustworthy enough for real operators to use.

Legible reasoningIf a driver cannot tell why a carrier scored well, the score should not exist.

Narrow agentsEach agent gets one outcome, explicit contracts, and typed handoffs so the work can be evaluated.

Phased autonomyAssist first. Supervise second. Automate more only when the evidence trail supports the next step.

Driver-side product instinct

LMDR keeps the driver surface concrete: pay, route, home time, documents, status, recruiter contact, and first dispatch.

Agentic workflow architecture

The system uses role-aware copilots, action registries, memory, approvals, and service dispatch instead of a single generic chatbot.

Adoption over demos

The work is built around operators. It has to fit real people, real constraints, and real decisions under pressure.

Agentic surfaces

The particle system is the workflow.

The moving particles below represent driver data, events, and human approvals crossing the product surface. Each route shows how a driver action becomes an agent decision, a service call, and a tracked outcome.

AI Matching LifecycleDriver intent moves through profile data, carrier intelligence, scoring, explanation, and application follow-up. Particles slow at human approval gates and accelerate after service dispatch.

Investor and resume signal

What the work proves.

LMDR is a product story and an execution story. It shows domain discovery, data modeling, AI system design, platform integration, user training, and go-to-market execution in the same body of work.

Implementation proof

Judgment inside the architecture.

The codebase was built to make AI useful inside a regulated recruiting workflow. The important point is not that models can produce output. It is why the system asks for that output, where it is constrained, and how the user can verify the result before trusting it.

AutoResearch experiments

AutoResearch adapts the Andrej Karpathy open-source pattern into LMDR by reading chat memories, proposing scoped experiments, evaluating outcomes, and promoting the best cached LRU responses.

WhyThe system should learn from real operator conversations without letting the model freely rewrite production behavior.TrustExperiments are bounded, measured, cached, and promoted only when they beat the prior response path.

OpenClaw memory, heartbeat, and soul

The Soul defines operating principles and hard stops, Heartbeat checks surfaces on a schedule, and Memory stores confidence-scored patterns that can reinforce, expire, or decay.

WhyAutonomy needs a working conscience, not just a faster queue.TrustCommunication limits, safety rules, audit logs, and memory decay keep proactive action bounded.

Cloud Run and Scheduler automation

Cloud Scheduler calls Cloud Run endpoints and Cloud Run Jobs with OIDC so enrichment, heartbeats, retries, campaign steps, notifications, and memory cleanup run on repeatable intervals.

WhyOperational reliability should not depend on somebody remembering to press a button.TrustBounded schedules, service accounts, and job logs make automation observable and accountable.

Semantic search and retrieval

Driver and carrier search uses ranked Postgres full-text search, trigram suggestions, geo filters, and memory mirrored into a RAG namespace with entity-scoped metadata.

WhyRecruiting search has to blend words, distance, profile fit, and remembered behavior.TrustScoped retrieval prevents useful context from becoming cross-user noise.

Ingestion to enrichment

FMCSA ingestion, deterministic carrier enrichment, OTrucking data, geocoding, NHTSA signals, social scan, web research, and model synthesis turn raw records into usable decision evidence.

WhyRaw carrier data is fragmented, stale, and hard for a driver or recruiter to evaluate.TrustFMCSA stays the source of truth, enrichment is cached, and conflicting signals are preserved.

OCR and document operations

CDL, medical card, MVR, and document upload flows use Gemini OCR, verification states, audit events, memory writes, XP triggers, and follow-up automation.

WhyCompliance review should be faster without hiding the verification decision.TrustExtraction supports the human workflow; verify, reject, audit, and chase remain explicit.

2020 to present

Founder and AI Systems Architect, LMDR

Built and deployed a production AI platform for recruiting lifecycle automation across drivers, recruiters, and carriers.

Developed the AI-native workforce platform roadmap across product buildout, commercialization, capital planning, and operational scale.
Built role-scoped agent behavior, tool execution, approval-aware actions, conversation state, intent routing, and reliability-focused system design.
Designed multi-provider routing across Claude, Gemini, Groq, OpenAI, Perplexity, and Mistral with cost-aware selection and fallback logic.
Built carrier intelligence and enrichment pipelines combining verified safety data, social sentiment, web research, and model synthesis.
Established governance-oriented operating structures: approval flows, reliability safeguards, decision controls, override logic, and audit-friendly execution.

2023 to 2024

Marketing Strategist and AI Integration Consultant, LMMA

Led discovery, process redesign, automation, analytics, and adoption training for logistics and service businesses.

Translated emerging technologies into practical workflows for teams with varied technical readiness.
Connected AI-assisted systems to client acquisition, lifecycle automation, analytics, and measurable business outcomes.
Built reusable enablement frameworks and adoption playbooks so client teams could operate systems independently.

2019 to 2020

Director of Marketing and Recruiting, Arnold Transportation

Managed a $2.5M budget, reduced costs 15%, and drove $1.75M in revenue growth through performance system redesign.

Built operating depth in stakeholder communication, analytics discipline, and cross-functional execution.
Led recruiting and marketing process improvements in a high-volume logistics environment.
Designed training and accountability systems that made new tools and process changes stick.

Technical buildout

Infrastructure, retrieval, and orchestration layer

Staged the platform around workflow reliability, observability, retries, and evidence-driven iteration.

Built GCP architecture using Cloud Run, Cloud Tasks, Pub/Sub, Eventarc, Cloud Run Jobs, Cloud Workflows, PostgreSQL/JSONB, and BigQuery.
Used embeddings, semantic ranking, pgvector similarity search, geo-aware matching, knowledge retrieval, and AutoResearch experiments to improve decision quality.
Applied LRU caching to preserve high-performing response paths and reduce repeated model work where the cached answer is already better.
Pressure-tested improvement claims through evaluation-minded deployment and guardrails-aware iteration.

Education

Purdue University and Southern New Hampshire University

M.S. Artificial Intelligence in progress. B.A. Marketing completed.

Purdue focus: policy and management, evaluation, governance, responsible deployment, and organizational adoption.
Marketing foundation: positioning, acquisition systems, stakeholder communication, and go-to-market execution.

Technical toolkit

PythonJavaScript / TypeScriptSQLGit / GitHubAutoResearchLRU cacheCloud RunCloud TasksPub/SubEventarcWorkflowsPostgres / JSONBBigQuerypgvector

Operating strengths

Technology roadmapping and staged investment planning across product, commercialization, and scale.
Governance frameworks for responsible AI deployment, approval-aware workflows, and operational risk controls.
Stakeholder translation between technical systems, business priorities, and operators who need usable workflows.
Scenario modeling for adoption, pricing, churn, runway, and phased technology investment decisions.

0 to 1 architecture

Data pipelines, service layers, agent routers, model routing, and workflow state built around a specific labor market.

Governed autonomy

Approval gates, recruiter overrides, memory, auditability, and policy preflight where automated action carries risk.

Adoption discipline

Built from operator pain, then trained around behavior change instead of stopping at technical deployment.