iGent Concert
/podium/architecture/

Podium Architecture

Gateway, coordinator, and agent process architecture

Podium separates external runtime access from host-local process management.

Component Layout

podium/
├── gateway
│   ├── auth and request validation
│   ├── deployment upload/proxy paths
│   ├── coordinator discovery through Valkey
│   └── runtime routing
├── coordinator
│   ├── deployment cache
│   ├── instance directories
│   ├── process supervision
│   ├── agent IPC
│   └── optional Chronicle workspace integration
└── SDKs and agent shims
    ├── TypeScript runtime helpers
    └── Python runtime helpers

Request Flow

1. Diminuendo or an operator calls the Podium gateway. 2. The gateway authenticates the request and selects a coordinator. 3. The coordinator ensures the deployment bundle is present. 4. The coordinator creates or locates the instance directory. 5. The coordinator starts the agent process and opens local IPC. 6. Runtime events are streamed back through the gateway.

Service Discovery

Coordinators register in Valkey with load and health metadata. The gateway uses that registry to place new instances and route existing ones.

For single-host local-runtime development, the root PM2 stack can start both podium-gw and podium-coord when FABRIC_PODIUM_MODE=local. Managed dev uses the company-wide staging Podium gateway instead.

Workspace Integration

Chronicle is optional. When enabled, it provides the workspace authority for versioned file access and sync. Podium should treat Chronicle as the workspace implementation rather than embedding a second file-versioning model.