xSeil agentic features

Pre-Agentic Orchestration: Closed-Loop Logistics Control Before the Agent Era — Tegrity.AI Group
Deployed-Systems Retrospectives · Paper II

Pre-Agentic Orchestration: Closed-Loop Logistics Control Before the Agent Era

Draft v0.4 — PRIVATE working draft. “Pre-agentic” and all concept mappings are retrospective interpretations, labelled as such throughout.

Changes in v0.4 (additive except one correction): the simulation-twin claim in §4 is corrected per the claim-status ledger of the Quantum Companion Paper (v2); new §5a supplies empirical anchors from operational artifacts recovered in 2026; a repository-provenance note (§8a) records the two surviving snapshots and the divergences of the 2023 port; references now carry explicit public URLs, including the GEPLAN case that anchors the §1 lineage note.

Series: Deployed-Systems Retrospectives, Paper II. Target: arXiv cs.MA, cross-list cs.AI. Companion: Paper I (architecture), Paper III (quantum formulations).

Abstract

Before agent frameworks became mainstream, deployed mission-critical systems implemented centralized equivalents of behaviours now attributed to multi-agent architectures. We document three such mechanisms in xSeil (2016–2017): a pacing daemon computing a multiplicative saturation index over destination pressure and issuing physical speed commands to vehicles through iterative marginal load-shifting; a scenario system with a full simulation twin evaluating counterfactual plans against a shared persistent configuration library; and an evidence-gated escalation ladder that widens search scope only on demonstrated insufficiency. We show that the daemon’s saturation index is structurally identical to the fragility measure F = P(anomalies) × P(propagation) formalized by the same group a decade later, map each mechanism to its modern agentic counterpart as explicit retrospective interpretation, and specify a benchmark protocol for the open empirical question of what decentralization buys — and costs — against a centralized baseline possessing global visibility and deterministic auditability.

A companion Technical Code Annex supplies the verbatim production code behind every claim below — the control-loop state machine, the geofence→delay→forward-propagation sensor, and the saturation-index→speed-command actuator — so the closed loop and the fragility identity are auditable, not narrated.

1. The orchestration problem

Planning (Paper I) produces route sheets; orchestration keeps the physical day executing them. Three sub-problems: pacing (vehicles must not saturate destination docking capacity), absorption (ad-hoc demand changes must be inserted without re-planning the day), and regime response (when local repair is insufficient, the system must escalate rather than thrash). All three were solved centrally, synchronously, against a shared database — the architecture that agent frameworks would later decompose.

A lineage note. The centralized model was not improvised in 2016; it descended from the same group’s GEPLAN deployment (2006–2010, PEMEX/Chicontepec), which coordinated hydrocarbon logistics through four integrated control centres operating one shared platform, treated incident management as the core function («disruptions were not exceptional — they were expected»), managed trade-offs (maintenance versus continuity, efficiency versus risk) centrally and dynamically, and enforced an explicit human-in-the-loop doctrine: the system aggregated, prioritized, and suggested; the operator decided. xSeil’s daemon is that doctrine’s next step — the first place the group allowed the system itself to issue physical commands (speed directives), and only for the narrow, reversible, safety-bounded pacing decision. The progression 2006 → 2016 is thus a controlled expansion of machine authority: from decision support to bounded actuation, a decade before «human-in-the-loop» became standard vocabulary.

2. The pacing daemon

A persistent process aggregates all estimated arrivals by destination and time band, computes three indices per (band, destination) group, and intervenes when saturation crosses unity.

The three indices:

unit saturation:      I_u = units_in_band / max(docks, 1)
passenger saturation: I_p = pax_in_band / max(pax_capacity, 10)
band proximity:       I_f = normalized distance of estimated arrival
                            from the band midpoint (cheapness of shifting;
                            sign gives the natural shift direction)
composite:            I   = I_p × I_u × I_f

The intervention rule (verified against the production routine, and richer than a threshold check):

While any group has I_u > 1 or I_p > 1: select one unedited offending vehicle — the selection alternates between the head and the tail of the saturation-sorted list on successive iterations — shift its estimated arrival into the adjacent band indicated by the sign of its proximity index, mark it edited, recompute all indices, and repeat until saturation clears or no candidates remain. Then, and only then, commit the physical commands: each shifted vehicle receives INCREASE_SPEED or DECREASE_SPEED according to the direction of its shift.

Two properties deserve emphasis. First, this is iterative marginal relaxation with full re-evaluation — move one unit, re-price the whole board, move again — the same clear-one-reprice-repeat pattern as the allocation loop of Paper I §3.4, now operating at the control layer. The system has one temperament at every level. Second, the alternating head/tail selection is a cheap diversification device: successive corrections are taken from opposite ends of the severity ordering, avoiding pathological chains of adjacent shifts.

