Auction Coordination Event-Driven Inventory Allocation Demand Fulfillment Adaptive Coordination

          Economic Coordination Explorer · Real-time decision system
        

Multi-agent coordination for auctions,
inventory, and fulfillment under demand uncertainty

Stefano Blando · phase-specific agents · real-time coordination

Project Focus

This explorer presents the project as an economic coordination system: procurement under auctions, inventory reconciliation, demand handling, bounded memory, and KPI replay.

System Animation

Stylized agent interaction loop

This animation shows the coordination cycle directly: demand arrives, policy is updated, procurement decisions are placed, inventory is reconciled, and fulfillment emits revenue and latency signals.

Live Workflow

Coordination Logic

Procurement

The auction phase acquires scarce inputs under budget constraints using recent market information and bounded memory.

Allocation

The reconciliation phase updates the feasible supply set, reallocates inventory, and liquidates low-value surplus before the next cycle.

Fulfillment

The execution phase serves queued demand under timing constraints while tracking conversion, latency, revenue, and operational failures.

Architecture

Control flow before prompting

The interesting part of this project is the orchestration substrate. The language model is only one component inside a guarded runtime that tracks state, dispatches the right phase agent, and routes actions through a limited capability surface. In economics language, this is closer to a coordination engine than to a chatbot.

Orchestration Graph

The graph summarizes the system logic: live events update the shared state ledger, phases are dispatched through a queue, specialized agents act within limited capabilities, and the whole cycle feeds persistence and replay metrics.

Phase Engine

Four prompts, four execution contracts

Each phase has a different failure surface, so the project uses distinct prompts, tools, and constraints rather than a single generic agent. This is also why the system maps cleanly to policy, procurement, reconciliation, and fulfillment.

Selected Phase

Memory

Sub-Agents

Capabilities

Prompt Policies

Prompt Focus

Execution Surface

This view is intentionally simple: the goal is to show how each phase owns a different capability set, not to force a fake benchmark.

Runtime Explorer

Illustrative trace, real control logic

The trace below is reconstructed from the system design and logging structure. It is meant to make the control flow legible: event transitions, decisions, warnings, and KPI emission across an auction-and-fulfillment cycle.

Trace Log

Turn-Level KPIs

KPI fields mirror the replay utility and `GameState` bookkeeping: clients, served dishes, revenue, bid spend, not-ready failures, and average serving latency.

Capability Surface

Which capabilities belong to which phase

One reason the project is readable is that the action surface is partitioned. The agents do not all get the same capabilities; each phase receives only what it needs for its economic role.

Phase × Capability Matrix