Problem Framing: 30+ Orders a Day, Zero Intelligence in How They Move
In early 2026, we engaged with a fast-growing Indian FMCG biscuit manufacturer operating a multi-city distribution network — dispatching from manufacturing plants to distributors and retailers across North and Western India. The company was scaling rapidly, but its logistics operations had not scaled with it.
Every day, the logistics team manually planned 30+ sales orders — deciding which orders to consolidate, which truck to assign, and which route to take. This was done in spreadsheets, phone calls, and experience-based judgment by a 4-person logistics planning team that was already operating at capacity.
The specific pain points:
- Truck utilisation averaged 52-58% — meaning nearly half of every truck's capacity was wasted on every trip. The logistics team selected trucks based on availability, not optimal fit for the load.
- No order consolidation logic — orders going to nearby destinations on the same day were dispatched separately because nobody had time to cross-reference delivery windows and geography manually across 30+ orders.
- Reactive communication with customers — distributors discovered delays only when the truck did not arrive. No proactive notification existed. This generated 15-20 inbound escalation calls daily from distributors asking "Where is my delivery?"
- Scaling meant hiring — every incremental growth in order volume required additional logistics planners. The cost of logistics coordination was growing linearly with revenue, not logarithmically.
The customer profile:
- FMCG manufacturer (biscuits and snacks) with national distribution
- 30+ sales orders dispatched daily from 2 manufacturing plants
- Fleet: mix of owned and hired trucks (8-tonne to 22-tonne capacity)
- 100+ truck movements monitored daily
- Existing systems: SAP (order management), GPS tracking on all vehicles, Google Maps for routing
- Logistics team: 4 planners handling all dispatch coordination manually
- Key metric: logistics cost as a percentage of revenue was significantly above the operations head's internal targets
The design constraint: The operations head needed the system live within 10 weeks — before the upcoming festive season when daily order volumes would double. The existing 4-person team could not absorb the festive spike without either hiring 2-3 temporary planners or finding a way to automate the intelligence layer of logistics planning. Hiring was the fallback; automation was the goal.
Why This Approach: Agentic AI Over Traditional Route Optimisation
The Decision We Made (and What We Rejected)
Rejected: Traditional route optimisation software (TMS)
Transport Management Systems with built-in route optimisation (like Oracle TMS or SAP TM) would address the routing problem but not the decision-making problem. They optimise a given set of shipments — they do not decide which orders to consolidate, which truck size is optimal for a variable load, or when to split vs combine shipments based on delivery urgency. Additionally, TMS implementations typically take 4-6 months and cost ₹30-50 lakh for mid-market FMCG companies.
Rejected: Rule-based automation (if-then dispatch logic)
Build a rules engine: "If destination is within 50km of another pending order and delivery window overlaps, consolidate." This handles the obvious cases but breaks on the edge cases that consume 60% of the planning team's time — variable truck sizes, partial loads, mixed urgency orders, weight-vs-volume constraints. Rules cannot reason about trade-offs; they can only execute predetermined paths.
Selected: Multi-Agent Agentic AI on Amazon Bedrock
The architecture uses collaborating AI agents, each responsible for a specific logistics reasoning task:
- Orchestrator Agent: Analyses all pending orders and decides the dispatch strategy (consolidate, direct, or express)
- Order Grouping Agent: Intelligently clusters orders by destination proximity, delivery window, and load compatibility
- Truck Selection Agent: Calculates total weight and volume, selects the optimal truck targeting 70-95% utilisation
- GPS ETA Monitoring Agent: Continuously tracks shipments, recalculates ETA using live traffic, and triggers proactive notifications when delays are detected
Why agentic over rule-based or TMS:
- Reasoning about trade-offs: The orchestrator weighs cost vs speed vs customer priority — "Is it worth sending a half-full truck now for an urgent order, or can we wait 4 hours for two more orders to the same region and send one full truck?" Rules cannot make this judgment; agents can.
- Continuous adaptation: The GPS agent does not just track — it reasons about what a delay means operationally and decides who to notify and when.
- Auditable decisions: Every agent logs its reasoning — "Selected 14-tonne truck because total weight is 11.2 MT and volume is 680 cubic feet. 18-tonne truck available but would result in only 62% utilisation. 10-tonne truck insufficient by 1.2 MT." This audit trail is critical for operations management.
- 10-week deployment: Unlike TMS (4-6 months), the agentic system was deployable within the festive deadline.
Implementation Architecture: 10 Weeks to Production
The system was implemented over 10 weeks, going live in mid-March 2026 — six weeks before the first festive demand spike.
Key Implementation: The Orchestrator Agent Configuration
{
"agentName": "logystix-orchestrator",
"foundationModel": "amazon.nova-pro-v1:0",
"instruction": "You are the logistics planning orchestrator for an FMCG distribution operation. Each planning cycle, analyse all pending sales orders and determine the optimal dispatch strategy. Consider: destination proximity for consolidation, delivery window constraints, truck capacity (weight and volume), customer priority tiers, and cost efficiency. For each dispatch decision, log your reasoning explicitly — why you grouped these orders, why you selected this truck size, and what trade-off you made between cost and speed. When truck utilisation would fall below 60%, evaluate whether waiting for additional orders is viable within delivery windows before dispatching. Always confirm the final dispatch plan with the logistics manager before execution.",
"idleSessionTTLInSeconds": 3600,
"memoryConfiguration": {
"enabledMemoryTypes": ["SESSION_SUMMARY"],
"storageDays": 30
},
"actionGroups": [
{
"actionGroupName": "OrderAnalysis",
"description": "Fetch pending orders from RDS, analyse destinations, weights, volumes, and delivery windows",
"actionGroupExecutor": {
"lambda": "arn:aws:lambda:ap-south-1:<account-id>:function:logystix-order-analysis"
}
},
{
"actionGroupName": "TruckSelection",
"description": "Query available truck fleet, calculate optimal truck-to-load assignment targeting 70-95% utilisation",
"actionGroupExecutor": {
"lambda": "arn:aws:lambda:ap-south-1:<account-id>:function:logystix-truck-selector"
}
},
{
"actionGroupName": "ETAMonitoring",
"description": "Poll GPS coordinates for dispatched trucks, calculate ETA using Maps API, detect delays and trigger notifications",
"actionGroupExecutor": {
"lambda": "arn:aws:lambda:ap-south-1:<account-id>:function:logystix-eta-monitor"
}
},
{
"actionGroupName": "NotificationDispatch",
"description": "Send WhatsApp and email notifications to customers and operations team when delays are detected",
"actionGroupExecutor": {
"lambda": "arn:aws:lambda:ap-south-1:<account-id>:function:logystix-notifications"
}
}
],
"guardrailConfiguration": {
"guardrailIdentifier": "logystix-operations-guardrail",
"guardrailVersion": "1"
}
}The Truck Selection Reasoning Pattern
The most impactful agent behaviour is the truck selection logic — where the agent reasons about weight, volume, and utilisation rather than applying a simple lookup:
# Lambda: Truck Selection Agent — reasoning-based vehicle assignment
import boto3
import json
bedrock = boto3.client('bedrock-runtime', region_name='ap-south-1')
rds_client = boto3.client('rds-data', region_name='ap-south-1')
def select_optimal_truck(order_group: dict) -> dict:
"""
AI-powered truck selection: reasons about weight, volume,
utilisation targets, and available fleet to select optimal vehicle.
"""
total_weight_mt = order_group['total_weight_mt']
total_volume_cuft = order_group['total_volume_cuft']
destination = order_group['destination_cluster']
urgency = order_group['max_urgency_level']
# Fetch available trucks from RDS
available_trucks = query_available_fleet(destination)
# Build reasoning prompt for the agent
reasoning_prompt = f"""
Order group for dispatch:
- Total weight: {total_weight_mt} MT
- Total volume: {total_volume_cuft} cubic feet
- Destination cluster: {destination}
- Urgency: {urgency}
- Delivery window: {order_group['delivery_deadline']}
Available trucks:
{json.dumps(available_trucks, indent=2)}
Select the optimal truck. Criteria:
1. Truck must accommodate both weight AND volume
2. Target utilisation: 70-95% (by the binding constraint — weight or volume)
3. If no truck achieves >60% utilisation, recommend waiting for more orders
(only if delivery window permits)
4. If urgency is 'express', prioritise speed over utilisation
Return JSON with: selected_truck_id, utilisation_percentage,
binding_constraint (weight or volume), and reasoning explanation.
"""
response = bedrock.invoke_model(
modelId="amazon.nova-pro-v1:0",
body=json.dumps({
"messages": [{"role": "user", "content": reasoning_prompt}],
"max_tokens": 512
})
)
result = json.loads(response['body'].read())
return result
# Example output from the agent:
# {
# "selected_truck_id": "TRK-14T-007",
# "utilisation_percentage": 82,
# "binding_constraint": "weight",
# "reasoning": "Total weight 11.2 MT fits 14-tonne truck at 80% weight
# utilisation. Volume (680 cuft) is at 68% of 14T truck capacity (1000 cuft).
# Weight is the binding constraint. 18-tonne truck available but would
# result in only 62% utilisation — below target. 10-tonne truck insufficient
# by 1.2 MT. Selected 14T as optimal fit."
# }Bedrock Guardrails: Logistics Safety
{
"name": "logystix-operations-guardrail",
"description": "Ensure safe and valid logistics decisions",
"topicPolicyConfig": {
"topicsConfig": [
{
"name": "overload-recommendation",
"definition": "Recommending truck loads that exceed the vehicle's rated weight or volume capacity",
"type": "DENY"
},
{
"name": "safety-bypass",
"definition": "Suggesting dispatch decisions that bypass mandatory safety checks or driver rest requirements",
"type": "DENY"
}
]
},
"contentPolicyConfig": {
"filtersConfig": [
{"type": "MISCONDUCT", "inputStrength": "HIGH", "outputStrength": "HIGH"}
]
}
}Real Numbers: 12 Weeks of Production Data (Mid-March – Early June 2026)
The system went live in mid-March 2026. Here are the results from 12 weeks of production operation:
| Metric | Before (Baseline: Jan-Feb 2026) | After (Mar-Jun 2026) | Change |
|---|---|---|---|
| Average truck utilisation | 52-58% | 72-79% | +20 percentage points |
| Logistics cost per delivery | Baseline indexed at 100 | 76 | -24% |
| Daily orders processed | 30+ (with 4 planners at capacity) | 36-40 (same 4 planners, with AI handling planning) | +20-25% throughput, zero additional headcount |
| Time spent on dispatch planning | 3-4 hours/day (team of 4) | 40-50 minutes/day (1 planner reviewing AI recommendations) | -78% |
| Customer escalation calls ("where is my delivery?") | 15-20/day | 9-11/day | -42% |
| Proactive delay notifications sent | 0 (no system existed) | Average 5-7/day (sent before customer calls) | New capability |
| Average ETA accuracy (predicted vs actual arrival) | N/A (no prediction) | 82% within ±30 minutes | New capability |
| Orders consolidated (that would have shipped separately) | ~5% (manual, when obvious) | ~28% of daily orders benefit from AI consolidation | +23 percentage points |
Cost Profile (Monthly)
| Component | Monthly Cost |
|---|---|
| Amazon Bedrock (Nova inference — orchestrator + specialist agents) | ₹0.9 lakh/month ($1,080) |
| Amazon RDS (orders, trucks, GPS data) | ₹0.4 lakh/month ($480) |
| Lambda (agent execution + API integrations) | ₹0.2 lakh/month ($240) |
| Google Maps API (ETA calculations — ~3,000 calls/day) | ₹0.5 lakh/month ($600) |
| WhatsApp Business API (notifications) | ₹0.1 lakh/month ($120) |
| CloudWatch + SES + IAM | ₹0.2 lakh/month ($240) |
| Total monthly platform cost | ₹2.3 lakh/month ($2,760) |
ROI Calculation
- Logistics cost reduction: 24% reduction on a monthly logistics spend of approximately ₹18-20 lakh = ₹4.3-4.8 lakh/month saved
- Avoided festive-season hiring: 2-3 temporary planners not needed (₹1.5-2 lakh saved over festive quarter)
- Reduced escalation handling: 6-9 fewer calls/day × 15 min each = ~2 hours/day of operations team time recovered
- Platform cost: ₹2.3 lakh/month
- Net monthly savings: ~₹2-2.5 lakh/month in direct logistics cost reduction alone (after platform cost)
- Payback period: Implementation cost (₹20 lakh / $24K) recovered in approximately 7-8 months
What Broke: Three Failure Modes and How We Fixed Them
Failure 1: Order Grouping Agent Consolidating Incompatible Products
What happened: In Week 2, the Order Grouping Agent consolidated a shipment of cream biscuits (temperature-sensitive, requires covered transport) with a bulk shipment of glucose biscuits (ambient, open truck acceptable). The cream biscuits arrived at the distributor with packaging damage from heat exposure during transit.
Root cause: The grouping agent was optimising purely on destination proximity and weight/volume fit — it did not consider product handling requirements. The product constraint ("requires covered transport" vs "ambient OK") was stored in SAP material master data but was not being passed to the agent as context.
Fix: Added a product-constraint lookup to the Order Grouping Agent's pre-processing step. Before grouping, the agent now queries material handling requirements from RDS and applies a hard constraint: orders requiring different transport conditions (temperature, fragility, hazmat) are never consolidated into the same truck, regardless of destination fit.
After fix in Week 3: zero product-incompatibility incidents in the remaining 10 weeks. The constraint eliminated approximately 8% of potential consolidations — an acceptable trade-off for product safety.
Failure 2: GPS Agent Triggering False Delay Alerts During Highway Toll Stops
What happened: In the first three weeks, approximately 22% of "delay detected" notifications sent to customers were false alarms. The truck was not actually delayed — it was stopped at a highway toll plaza for 15-25 minutes, which the GPS agent interpreted as an unexpected stop indicating a delay.
Root cause: The ETA monitoring agent used a simple heuristic: "if truck is stationary for >10 minutes and not at a known delivery point, flag as potential delay." Highway toll plazas, fuel stops, and mandatory driver rest points were not in the agent's context as expected stop locations.
Fix: Built a "known stop points" reference layer in RDS — toll plazas, fuel stations, and designated rest stops along all active routes. The GPS agent now checks whether a stationary truck is at a known stop point before classifying as delayed. Additionally, increased the stationary threshold from 10 minutes to 20 minutes for locations within 2km of a known stop point.
After fix in Week 4: false delay notifications dropped from 22% to 8%. The remaining 8% are genuine edge cases (unexpected stops not in the reference database) — acceptable and self-correcting as new stop points are added.
Failure 3: Truck Selection Agent Recommending Unavailable Vehicles
What happened: In Week 3-4, approximately 15% of truck selection recommendations referenced trucks that were not actually available — they were already dispatched, under maintenance, or committed to another route. The logistics manager had to override and manually select a truck.
Root cause: The truck fleet availability data in RDS was updated by the operations team manually — typically with a 1-2 hour lag. The Truck Selection Agent queried "available trucks" and received stale data showing trucks as available when they had already been dispatched 30-90 minutes earlier.
Fix: Implemented a real-time fleet status sync: when a dispatch is confirmed, the truck status in RDS is updated immediately (within the same Lambda execution that confirms the dispatch). Added a "last_status_update" timestamp to the fleet table, and the Truck Selection Agent now filters out any truck whose status was updated more than 30 minutes ago without reconfirmation — treating stale-status trucks as "availability uncertain" and excluding them from automatic selection.
After fix in Week 5: unavailable-truck recommendations dropped from 15% to 4%. The remaining cases occur when two dispatch cycles happen within minutes of each other (race condition) — resolved by the logistics manager's approval step.
Agent Reasoning in Action: Why This Is Not Route Optimisation
The distinction between this system and traditional logistics software is that these agents make judgment calls, not just calculations.
Examples of reasoning in production:
- Three orders to the same city: two are standard (2-day window) and one is urgent (same-day). Total weight: 14 MT. Available trucks: one 18T (leaves now) and one 10T (available in 3 hours). → The orchestrator decides: dispatch the urgent order immediately on a hired 10T truck (58% utilisation — below target but necessary for the SLA), and hold the two standard orders for consolidation with tomorrow's orders to the same region. Logs reasoning: "Splitting delivers the urgent order within SLA while avoiding an 18T truck at 78% utilisation that would leave the two standard orders without a vehicle for their window."
- An order group weighs 9.8 MT. Available trucks: 10T and 14T. → The agent selects the 10T truck at 98% weight utilisation, but checks volume: if volume exceeds 85% of the 10T's capacity, it escalates to the 14T. Reasoning is logged either way.
- GPS shows a truck stopped for 45 minutes, 12km from destination, not at a known stop point. → The ETA agent reclassifies from "minor delay" to "delayed," sends WhatsApp notification to the customer with updated ETA, and logs: "Vehicle stationary for 45 min, not at toll/fuel/rest point. Likely traffic blockage or breakdown. Updated ETA from 2:30 PM to 3:45 PM based on historical recovery time for this route segment."
A Presales Perspective: Why Logistics Is the Highest-ROI Agentic AI Use Case in FMCG
Why This Conversation Wins Every Time
In my presales engagements with FMCG manufacturers, the logistics conversation has the fastest path to executive buy-in of any AI use case — for one simple reason: logistics cost is a P&L line item that every CFO monitors monthly.
When I show a CFO that their logistics cost per delivery can drop by 20-25% through better truck utilisation and order consolidation — at a platform cost of ₹2.3 lakh/month — the ROI conversation is over in one slide. The payback period (7-8 months) is shorter than most enterprise software procurement cycles.
The Opening Question
"What percentage of your trucks leave your plant at less than 70% capacity? And how many orders per week ship to the same region on different trucks because nobody had time to consolidate them?"
Every FMCG logistics head knows these numbers are bad. They just have not had a solution that fits their timeline and budget. The 10-week deployment timeline is what makes this actionable — it is not a 6-month TMS implementation.
The Demonstration That Shifts the Conversation
Show the truck selection agent's reasoning log: "Selected 14-tonne truck because total weight is 11.2 MT and volume is 680 cubic feet. 18-tonne truck available but would result in only 62% utilisation." When the operations head sees the AI making the same judgment calls their best planner makes — but for every single order, every single day, without fatigue or oversight — they understand this is not automation. It is an intelligent planning partner.
The Objection You Will Hear
"Our logistics is too complex for AI — too many variables, too many exceptions."
Response: "That complexity is exactly why rule-based systems fail and why you are still doing this manually. Agentic AI reasons about complexity — that is its core capability. The more variables and trade-offs involved, the more value AI adds over spreadsheets. The simpler the problem, the less you need AI."
Lessons for Technology Leaders
- Logistics cost is a P&L line item — which makes AI ROI immediately visible — Unlike AI use cases buried in productivity metrics or qualitative improvements, logistics cost reduction shows up in the next month's financial statements. This makes the business case trivially easy to prove and fund.
- Agentic AI reasoning logs are an operational asset, not a debugging tool — The truck selection reasoning ("why this truck, not that one") became the operations team's primary planning review artifact. They stopped reviewing dispatches one-by-one and started reviewing the AI's reasoning for exceptions only. The logs are the operations intelligence layer.
- Start with the "boring" planning work, not the "exciting" prediction work — Order grouping and truck selection are not glamorous AI use cases. But they consume 3-4 hours of planning time daily and directly impact the largest logistics cost driver (utilisation). Solve the boring problem first; it funds the exciting problems.
- Real-time monitoring agents are only as good as their context — The GPS agent's false alarm problem (22% false positives) was entirely a context problem, not a reasoning problem. The agent's logic was correct; its knowledge of the world (toll plazas, fuel stops) was incomplete. In agentic systems, context quality determines output quality.
- Human-in-the-loop is not a limitation — it is a trust-building strategy — The logistics manager's approval step was initially a safety net. After 6 weeks of consistent AI quality, it evolved into a 2-minute review rather than a 3-hour planning session. Trust is earned incrementally — design for it.
Reusable Artifact: Agentic Logistics Planning Deployment Playbook
Based on this engagement, we developed a reusable 10-week framework for FMCG logistics automation:
Week 1-2: Order data audit + fleet data normalisation + RDS schema design
Week 3-4: Orchestrator agent + Order Grouping Agent development
Week 4-5: Truck Selection Agent + utilisation logic + reasoning templates
Week 5-6: GPS integration + ETA monitoring agent + Maps API configuration
Week 7-8: Notification system (WhatsApp + SES) + escalation logic
Week 8-9: Integration testing with live orders + known-stop-points database
Week 9-10: Production deployment + operations team training + false-positive tuning
Week 11+: Continuous improvement — route learning, seasonal pattern adaptation
Applicable to: Any FMCG, CPG, or distribution company with daily multi-order dispatches and a fleet of mixed-capacity vehicles. Particularly effective for companies where manual planning is the bottleneck to scaling order volume.
AWS services required: Bedrock AgentCore (Nova), Amazon RDS, Lambda, CloudWatch, SES, Bedrock Guardrails, IAM. External: Google Maps API, WhatsApp Business API.
Conclusion
This engagement proved that agentic AI is not limited to knowledge work and document processing — it is equally powerful for physical-world logistics planning where decisions have immediate, measurable financial impact.
The 24% logistics cost reduction was not achieved by optimising routes (the traditional TMS approach). It was achieved by giving the operations team an AI planning partner that reasons about order consolidation, truck selection, and delivery trade-offs — the judgment-intensive work that spreadsheets and rules cannot automate.
The most telling metric is not the cost reduction — it is the throughput change: 30+ orders/day with 4 planners at capacity → 36-40 orders/day with the same 4 planners spending 40-50 minutes reviewing AI recommendations instead of 3-4 hours building plans from scratch. The organisation scaled its logistics capacity by 20-25% without hiring a single additional person. That is the operational leverage of agentic AI.
About the Author
Rajat Jindal is VP – Presales at AeonX Digital Technology Limited, where he architects winning cloud strategies for enterprise customers and translates modernization into measurable business value. He is a strong advocate of AWS, committed to sharing thought leadership that helps technology leaders make faster, better-informed decisions.