Rather than exposing low-level robot interfaces directly to users or applications, Vega manages the complete execution lifecycle of a task—from receiving an intent, through Capability execution, to maintaining execution state and recovering from interruptions.
This document introduces the high-level architecture of Vega and explains how its major components work together.
System Overview
At a high level, Vega consists of four layers.
Each layer has a different responsibility.
| Layer | Responsibility |
|---|---|
| Applications | Submit user requests or integrate Vega into external systems. |
| Vega Runtime | Interprets requests, manages execution, coordinates Capabilities, maintains state, and handles recovery. |
| Capability Layer | Provides modular functionality such as navigation, speech, perception, manipulation, or external service integrations. |
| VCP | A public communication protocol used between Vega, Capabilities, robots, and external systems. |
| Robots & External Systems | Physical robots, ROS 2 nodes, sensors, cloud services, databases, and third-party APIs. |
The Runtime remains proprietary, while the SDK, VCP specification, and Capability framework are open for extension.
Request Lifecycle
Every task executed by Vega follows the same high-level lifecycle.
Unlike simple request-response systems, robot tasks may continue for seconds, minutes, or even hours.
Throughout execution, Vega continuously tracks:
- Task State
- Execution Progress
- Capability Status
- Execution Results
- Failure Conditions
- Recovery Checkpoints
This allows long-running work to remain consistent even when interruptions occur.
Capability Architecture
Capabilities are the primary extension mechanism of Vega.
Each Capability implements a specific piece of robot functionality while remaining independent from the Runtime implementation.
Each Capability declares:
- Supported Functionality
- Required Inputs
- Produced Outputs
- Hardware Or Software Requirements
- Execution Limitations
The Runtime discovers compatible Capabilities and invokes them through public SDK interfaces rather than internal Runtime code.
This separation allows developers to build new integrations without modifying Vega itself.
Communication Architecture
Communication between Vega and external systems is performed through the Vega Capability Protocol (VCP).
VCP defines the public communication contract used between:
- Vega Runtime
- Capability Providers
- Robot Adapters
- External Services
- Future Distributed Systems
The protocol is transport-independent and is documented separately in the VCP Specification.
Execution State
Robot execution is inherently stateful.
Rather than treating every request as an isolated operation, Vega maintains execution state throughout the lifetime of a task.
A simplified execution lifecycle is shown below.
Created
│
Accepted
│
Running
│
CompletedWhen failures occur, additional transitions may happen.
Running
│
Failed
│
Recovering
│
RunningState persistence allows Vega to continue execution without restarting an entire workflow whenever recovery is possible.
Recovery Model
Real-world robots encounter interruptions that traditional request-response software does not.
Examples include:
- Process Crashes
- Robot Reboots
- Temporary Network Failures
- Unavailable Services
- Capability Failures
Rather than discarding execution state, Vega records sufficient runtime information to determine whether a task can safely resume.
Recovery behavior depends on the task, Capability contracts, and execution state.
Not every interrupted task is recoverable, but Vega provides a consistent framework for handling failures and continuing work whenever possible.