Experiencias Xcaret Xseil - Pre Agentic logistic intelligence before AI mainstream - By Tegrity.AI

Tegrity.AI - The Integral Management Society SAS is a development center with more than 20 years of experience in complex systems intelligence and operational AI integrity. Formed by former Nokia engineers who had previously worked with Pemex on logistics digitalization, the team accepted the xSeil challenge and developed the platform entirely from Mexico.

Experiencias Xcaret is the largest integrated tourism operator in Latin America, managing a dense regional ecosystem of seven theme parks and roughly 500 hotels, the organization faced a logistical challenge that surpassed standard industry models at the time.

1. The Problem: "Blind" Committed Demand

Unlike traditional logistics where orders can be rejected or windows renegotiated, xSeil operated under a Fully Committed Demand model with Zero Flexibility.

• Blind Commitments: Distributed resellers could commit services independently with no pre-sale capacity checks or system awareness.

• Locked SLAs: Every ticket defined a fixed pickup time and location at the moment of sale—non-negotiable and unadjustable.

• Hard Constraints: The system enforced strict feasibility conditions, including fixed arrival commitments and no standing passengers, eliminating any tolerance for capacity overflow or schedule deviation.

• Large Scale: The system handled 12,000 daily passengers. For each assignment, the engine evaluated approximately 60 million feasible configurations, knowing that a single change could trigger a cascade of disruptions across the entire network.

• High Propagation Effects: Local changes (e.g., marginal demand variations) could propagate across the network, forcing reallocation of vehicles and reconfiguration of multiple routes due to tight resource coupling between assignments.

• Collusive Objectives: Planning objectives were inherently conflicting (e.g., shorter trips vs fuel consumption, punctuality vs policy-compliant vehicle allocation). Multiple trade-offs had to be resolved simultaneously under continuously evolving operational priorities.

  
  

2. General Architecture: A Logistics Operating System

xSeil was architected not as a narrow VRP (Vehicle Routing Problem) tool, but as a full logistics operating platform designed to control the entire operational lifecycle.

• End-to-End Logistics Platform: The system extended beyond routing to include fleet availability management (workshop / preceptoría for maintenance and unit readiness), rental estimation and management with third-party providers, planning and optimization, real-time control, dynamic adjustment, and managerial decision support, ensuring that capacity, availability, and execution constraints were managed at source.

  
  

• Core Operational Modules: The platform was structured around operational modules including schedule optimization, catalog and master data management, planning engine, reassignment management, time estimation, real-time control (Control Logístico), passengers effectively transported, dynamic route sheet, transfer center coordination, “copiloto” (cruise speed control), and managerial decision support, covering the full transport lifecycle from planning to execution and control.

  
  

• Data Foundation & Middleware Layer: A dedicated data normalization and integration layer (middleware / ETL) was required to clean, validate, and reconcile fragmented inputs from SOX, GPS (GeoTab), and operational sources, transforming inconsistent data into reliable planning inputs.

  
  

• Full-Stack Intelligence: Built on a Linux / Python 3 / PostgreSQL stack, the platform combined backend planning engines, integration services, and mobile execution layers, enabling both centralized decision-making and distributed field execution. Redis Cache, C

  
  

• Closed-Loop Control: Through GeoTab telemetry and mobile interfaces, xSeil established a real-time feedback loop between planned routes and actual execution, allowing continuous validation, adjustment, and operational control.

As a result, xSeil was able to operate with a complete and coherent data model, ensuring that planning decisions were based on actual fleet readiness, demand conditions, and real-time operational feedback.

3. Managing the Routing Complexity: A Pre-Agentic, Stability-Driven Approach

To handle the NP-complex nature of the problem, xSeil did not attempt to “solve” the system in a classical optimization sense. Instead, it confronted the complexity through a structured, modular, and pre-agentic intelligence approach, where each passenger behaved as an autonomous decision unit competing or collaborating for scarce operational resources.

• Pre-Agentic Allocation Model (Competition & Cooperation): Pre-Agentic Allocation Model (Competition & Cooperation): Each passenger assignment can be interpreted, retrospectively, as an implicit decision unit competing for limited resources (capacity, punctuality, route quality, vehicle type). This was not implemented as a true multi-agent system; planning was fully centralized, and these behaviors emerged from the allocation logic.At the same time, compatible passengers were grouped through collaborative aggregation, enabling joint optimization and reducing internal competition. This effectively transformed the problem into a centralized resource allocation system with agent-like dynamics, where cooperation reduced complexity and competition defined trade-offs.

  
  

• Dynamic Utility & Internal Pricing: Instead of fixed weights, the system used non-linear utility curves to represent objectives (fuel, stops, punctuality, transfers, vehicle policy). These were translated into a form of internal pricing mechanism, where each objective had a dynamic marginal cost depending on system state. For example, if delays accumulated, the “price” of punctuality increased, forcing the system to deprioritize other objectives such as fuel efficiency or route simplicity in order to protect SLA commitments.

  
  

• Satisficing (The "Good Enough" Logic): The system did not chase a theoretical global optimum, which was computationally infeasible under live conditions. Instead, it used a Global Utility metric to determine when a solution was “good enough” to execute. This allowed the system to stop the search once a safe, high-utility threshold was reached, balancing solution quality with time and computational constraints.

  
  

• Fragility as a Capacity Signal: The system incorporated fragility as a safety mechanism, defined as: Fragility=Probability of Anomalies×Propagation Probability\text{Fragility} = \text{Probability of Anomalies} \times \text{Propagation Probability}Fragility=Probability of Anomalies×Propagation Probability When fragility increased, the system shifted behavior from optimization to protection, introducing operational slack (e.g., renting additional units, adding buffers, reducing coupling). Capacity management was therefore not an optimization outcome, but a precondition for safe operation.

  
  

• Stability Partitioning (Low-Propagation Clustering): Rather than solving the full network at once, the system organized agents into cooperative groups, and then into low-propagation clusters — subproblems whose local decisions were unlikely to destabilize the rest of the network. The system then resolved these clusters sequentially, starting with the most stable or least coupled, effectively locking useful structures early and reducing the active search space step by step.

  
  

• Dynamic Heuristics & Decision Memory: The system used decision memory to store and reuse previously evaluated trip patterns, cluster configurations, and allocation structures. This converted part of the process from blind combinatorial exploration into informed retrieval plus local adjustment, significantly improving speed and practical tractability under real-time conditions. 

  
  

Why this is Relevant in 2026: Closing Perspective

While the stack was designed a decade ago, the underlying engineering principles remain highly relevant in current large-scale operational systems:

• Resilience over Efficiency: In increasingly volatile environments, xSeil prioritized antifragility and risk-driven capacity management, using fragility signals to introduce slack and protect feasibility. This aligns with current approaches in mission-critical systems where maintaining operational continuity outweighs marginal efficiency gains.

  
  

• Contextual Decision Logic (Beyond Static AI): Rather than relying on fixed reward functions, xSeil implemented dynamic marginal pricing of objectives, allowing priorities to shift based on system state. This anticipates current approaches in advanced multi-agent and adaptive systems, where trade-offs are resolved contextually rather than through static weighting.

  
  

• Operational Stability as a Scaling Strategy: The use of stability partitioning (low-propagation clustering) demonstrates a practical way to scale complex optimization problems without relying on brute-force computation. It highlights that structural decomposition and execution-aware heuristics remain competitive with, and often preferable to, purely compute-driven approaches.

More info on http://tegrity.AI   info@tegrity.AI