3. The fragility identity

The published field case (2026 formalization) defines fragility as F = P(anomalies) × P(propagation), with a doctrine switch from optimization to protection when F rises. The 2016 daemon computes I = I_p × I_u × I_f — a product of pressure terms with intervention masked on components exceeding unity.

The structural identity is exact: both are multiplicative composites of independent pressure factors; both use a unit threshold as the regime boundary; both respond not by optimizing harder but by relieving pressure (shifting load, adding slack). The daemon is the fragility switch, running in production, ten years before its formalization. We claim structural identity as documented fact; we label the reading of the daemon as an «early warning system» a retrospective interpretation — the 2016 designers spoke of saturation, not regimes.

3.1 The closed loop, precisely

The field case describes a “real-time monitoring layer fusing GPS telemetry with mobile field execution, closing the loop between planned routes and actual movement, boarding, and punctuality.” The Technical Code Annex §2 shows this is literal: a geofence-entry event is matched to its planned stop, the real delay is computed against the promised time, and — the decisive line — the delta is propagated forward through every downstream stop, so the remaining plan re-estimates itself the instant reality diverges. The controller runs on a fixed five-minute frame (FRANJA_ASISTENTE_VIAJE) over a Linux/Python 3/Django/PostgreSQL/Redis stack serving ~250 concurrent users — sensing (geofences + boarding ingest), deciding (saturation index), and actuating (speed cues) once per frame. This is a control loop in the engineering sense, not a scheduler with alerts.

4. The scenario system and the simulation twin

Every planning object is scenario-scoped. A simulation twin — a near-duplicate of the planner gated by a simulation flag — evaluates counterfactual plans against the same persistent library, writing to scenario-scoped materialized candidate sets. Consequences — with one correction adopted from the companion claim ledger: (i) the production planner accepts a simulation flag and writes simulation-scoped objects, so flag-gated what-if runs share the production code path; however, a separate simulation-oriented implementation also exists in the repository and shows material drift (imports, fleet estimation, CT planning, rental estimation, post-processing), so the earlier claim that all simulation used an identical code path is withdrawn — any twin-based oracle must state which of the two paths it uses and validate equivalence; (ii) scenario libraries accumulate — largely during idle machine time — into an ever-larger store of pre-evaluated configurations (the decision-memory doctrine); (iii) the twin provides a native instrumented oracle for perturbation studies: inject a demand change, run the twin, observe whether the repair regime triggers. Companion Paper III builds its rare-event estimation formulation (Q-B) directly on this oracle.

5. The escalation ladder

When a band’s normal candidate set proves insufficient, the planner widens its search one bounded page at a time («advanced-search» mode), capped by configuration. Scope widens only on evidence of insufficiency and never unboundedly. Retrospectively — labelled as such — this is the operational ancestor of the semantic window later formalized by the group: context width as a governed variable, adjusted on evidence, with a cap. The native instrumentation matters empirically: rollback frequency and escalation depth per band are logged, giving any future study a measurable regime-event stream at zero instrumentation cost.

5a. Empirical anchors recovered in 2026

Operational artifacts recovered in 2026 give the three orchestration sub-problems of §1 measured magnitudes rather than narrative ones. All figures below are class-O (operational artifact) unless marked T (participant testimony).

Absorption has a measured rate. Per-reservation exports from the legacy system of record (SOX) survive for two complete service days, 4 and 6 July 2017 (3,328 and 3,605 reservations; 10,679 and 11,954 booked passengers). Capture dates show that 7–10% of reservations were created on the service day itself (326 and 270 reservations respectively). That is the empirical workload of the absorption loop — the ad-hoc insertions the library-lookup mechanism had to place without re-planning the day.

The evening plan was provably an estimate. The same booking curve shows 31–37% of final demand captured two or more days before service and 56–59% on the day before. Because capture resolution is date-level, the fraction visible at the 18:00 planning cut is bounded between 31–37% and 90–93%, not measured exactly. Either bound makes the point: the orchestration layer existed because the plan it executed was built on partial information by construction.

Orchestration outputs were recovered, not just orchestration code. Executed field route sheets survive for 1–8 August 2017 (Cancún and Riviera Maya operations). They show single routes carrying passengers for up to seven destination codes simultaneously (multi-destination coalitions in execution) and unit labels of the form BUS 100-1 / BUS 100-2 — the same physical unit performing sequential trips. Multi-trip reuse and coalition service, previously code-established capabilities, are now observed in field artifacts. Recovered sheets total ≈6,100–9,000 pickup passengers per day across the three recovered operation families (pickup direction only; not the complete daily operation; one day contains near-duplicate sheet versions requiring deduplication).

