Forge Runtime: remove CLI chaos, keep shipping speed.

Hard truth: multi-CLI setups are powerful but hard to follow. The product direction is a dedicated runtime layer that standardizes execution, auth, MCP, and observability for every agent.

Runtime blueprint

Forge Runtime Container: one image with all 3 CLIs + wrapper command surface
Built-in MCP wiring and capability registry
Git auth bootstrap (GitHub + self-hosted GitLab)
Unified run id, logs, and policy events across all agents
Remote execution mode for always-on worker pools

> primary UX target: forge run <agent> <task> --mode {pro|madmax|insane}

GitHub / GitLab workers (job-triggered)

Pros

Great audit trail and change history alignment
Lower idle cost when workload is bursty
Simple approvals + branch protections

Tradeoffs

Cold starts and queue latency
Harder long-running interactive sessions
Auth/session setup repeated per run

Best fit: Best for teams with predictable CI flow and moderate interactivity.

Always-on runtime machine / cluster

Pros

No bootup delay, instant execution
Persistent auth/session/tool caches
Ideal for MCP-heavy and interactive agent loops

Tradeoffs

Higher baseline infra cost
Needs stronger isolation and watchdog controls
Operational overhead for uptime and patching

Best fit: Best for high-frequency usage and agent-first workflows.

Recommended direction (for now)

Use a hybrid model: always-on runtime for high-frequency interactive work + GitHub/GitLab triggers for compliance-heavy PR and release workflows. That gives instant agent response without losing governance.

DISCUSS FORGE RUNTIME ← BACK TO PRODUCTS