G

Agent Lifecycle

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._