Agent Lifecycle
End-to-end flow from agent registration to final receipt — everything an operator or developer needs to understand about how an agent is deployed, executed, and audited on Gao Internet.
Overview#
Every agent on Gao AI OS follows a deterministic lifecycle with clearly defined phases, state transitions, and exit conditions. No agent can enter an execution phase without completing all preceding registration requirements.
REGISTER → CONFIGURE → ACTIVATE → [EXECUTE]* → RETIRE
│
RECEIPT EMITTED
---
### Phase 1: Agent Registration
An agent is registered by binding a **capability manifest** to a Gao Domain.
**Required inputs:**
- Gao Domain (must be owned by the registering entity)
- Agent identifier (unique within the domain)
- Agent type (template or custom)
- Capability manifest (actions, settlement ceiling, expiration)
- Risk tier declaration
**Outputs:**
- `agent_id` — unique, domain-scoped identifier
- Pending CAP token request
**Validation checks:**
- Domain ownership verified via L5
- Agent ID uniqueness confirmed
- Settlement ceiling ≤ domain policy maximum
- Expiration within allowed range
**State:** `REGISTERED`
---
### Phase 2: Capability Grant (CAP Token Issuance)
The domain owner **explicitly signs** a capability grant for the registered agent.
This is not automatic. CAP tokens require active human authorization regardless of agent type or risk tier.
Domain Owner Signs CAP Token
│
▼
GAR v1 validates CAP schema
│
▼
CAP stored in domain capability registry
│
▼
Agent moves to CONFIGURED state
**CAP token contains:**
- Agent ID and domain binding
- Permitted action types
- Settlement ceiling (per-execution or aggregate)
- Risk tier assignment
- Expiration timestamp
- Revocation flag (default: revocable)
**State:** `CONFIGURED`
---
### Phase 3: Activation
Activation opens the agent’s execution window. An activated agent can receive inputs and begin execution flows.
**Activation requires:**
- Valid, non-expired CAP token
- Domain in active state (L5)
- DePIN compute slot allocated (L7)
- Policy snapshot locked
**State:** `ACTIVE`
A domain owner can deactivate an agent at any time, which immediately prevents new execution windows from opening. In-flight executions complete their current window before terminating.
---
### Phase 4: Execution (Repeating)
Each execution is an **atomic, bounded unit** — one input, one execution window, one receipt.
#### Execution Window
Property
Behavior
**Start**
Triggered by input event
**End**
Output emitted OR timeout reached
**Maximum duration**
Defined in CAP token (default: 5 minutes)
**Concurrency**
Configurable; default: 1 concurrent execution per agent
#### Execution State Machine
IDLE ──input──▶️ POLICY_CHECK
│
pass───┤───fail──▶️ ABORT (failure receipt)
▼
CAP_VALIDATION
│
pass───┤───fail──▶️ ABORT (failure receipt)
▼
TIER_CHECK
│
tier≤1 ─────┤──── tier=2 ──▶️ AWAITING_CONFIRMATION
▼ │
EXECUTING ◀️──── confirmed ──────┘
│
tier=3? ────────────────────────▶️ AWAITING_HUMAN_AUTH
│ │
n/a ───┘◀️──── out-of-band auth ────────────┘
▼ │
EXECUTING ◀️────────────────────auth
│
complete┤──timeout──▶️ TIMEOUT (partial receipt)
▼
RECEIPT_EMITTING
│
success─┤──failure──▶️ RETRY (up to 3x)
▼
IDLE
#### Settlement During Execution
If an agent action requires value transfer:
1. Agent **proposes** a settlement request (amount, recipient, currency)
2. Settlement request is submitted to Gao Payment (L4)
3. If the amount is within the user’s pre-authorized settlement ceiling → auto-authorized
4. If above ceiling → execution pauses, domain owner is notified, human authorization required
5. User signs the transaction via their wallet
6. Settlement confirmed on-chain
7. Settlement reference included in receipt
The agent **never directly initiates** a blockchain transaction.
---
### Phase 5: Receipt Emission
Every completed execution (successful or failed) emits a canonical GAR receipt.
**Receipt is:**
- Signed by the GAR v1 runtime
- Linked to the CAP token used
- Linked to the policy snapshot hash
- Written to the domain’s receipt ledger
- Queryable via Gao Workspace (L1) audit log
See GAR v1 Specification for full receipt schema.
---
### Phase 6: Retirement
An agent is retired when:
- CAP token expires (automatic)
- Domain owner explicitly revokes the agent
- Domain is transferred (new owner must re-authorize)
- Agent fails compliance review
**Retirement behavior:**
- In-flight executions complete their current window
- No new execution windows open
- All receipts remain accessible indefinitely
- Memory store is preserved (configurable retention period)
**State:** `RETIRED`
Retired agents cannot be reactivated. A new registration with a new CAP token is required.
---
### State Transition Summary
From State
Event
To State
—
Registration complete
`REGISTERED`
`REGISTERED`
CAP token signed
`CONFIGURED`
`CONFIGURED`
Activation triggered
`ACTIVE`
`ACTIVE`
Input received
`EXECUTING`
`EXECUTING`
Execution complete
`ACTIVE` (idle)
`EXECUTING`
Timeout
`ACTIVE` (idle, partial receipt)
`EXECUTING`
Policy/CAP failure
`ACTIVE` (idle, failure receipt)
`ACTIVE`
CAP expired or revoked
`RETIRED`
`ACTIVE`
Owner deactivates
`RETIRED`
---
### Audit Access
All lifecycle events and receipts are accessible via:
- **Gao Workspace** (L1) — visual audit log with filtering
- **SDK** (`gao.receipts.query()`) — programmatic access
- **On-chain ledger** — raw receipt data, always accessible regardless of interface availability
The audit trail survives even if Gao Labs ceases operation.
---
_The agent lifecycle is enforced by GAR v1 and cannot be modified by agent code, operator configuration, or governance action. Lifecycle invariants are documented in GAR v1 Specification as INV-01 through INV-08._