Scale decomposes by planning instance. Planning executed per geographic operation (Cancún, the Riviera Maya operations, Xenses) and per time slot (morning, afternoon); a daily total is the sum over instances. The recovered booked totals directly match the published ~12,000-passenger order of magnitude. The daily scale was around 10,000 passengers per day in high season, approximately 12,000 on busy days, and occasional peaks of 15,000–17,000; the Cancún morning instance alone could reach 10,000–12,000 on a peak day.

Gap declared. Recovered demand days (July) and recovered executed days (August) do not overlap; no matched demand-to-plan instance exists yet. Recovering one SOX export for any day in 1–8 August 2017 creates the first complete replay instance for the Annex B4 protocol. The SOX exports contain personal data (guest surnames, room numbers, confirmation codes); anonymization is mandatory before any circulation.

6. Retrospective mapping to multi-agent architectures

All mappings in this section are retrospective interpretations.

xSeil mechanism (1 process, 1 DB) Modern agentic counterpart
Pacing daemon polling + shifting Destination-station agents auctioning arrival slots; vehicle agents negotiating (Contract-Net)
Ad-hoc insertion via library lookup Passenger-group agents issuing calls-for-proposals; vehicles bidding marginal detour cost
Simulation twin Agent world-model / rollout evaluation
Escalation ladder Meta-controller widening task scope on failure
Fragility switch Guardian/governor agent vetoing optimization under stress

A Contract-Net reference design is specified in Annex B3. We do not claim the MAS version is better; we claim the trade is open (§7).

7. What centralization bought — and the open benchmark

The centralized design possessed, natively: global visibility (every index computed over the whole board), determinism (identical inputs, identical commands — auditable after any incident), and single-writer consistency (no negotiation protocol, no distributed-state reconciliation). A MAS must pay engineering cost to recover each. What a MAS promises in exchange: elimination of polling latency, horizontal scalability, and locality of failure. The claims in the source literature of this paper’s earlier internal draft — asymptotic superiority of negotiation over polling — are not derived here and are withdrawn; the net effect is an empirical question. Annex B4 specifies the protocol; until it is executed, no verdict is asserted.

8. Limitations

Single system; originating-group retrospective; the MAS comparison is design-level; the retrospective labels are interpretations of a system whose designers used different vocabulary. The fragility identity is structural, not intentional — no design document from 2016 states the F formula; the code does.

8a. Repository provenance

Two archives of the production repository survive. Snapshot A (21 April 2018; 601 files; SHA-256 77bc819a…586ce786) is the production-era snapshot and the sole anchor for every code claim here and in the Technical Code Annex. Snapshot B (28 January 2023; 671 files; SHA-256 c2de31a8…54edd2) is a later third-party containerization of Snapshot A. The orchestration modules cited in this paper (the pacing daemon, the planner retry/escalation machinery, the simulation paths) are byte-identical across both snapshots. The port nevertheless introduces at least three semantic divergences, two of which sit squarely in the orchestration layer: an exception-propagation change (raise replaced by logging) that silently alters failure and retry semantics — precisely the regime machinery of Annex B2 — and a rewritten transfer-admissibility inequality that changes which hotel–transfer–destination triples are generated. A third is a mechanical rename defect that breaks the concurrency computation at runtime. Consequence: Snapshot B must never be executed as historical evidence or as the replay baseline; its divergences are, however, natural candidates for the semantic-repair arm of the replay programme.

Annexes

Annex B1 — Pacing daemon (disclosure level L1: faithful pseudocode)

def pacing_daemon_tick(date):
    board = arrivals_by_route(date)     # est. arrival, unit, pax, destination,
                                        # docks_max, pax_max — one row per sheet
    for v in board: v.speed, v.edited = HOLD, False
    pick_head = True                    # alternating selection device

    while True:
        assign_bands(board)                                  # band, order
        g = board.groupby([band, destination])
        board.units_in_band = g.count(); board.pax_in_band = g.sum(pax)
        board.dock_slot     = g.cumcount_by_arrival() + 1

        mid = (band_start + band_end) / 2                    # per row, seconds
        board.direction = sign(arrival − mid)                # which neighbor band
        board.I_f = normalized_distance_from_midpoint(arrival, band)
        board.I_u = units_in_band / max(docks_max, 1)
        board.I_p = pax_in_band  / max(pax_max, 10)
        board.I   = board.I_p * board.I_u * board.I_f        # composite

        offenders = board[(I_u > 1) | (I_p > 1)][~edited] \
                        .sort_values([band_order, I])
        if offenders.empty: break

        v = offenders.head if pick_head else offenders.tail  # alternate ends
        pick_head = not pick_head

        if v.direction > 0:   # past midpoint → yield: slip to next band
            v.arrival = next_band(v).start;      v.speed = SLOW_DOWN
        else:                 # before midpoint → advance: catch previous band
            v.arrival = prev_band(v).end − 1min; v.speed = SPEED_UP
        v.edited = True
        # loop: full re-evaluation of every index after each single move

    for v in board[edited]:                                  # commit phase
        route_sheet(v).status = (INCREASE_SPEED if v.speed == SPEED_UP
                                 else DECREASE_SPEED)
        persist(v)

Interface (L0): input — live estimated arrivals with destination capacities; output — per-vehicle speed directives; guarantees — terminates (each move marks a vehicle edited; finite vehicles), never overfills a destination it can relieve, commands committed only after the board clears or exhausts.

Verbatim evidence (L2; client permission on record) — the composite index and the command commit, quoted from apps/xlogistics/daemon.py:

# ~288–298: the three pressure indices and their product
track["indice_saturacion_unidades"]  = track.num_unidades / track.andenes_max
...
track["indice_saturacion_pasajeros"] = track.pax_franja / track.pax_max
track["indice"] = (track["indice_saturacion_pasajeros"]
                   * track["indice_saturacion_unidades"]
                   * track["indice_franja"])

# ~307: the regime boundary — intervene only past unity
mask_saturacion = (track.indice_saturacion_unidades > 1) | (track.indice_saturacion_pasajeros > 1)

# ~336–345: the commit phase — physical commands, only after the board settles
for row in track.loc[track.edited == True].itertuples():
    hoja = HojaRuta.objects.get(pk=row.id_hruta_id)
    if row.velocidad == up_speed:
        hoja.status_hruta = INCREMENTAR_VELOCIDAD
    else:
        hoja.status_hruta = DISMINUIR_VELOCIDAD
    hoja.save()

Reading: the multiplicative pressure composite with a unit threshold — the structural twin of the published fragility formula (§3) — and the two-phase discipline: deliberate on the whole board first, actuate second.

Annex B2 — Regime machinery and native instrumentation (L1)

# Exception vocabulary = the regime-change machinery
class Rollback(Exception):          "constraint broke: undo band, re-plan"
class RangeOutOfOperation(Exception): "outside operating envelope"
class MoveToNearerBand(Exception):  "reassign candidate to adjacent band"

RETRY = 0
while status == RETRY:              # band-level repair-and-retry regime
    demand = refetch(band)          # world may have changed
    status = plan_band(band, demand)

# Evidence-gated escalation (semantic-window ancestor):
for page in range(MAX_ESCALATION):  # page 0: normal; page 1+: widened search
    C = fetch_candidates(band, page)
    if C: break

# Native instrumentation (log-derivable regime-event stream):
#   rollback_count[band], escalation_depth[band], daemon_moves[tick]

These three counters constitute a free, production-grade cascade proxy: any perturbation study (Paper III, Q-B) can define its marked event as «rollback triggered» or «escalation depth ≥ d» with zero added instrumentation.

Annex B3 — Contract-Net reference design (L0)

Roles: Destination-Station Agent (owns docks; publishes slot inventory per band), Vehicle Agent (owns trajectory; bids arrival-shift cost), Passenger-Group Agent (owns an ad-hoc group; issues call-for-proposals with window and size). Message schema: CFP(window, size, stop) → BID(detour_cost, arrival) → AWARD/REJECT; slot market: OFFER(band, slots) → CLAIM(vehicle, shift_cost) → GRANT. Governor agent retains the fragility veto: when the composite pressure of any destination exceeds unity, optimization messages are suspended and only pressure-relieving trades are granted — the centralized doctrine, preserved under decentralization.

Annex B4 — Centralized-vs-MAS benchmark protocol (L0; no claims)

Instances: frozen replay of anonymized daily demand with injected perturbation families (arrival noise, dock outages, demand bursts). Arms: (a) the centralized daemon as specified in B1; (b) the CNP design of B3. Metrics: end-of-day SLA violations; p50/p99 command latency; message/DB-op volume; auditability (fraction of interventions reconstructible to a deterministic cause); failure containment (blast radius of a killed component); degradation slope (SLA violations vs injected pressure). Pre-registered analysis; no directional hypothesis asserted.

System of record: private repository (audit under NDA; provenance in §8a). Public sources as in Paper I, plus:

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *