Prompt → Planner → Policy Gate → Sandbox / Browser / Tools → Artifacts → Hosted App / Workflow

---

### 2\. Architectural Position

#### 2.1 Gao Internet 8-Layer Stack

Gao Internet enforces a locked 8-layer architecture. No layer may override another layer’s invariants.

Layer

Name

Role

1

Workspace

Operations console and agent management

2

Browser

Gateway, client execution, approvals

3

SDK

Developer integration and tooling

4

Payment

Settlement, receipts, budget enforcement

5

Domain

Root identity and authority

6

Network

Transport and relay

7

DePIN

Distributed compute, storage, bandwidth

8

AI OS

Standards (AIP) + runtime enforcement (GAR)

#### 2.2 Position of Gao Agent Builder

Gao Agent Builder is a Workspace-native product and control-plane system that composes with all 8 Gao layers and exposes a unified user-facing surface.

It must:

-   Use Workspace as the main management and operations surface
    
-   Use Browser as the client execution and approval surface
    
-   Use SDK as the integration, contract, and developer layer
    
-   Use Payment for budget-aware and receipt-native financial side effects
    
-   Use Domain as root authority and agent identity binding
    
-   Use Network for remote transport, relay, and connector execution
    
-   Use DePIN for distributed compute, long-running workloads, and storage
    
-   Use AI OS and GAR as the only valid runtime enforcement layer
    

#### 2.3 What Gao Agent Builder Is Not

Gao Agent Builder is not:

-   A new core layer in the Gao stack
    
-   A hosted automation service operating outside Gao AI OS
    
-   A custodial wallet or key management system
    
-   A financial settlement system
    
-   A domain ownership or authority system
    
-   A replacement for GAR or AIP standards
    
-   A foundation model or inference provider
    

---

### 3\. Product Capabilities

The system handles high-level natural language requests and delivers fully deployed, working systems.

**Example requests:**

-   “Build a CRM for my business with contacts, pipeline, and invoices”
    
-   “Create a booking app for my restaurant”
    
-   “Set up an internal support desk with ticketing”
    
-   “Deploy a sales outreach agent that researches leads and sends emails”
    
-   “Build an inventory management system with reorder alerts”
    
-   “Create an approval workflow for vendor payments”
    
-   “Automate my LinkedIn outreach and track responses”
    
-   “Build a Telegram bot that monitors my sales data”
    

**The system will:**

1.  Understand intent from natural language
    
2.  Generate a structured task graph and execution plan
    
3.  Bind required tools, skills, and connectors
    
4.  Evaluate capability and policy constraints
    
5.  Request human approval where required by risk tier
    
6.  Execute through GAR with sandbox and browser runtimes
    
7.  Emit receipts, traces, and audit spans throughout
    
8.  Update memory and persist state
    
9.  Deploy resulting agents or apps with public `.gao` domain endpoints
    

---

### 4\. Layer-by-Layer Mapping

#### 4.1 Layer 1 — Workspace

Workspace is the primary operations console for Gao Agent Builder.

Responsibilities:

-   Agent creation and management UI
    
-   Policy and budget configuration
    
-   Capability grant and revoke surface
    
-   Trace and receipt explorer
    
-   Deployment control panel
    
-   Safe mode and suspension controls
    
-   Enterprise governance and audit visibility
    

> Workspace configures but never overrides enforcement performed by other layers.

#### 4.2 Layer 2 — Browser

Browser is the gateway, client execution surface, and approval runtime.

Responsibilities:

-   Approval prompts for sensitive and high-risk actions
    
-   Domain authority verification surfaces
    
-   x402 payment proof and receipt confirmation flows
    
-   Secure runtime isolation status indicators
    
-   Browser-local execution where permitted by policy
    
-   Headless browser runtime for agent-driven automation
    
-   Human confirmation for external high-risk actions
    

#### 4.3 Layer 3 — SDK

SDK is the canonical developer integration layer.

Responsibilities:

-   Manifest type definitions and validators
    
-   Tool schema validators
    
-   Receipt validation helpers
    
-   Capability-aware execution wrappers
    
-   Domain resolution helpers
    
-   x402 payment intent helpers
    
-   Connector plugin interface
    
-   Runtime-safe developer APIs
    

**SDK packages:**

#### 4.4 Layer 4 — Payment

Payment handles settlement, budget enforcement, x402 flows, and canonical receipts.

Responsibilities:

-   Budget profile assignment per agent
    
-   Autopay threshold configuration
    
-   Merchant allowlists
    
-   Settlement-aware tool binding
    
-   Spend traces and finality visibility
    
-   Machine-to-machine payment tool contracts
    
-   x402 API spend flows
    

> Builder must never process or pool settlement directly.

#### 4.5 Layer 5 — Domain

Domain is the root identity and authority layer for all agent operations.

Responsibilities:

-   Bind every agent to an `owner_domain`
    
-   Scope all capabilities to domain authority
    
-   Require expirable and revocable authorization
    
-   Attach agent identity records to domain DNS
    
-   Preserve governance anchor for all AI execution
    

> Builder must never grant authority outside the owner domain scope.

#### 4.6 Layer 6 — Network

Network is the remote transport and relay layer.

Responsibilities:

-   Remote tool transport and execution
    
-   Deterministic routing of remote requests
    
-   Connector execution over approved transport paths
    
-   Relay-aware execution planning
    
-   Network-bound external task invocation
    

#### 4.7 Layer 7 — DePIN

DePIN is the infrastructure execution and marketplace layer.

Responsibilities:

-   Distributed compute targets for long-running agent tasks
    
-   Storage backing for persistent workspaces and artifact stores
    
-   Bandwidth relay for high-throughput connector operations
    
-   Usage-based infrastructure pricing for agent workloads
    
-   Execution target selection exposed in deployment profiles
    

#### 4.8 Layer 8 — AI OS

AI OS is the intelligence and standards layer. It must remain the normative foundation.

Responsibilities:

-   AIP standards define **what** the system must guarantee
    
-   GAR defines **how** those guarantees are enforced at runtime
    
-   Builder compiles user intent into AIP-compatible plans
    
-   All execution is handed to GAR only
    
-   AI OS security, policy, memory, and observability rules apply universally
    

---

### 5\. Normative Product Principles

Gao Agent Builder **must** follow these principles without exception:

1.  **Policy-first execution** — No side effects before Policy Gate approval.
    
2.  **Identity-bound authority** — Every agent action must be attributable to domain-scoped authority.
    
3.  **GAR-only execution** — All real execution must pass through GAR. Builder has no privileged runtime of its own.
    
4.  **Deterministic side-effect boundaries** — Side-effecting operations must be idempotent and replay-safe.
    
5.  **Auditability by default** — All tool calls, policy decisions, receipts, and checkpoints must be inspectable.
    
6.  **Model-agnostic orchestration** — Builder orchestrates models but must not depend on any single vendor.
    
7.  **Non-custodial architecture** — Builder never custodies keys, funds, or domain ownership records.
    
8.  **Sandbox-first code execution** — All generated code must execute inside SSVM-enforced sandbox boundaries.
    
9.  **Taint-aware content handling** — All imported external content is tainted by default. Tainted content cannot directly trigger side effects.
    
10.  **Enterprise-ready safety posture** — RBAC, retention controls, audit export, and air-gapped support must be available at enterprise deployment tier.
     

---

### 6\. Core Product Modules

#### 6.1 Agent Definition Studio

Primary UI and API surface to define an agent package.

Field

Type

Description

`agent_id`

string

Canonical agent identifier

`name`

string

Human-readable name

`owner_domain`

string

Gao Domain authority binding

`description`

string

Purpose summary

`purpose`

string

Normalized purpose class

`risk_tier_default`

enum

LOW / MEDIUM / HIGH

`allowed_capabilities`

array

Scoped capability list

`policy_profile_id`

string

Reference to PolicyProfile

`memory_profile_id`

string

Reference to MemoryProfile

`model_profile_id`

string

Reference to ModelProfile

`tool_set_id`

string

Reference to ToolSetManifest

`skill_set_id`

string

Reference to SkillSetManifest

`deployment_profile_id`

string

Reference to DeploymentProfile

`approval_profile_id`

string

Reference to ApprovalProfile

`sandbox_profile_id`

string

Reference to SandboxProfile

`connector_set_id`

string

Reference to ConnectorSet

`status`

enum

draft / active / paused / revoked

**Outputs:**

-   Normalized `AgentManifest`
    
-   Versioned builder bundle
    
-   Publishable runtime profile
    
-   Deployment and ops metadata
    

#### 6.2 Prompt-to-Agent Composer

Natural language entry point. A user prompt is transformed into:

-   Structured intent classification
    
-   Proposed task graph
    
-   Proposed data model and entity schema
    
-   Proposed UI blocks
    
-   Proposed tool and skill bindings
    
-   Proposed connector activations
    
-   Proposed policy profile
    
-   Proposed deployment mode
    

> The generated output remains a **proposed plan** until it passes GAR planning and gating. No execution occurs before Policy Gate approval.

#### 6.3 Skill and Tool Composer

Builder supports both tools and skills as first-class objects.

**Tools** are contract-level interfaces. Each tool definition must include:

-   Tool name
    
-   Input schema (JSON Schema)
    
-   Output schema (JSON Schema)
    
-   Required capability declaration
    
-   Risk tier classification
    
-   Side-effect declaration
    
-   Idempotency support flag
    
-   Local or remote boundary flag
    
-   Sandbox execution flag
    

**Skills** are declarative automation packages composed from tools, policies, and runtime bindings. Each skill definition must include:

-   Skill name and version
    
-   Domain signature status
    
-   Required policies
    
-   Tool list
    
-   Revocation status
    
-   Install, update, and lifecycle metadata
    

#### 6.4 App Generator

Core “prompt → software” surface.

**Supported output classes:**

-   CRM
    
-   Booking application
    
-   Internal support desk
    
-   Ticket and approval workflow
    
-   Inventory management system
    
-   Campaign manager
    
-   Reporting and analytics dashboard
    
-   Approval flow app
    

**Internal generation sequence:**

1.  Interpret natural language prompt
    
2.  Infer business entities and relationships
    
3.  Infer data model and schema
    
4.  Infer UI model and component blocks
    
5.  Infer required tools, skills, and connectors
    
6.  Infer policy and budget constraints
    
7.  Produce draft app plan
    
8.  Route to human approval where required by risk tier
    
9.  Compile and execute through sandbox
    
10.  Deploy to Workspace and hosting surface
     

#### 6.5 Runtime Binding Layer

Builder’s job is strictly to:

-   Compile agent definitions into runtime-safe bundles
    
-   Create GAR sessions
    
-   Pass execution requests into GAR
    
-   Display runtime outputs, traces, receipts, and checkpoints returned from GAR
    

#### 6.6 Deployment Manager

Deployment profiles support:

-   Browser-local execution
    
-   Desktop execution
    
-   Mobile execution
    
-   Server execution
    
-   Kubernetes cluster execution
    
-   DePIN executor node deployment
    
-   Serverless endpoint deployment
    
-   Public hosted app with `.gao` domain binding
    

#### 6.7 Ops Console

Complete operations console for:

-   Run, pause, suspend, and terminate agents
    
-   View real-time execution traces
    
-   View receipts and finality state
    
-   View and restore checkpoints
    
-   Inspect memory usage and domain scope
    
-   Rotate tool bindings and skill sets
    
-   Revoke individual tools, skills, or adapters
    
-   Enable safe mode and deny-all controls
    
-   Export full audit data
    
-   Inspect spend burn and budget remaining
    

---

### 7\. Secure Execution Sandbox

#### 7.1 Sandbox Architecture

{
  "schema": "gao.sandbox.profile.v1",
  "runtime": "SSVM",
  "languages": ["python", "javascript", "typescript", "bash"],
  "filesystem": {
    "ephemeral_workspace": "/tmp/agent/{session_id}",
    "persistent_workspace": "/domain/{domain_id}/workspace",
    "artifact_store": "/artifacts/{agent_id}"
  },
  "network": {
    "egress": "policy-gated",
    "connector_access": "allowlist-only",
    "raw_internet": false
  },
  "resource_limits": {
    "cpu_seconds": "configurable",
    "memory_mb": "configurable",
    "execution_timeout_s": "configurable"
  },
  "audit": "full-trace",
  "escape_prevention": true
}

#### 7.2 Execution Capabilities

-   Python script execution with dependency installation
    
-   Node.js and TypeScript service compilation and execution
    
-   Bash and shell automation
    
-   Data pipeline execution
    
-   Test suite execution and reporting
    
-   File generation and transformation
    
-   API endpoint scaffolding and execution
    

#### 7.3 Sandbox Invariants

1.  All code execution must remain inside sandbox boundaries.
    
2.  File system access outside scoped paths is denied.
    
3.  Network egress must pass policy-gated connector allowlist.
    
4.  Secrets must never be passed raw into execution context.
    
5.  All execution produces a trace span in the audit log.
    
6.  Side-effecting code operations must declare idempotency support.
    

#### 7.4 Code Execution Flow

{
  "schema": "gao.hosting.profile.v1",
  "auto_subdomain": "{app_name}.workspace.gao",
  "custom_domain_binding": true,
  "ephemeral_preview": true,
  "persistent_deploy": true,
  "ssl": "auto",
  "cdn": "enabled",
  "domain_authority_required": true
}

crm.workspace.gao       → ephemeral preview
crm.merchant.gao        → persistent custom domain
support-desk.company.gao → enterprise domain binding

{
  "schema": "gao.browser.runtime.v1",
  "engine": "chromium-headless",
  "mode": ["headless", "visual"],
  "capabilities": {
    "click": true,
    "type": true,
    "scroll": true,
    "extract": true,
    "screenshot": true,
    "form_fill": true,
    "js_execution": true,
    "session_persistence": true,
    "cookie_management": "policy-scoped"
  },
  "policy_enforcement": "GAR",
  "audit": "full-trace",
  "taint_marking": "automatic"
}

{
  "schema": "gao.connector.registry.v1",
  "tier_1": [
    "gmail", "google_drive", "google_calendar",
    "slack", "github", "telegram", "jira", "notion"
  ],
  "tier_2": [
    "twitter", "linkedin", "shopify",
    "stripe", "airtable", "hubspot", "salesforce"
  ],
  "gao_native": [
    "gao_social", "meshii", "payii",
    "tmail", "gao_workspace", "gao_domains", "runx"
  ],
  "custom": ["oauth2", "webhook", "sdk_plugin", "rest_api"]
}

Slack message received
↓
Trigger agent task
↓
Agent fetches data from Google Sheet via Drive connector
↓
Agent generates report via sandbox execution
↓
Policy gate approves send action
↓
Agent sends email via Gmail connector
↓
Receipt and audit span recorded

---

### 11\. Media Generation Module

#### 11.1 Supported Output Types

Type

Engine Class

Risk Tier

Image

Diffusion model

LOW

Video

Generative video model

MEDIUM

Audio / TTS

Voice synthesis model

LOW

Document

Structured generation

LOW

Dataset

Extraction + transform

LOW–MEDIUM

#### 11.2 Policy Rules

1.  Generated media must be attributed to domain-scoped agent authority.
    
2.  Media outputs must be stored in the artifact store, not injected into model context.
    
3.  Outputs used in external-facing content must pass policy gate.
    
4.  Deepfake-risk outputs (video/voice of real individuals) are HIGH risk tier and require explicit approval.
    

---

### 12\. Multi-Agent Execution

#### 12.1 Agent Roles

Role

Function

Coordinator

Decomposes goal, delegates subtasks, merges results

Worker

Executes discrete subtasks

Reviewer

Validates outputs against declared quality or policy standards

Observer

Monitors long-running tasks and emits checkpoints

#### 12.2 Multi-Agent Execution Flow

#### 12.3 Multi-Agent Invariants

1.  Each sub-agent must have its own domain-scoped capability grant.
    
2.  Inter-agent communication must pass through GAR bridge interface.
    
3.  Side effects from any sub-agent require their own policy gate evaluation.
    
4.  The full execution tree must be auditable as a single trace graph.
    

---

### 13\. Runtime and Execution Model

#### 13.1 Runtime Rule

All execution must go through GAR.

Builder proposes plans and configuration. GAR is solely responsible for enforcement of:

-   Capability validation
    
-   Policy enforcement
    
-   Identity binding
    
-   Execution compliance
    
-   Tool interface validation
    
-   Sandbox boundary enforcement
    
-   Prompt injection mitigation
    
-   Observability guarantees
    
-   Enterprise compliance requirements
    

#### 13.2 Execution State Model

Distributed and long-running execution additionally supports:

#### 13.3 Non-Negotiable Runtime Rules

1.  No side effects before Policy Gate approval.
    
2.  All side-effect boundaries must be idempotent.
    
3.  Checkpoints must precede irreversible actions.
    
4.  Replay must not duplicate side effects.
    
5.  All local and remote tool execution must pass the Bridge Interface.
    
6.  All sandbox execution must remain inside declared filesystem and network boundaries.
    
7.  All browser automation results are tainted until policy gate approval.
    

---

### 14\. Security Model

#### 14.1 Prompt Injection Defense

Builder adopts Gao AI OS AIP-13 prompt injection rules.

**Mandatory handling:**

-   All imported external content — files, webpages, emails, scraped data — is marked tainted by default
    
-   Secrets must never be injected directly into LLM model context
    
-   High-risk actions triggered by tainted content must escalate to human approval
    
-   External content must be boundary-wrapped before reaching the planner
    
-   High-risk actions must use two-pass validation
    

**Builder implications:**

-   Files, webpages, emails, and scraped content receive automatic taint markers at ingestion
    
-   Models cannot directly convert tainted content into side effects
    
-   Send, publish, delete, deploy, and payment actions triggered by tainted content require escalation
    
-   Secret vault values remain outside model-visible context unless strictly required by declared capability
    

#### 14.2 Bridge Security

All local and remote tool execution must pass the Bridge Interface.

Replay-resistant request envelopes must include:

Field

Purpose

`session_id`

Session binding

`tool_call_id`

Tool call uniqueness

`idempotency_key`

Replay prevention

`domain`

Identity binding

`capability`

Required capability declaration

`policy_hash`

Policy version binding

`timestamp`

Time binding

`nonce`

Replay resistance

`origin_marker`

Taint origin tracking

`signature`

Remote boundary trust

#### 14.3 Sandbox Security

1.  All generated code executes inside SSVM boundaries.
    
2.  File system access outside declared scoped paths is denied at runtime.
    
3.  Network egress from sandbox must pass connector allowlist and policy gate.
    
4.  Secrets passed to sandbox must be vault-scoped and not logged.
    
5.  Sandbox escape attempts must trigger immediate suspension and audit event.
    

#### 14.4 Browser Safety

1.  Browser automation sessions run in isolated chromium contexts.
    
2.  Session cookies and credentials are policy-scoped and not persisted beyond explicit grant.
    
3.  All pages are tainted on load.
    
4.  High-risk actions from browser automation require policy gate re-evaluation.
    

#### 14.5 Financial Safety

Builder must never:

-   Custody funds or user keys
    
-   Pool or batch payments outside Layer 4 protocol
    
-   Rewrite or modify receipts after generation
    
-   Bypass payment finality requirements
    
-   Bypass user signature requirements for payment intents
    

---

### 15\. Functional Subsystems

#### 15.1 Agent Registry

Stores canonical metadata for all agents:

-   `agent_id`, `version`, `owner_domain`
    
-   `manifest_hash`, `status`
    
-   `created_by`, `last_published_at`
    
-   `sandbox_profile_id`, `connector_set_id`
    

#### 15.2 Manifest Compiler

Transforms UI and prompt definitions into normalized runtime bundles:

-   `AgentManifest`
    
-   `ToolSetManifest`
    
-   `SkillSetManifest`
    
-   `PolicyProfile`
    
-   `ModelProfile`
    
-   `DeploymentProfile`
    
-   `ApprovalProfile`
    
-   `SandboxProfile`
    
-   `ConnectorSet`
    
-   `HostingProfile`
    

#### 15.3 Policy Profile Manager

Handles:

-   Capability allowlists per agent
    
-   Risk tier thresholds and overrides
    
-   Spending limits and autopay thresholds
    
-   Merchant and connector allowlists
    
-   Escalation paths for high-risk actions
    
-   Safe mode and deny-all controls
    
-   Retention rules and redaction policies
    
-   Enterprise compliance flags
    

> Workspace configures these profiles. Enforcement belongs exclusively to GAR and Payment layers.

#### 15.4 Runtime Session Manager

Creates and manages GAR sessions. Tracks:

-   Planning state, gating state
    
-   Active tool calls
    
-   Sandbox execution state
    
-   Browser automation state
    
-   Trace spans, receipt handles
    
-   Checkpoint handles, execution target handles
    

#### 15.5 Memory Manager

Configures:

-   Domain-scoped memory
    
-   Workspace-scoped memory
    
-   Session-scoped memory
    
-   Retention profile, redaction profile
    
-   Enterprise memory controls
    

#### 15.6 Audit and Trace Explorer

Displays:

-   Full execution trace graph
    
-   Tool call graph with inputs and outputs
    
-   Policy gate decisions and reasons
    
-   Taint propagation map
    
-   Sandbox and browser automation events
    
-   Receipts and finality state
    
-   Checkpoint transitions and migration events
    
-   Connector activation events
    
-   Model and provider used per planning step
    
-   Approval events and escalation decisions
    

---

### 16\. Data Contracts

#### 16.1 AgentManifest

{
  "schema": "gao.agent.manifest.v1",
  "agent_id": "agt_xxx",
  "name": "Sales CRM Builder",
  "owner_domain": "merchant.gao",
  "version": "1.0.0",
  "description": "Builds and operates CRM workflows for merchants",
  "purpose": "crm_generation_and_ops",
  "risk_tier_default": "MEDIUM",
  "capabilities": [
    "workspace:read",
    "workspace:write",
    "payment:intent_create",
    "domain:resolve",
    "network:remote_tool_call",
    "sandbox:execute",
    "browser:automate",
    "connector:gmail",
    "connector:slack"
  ],
  "policy_profile_id": "pol_xxx",
  "memory_profile_id": "mem_xxx",
  "model_profile_id": "mdl_xxx",
  "tool_set_id": "tools_xxx",
  "skill_set_id": "skills_xxx",
  "deployment_profile_id": "dep_xxx",
  "approval_profile_id": "apr_xxx",
  "sandbox_profile_id": "sbx_xxx",
  "connector_set_id": "conn_xxx",
  "status": "draft"
}

#### 16.2 ToolContract

{
  "schema": "gao.tool.contract.v1",
  "tool_name": "create_invoice",
  "input_schema": {},
  "output_schema": {},
  "required_capability": "payment:intent_create",
  "risk_tier": "HIGH",
  "side_effecting": true,
  "idempotency_supported": true,
  "remote_boundary": true,
  "sandbox_required": false
}

#### 16.3 SkillManifest

{
  "schema": "gao.skill.manifest.v1",
  "skill_id": "skill_sales_followup",
  "name": "Sales Follow-up Automation",
  "version": "1.0.0",
  "domain_signed": true,
  "tools": ["search_contacts", "draft_message", "create_task"],
  "policies_required": ["sales_default"],
  "revocable": true
}

#### 16.4 DeploymentProfile

{
  "schema": "gao.deployment.profile.v1",
  "target": "server",
  "runtime_mode": "gar_enforced",
  "browser_approval_required": true,
  "checkpointing": true,
  "trace_export": true,
  "enterprise_mode": false,
  "hosting": {
    "auto_subdomain": "crm.workspace.gao",
    "custom_domain_binding": false,
    "ssl": "auto"
  }
}

#### 16.5 SandboxProfile

{
  "schema": "gao.sandbox.profile.v1",
  "runtime": "SSVM",
  "languages": ["python", "javascript", "typescript", "bash"],
  "filesystem": {
    "ephemeral_workspace": "/tmp/agent/{session_id}",
    "persistent_workspace": "/domain/{domain_id}/workspace",
    "artifact_store": "/artifacts/{agent_id}"
  },
  "network_egress": "policy-gated",
  "resource_limits": {
    "cpu_seconds": 300,
    "memory_mb": 2048,
    "execution_timeout_s": 600
  },
  "audit": "full-trace"
}

#### 16.6 ConnectorSet

{
  "schema": "gao.connector.set.v1",
  "connector_set_id": "conn_xxx",
  "connectors": [
    {
      "connector_id": "gmail",
      "tier": 1,
      "scopes": ["read", "send"],
      "risk_tier": "MEDIUM",
      "auth_type": "oauth2"
    },
    {
      "connector_id": "slack",
      "tier": 1,
      "scopes": ["message:write", "channel:read"],
      "risk_tier": "LOW",
      "auth_type": "oauth2"
    },
    {
      "connector_id": "meshii",
      "tier": "gao_native",
      "scopes": ["message:send"],
      "risk_tier": "LOW",
      "auth_type": "domain_signed"
    }
  ]
}

POST   /builder/agents
GET    /builder/agents/:id
PATCH  /builder/agents/:id
POST   /builder/agents/:id/compile
POST   /builder/agents/:id/publish
POST   /builder/agents/:id/pause
POST   /builder/agents/:id/revoke
POST   /builder/agents/:id/safe-mode
POST   /builder/agents/:id/tools/install
POST   /builder/agents/:id/skills/install
POST   /builder/agents/:id/adapters/install
POST   /builder/agents/:id/connectors/install
GET    /builder/agents/:id/traces
GET    /builder/agents/:id/receipts
GET    /builder/agents/:id/checkpoints
GET    /builder/agents/:id/audit

POST   /builder/compose
POST   /builder/compose/:job_id/refine
POST   /builder/compose/:job_id/approve-plan
POST   /builder/compose/:job_id/generate-app
POST   /builder/compose/:job_id/deploy

POST   /gar/sessions
POST   /gar/sessions/:id/execute
POST   /gar/sessions/:id/suspend
POST   /gar/sessions/:id/migrate
POST   /gar/sessions/:id/terminate

POST   /sandbox/sessions
POST   /sandbox/sessions/:id/execute
GET    /sandbox/sessions/:id/artifacts
GET    /sandbox/sessions/:id/logs
POST   /sandbox/sessions/:id/terminate

POST   /browser/sessions
POST   /browser/sessions/:id/navigate
POST   /browser/sessions/:id/action
GET    /browser/sessions/:id/screenshot
GET    /browser/sessions/:id/extract
POST   /browser/sessions/:id/terminate

GET    /connectors
GET    /connectors/:id
POST   /connectors/:id/auth
POST   /connectors/:id/actions/:action_name
GET    /connectors/:id/audit

POST   /hosting/deploy
GET    /hosting/apps/:id
POST   /hosting/apps/:id/promote
POST   /hosting/apps/:id/rollback
DELETE /hosting/apps/:id

GET    /artifacts
GET    /artifacts/:id
POST   /artifacts/:id/promote
GET    /artifacts/:id/download
DELETE /artifacts/:id
GET    /artifacts/:id/lineage

POST   /knowledge/ingest
GET    /knowledge/ingest/:id
GET    /knowledge/objects
GET    /knowledge/objects/:id
POST   /knowledge/objects/:id/trust
GET    /knowledge/search

POST   /scheduler/jobs
GET    /scheduler/jobs
GET    /scheduler/jobs/:id
PATCH  /scheduler/jobs/:id
POST   /scheduler/jobs/:id/pause
POST   /scheduler/jobs/:id/resume
POST   /scheduler/jobs/:id/replay
DELETE /scheduler/jobs/:id
GET    /scheduler/jobs/:id/runs

GET    /memory/graph
GET    /memory/graph/nodes/:id
GET    /memory/graph/nodes/:id/edges
POST   /memory/graph/query
GET    /memory/graph/lineage/:artifact_id

---

### 18\. UI Surfaces

#### 18.1 Workspace-Native UI

Tab

Purpose

Overview

Agent status and activity summary

Prompt Builder

Natural language agent and app composition

Manifest

Agent definition and versioning

Tools

Tool binding and management

Skills

Skill install, revoke, lifecycle

Connectors

SaaS and Gao-native connector management

Models

Model profile and adapter configuration

Sandbox

Code execution environment and artifacts

Browser

Browser automation sessions and history

Memory

Memory profile and retention configuration

Policies

Policy profile and capability management

Budget

Spend limits and finality state

Deployment

Deployment profile and hosting configuration

Traces

Real-time and historical execution traces

Receipts

Payment receipts and finality confirmation

Checkpoints

Checkpoint history and restore controls

Artifacts

Artifact store, versioning, promotion, download

Knowledge

Knowledge ingestion, objects, retrieval index

Scheduler

Scheduled jobs, triggers, run history

Memory Graph

Operational memory graph, lineage, entity links

#### 18.2 Browser Surfaces

-   Approval prompt for sensitive actions
    
-   Domain authority confirmation flow
    
-   x402 payment proof prompt
    
-   Risk-tier escalation warning
    
-   Runtime isolation status indicator
    
-   Secure connector authorization prompt
    
-   Browser automation session viewer
    

---

### 19\. Artifact System

#### 19.1 Purpose

The Artifact System is the persistent output layer for Gao Agent Builder. Every meaningful execution output is captured as a first-class artifact.

Artifacts include: generated code, app bundles, datasets, transformed documents, reports, screenshots, browser session captures, media outputs, API definitions, test results, and audit exports.

#### 19.2 Artifact Classes

Class

Description

Typical Producer

`code_bundle`

Generated application or script source

Sandbox

`app_bundle`

Deployable web app or service bundle

App Generator

`dataset`

Structured table, JSON, CSV, extracted records

Connectors / Sandbox

`document`

PDF, Markdown, DOCX, report package

Sandbox / Media

`browser_capture`

Screenshots, DOM extracts, session recordings

Browser Runtime

`test_result`

Unit, integration, E2E, QA reports

Sandbox / Browser

`media`

Image, audio, video output

Media Generation

`api_spec`

OpenAPI / endpoint manifests

Sandbox

`audit_export`

Trace export, receipts, compliance package

Ops Console

`model_output`

Structured planner/reasoning output retained for review

GAR

#### 19.3 Artifact Contract

{
  "schema": "gao.artifact.v1",
  "artifact_id": "art_xxx",
  "type": "code_bundle",
  "owner_domain": "merchant.gao",
  "producer_agent_id": "agt_xxx",
  "session_id": "sess_xxx",
  "storage_location": "/artifacts/agt_xxx/art_xxx",
  "hash": "sha256:...",
  "size_bytes": 102400,
  "mime_type": "application/zip",
  "created_at": "2026-03-06T00:00:00Z",
  "access_policy_id": "acc_xxx",
  "retention_profile_id": "ret_xxx",
  "taint_state": "clean",
  "version": 1,
  "immutable": true,
  "lineage": {
    "parent_artifacts": [],
    "derived_from_sessions": ["sess_xxx"]
  }
}

#### 19.4 Artifact Invariants

1.  Every artifact must be domain-bound to its owner domain.
    
2.  Every artifact must carry a content hash for integrity verification.
    
3.  Every artifact must be versioned.
    
4.  Immutable artifacts must never be modified in place.
    
5.  Derived artifacts must preserve full lineage references.
    
6.  Tainted source material must preserve taint state until cleared by policy gate.
    
7.  Hosted artifacts must reference the originating artifact ID.
    
8.  Deletion and retention actions must produce audit events.
    

#### 19.5 Artifact Lifecycle

#### 19.6 Artifact Access Modes

Access Mode

Scope

`private`

Owner domain only

`workspace-shared`

All agents in Workspace

`agent-shared`

Specific delegated agents

`public hosted`

Public URL via Gao Domains

`compliance-exportable`

Authorized audit export

---

### 20\. Knowledge Ingestion Pipeline

#### 20.1 Purpose

The Knowledge Ingestion Pipeline transforms external and internal data into structured, retrievable knowledge for agents.

#### 20.2 Supported Sources

Source Type

Examples

Uploaded files

PDF, DOCX, CSV, JSON

Workspace files

Workspace-native documents

Email

Gmail via connector

Cloud storage

Google Drive, Notion

Collaboration

Slack threads

Code

GitHub repositories

Web

Scraped pages via Browser Runtime

Datasets

CSV / JSON datasets

Gao-native records

Tmail, Gao Social, Gao Workspace

Custom APIs

REST endpoints via connector

#### 20.3 Ingestion Pipeline Stages

#### 20.4 Taint and Trust Rules

1.  All external content enters as tainted by default.
    
2.  Connector-provided content is tainted unless explicitly trusted by policy profile.
    
3.  Knowledge retrieved from tainted objects cannot directly trigger side effects.
    
4.  Promotion from tainted to trusted requires policy gate review and audit event.
    
5.  Trust decisions must be logged with actor and timestamp.
    

#### 20.5 Retrieval Modes

-   Semantic vector retrieval
    
-   Structured SQL-style query
    
-   Timeline-ordered query
    
-   Connector-origin filtered query
    
-   Artifact-origin filtered query
    
-   Domain-scoped knowledge retrieval
    

#### 20.6 Ingestion Invariants

1.  Source provenance must be preserved for every ingested object.
    
2.  Every ingested object must trace back to a source artifact or connector reference.
    
3.  All indexing must be domain-scoped unless explicitly shared.
    
4.  Secrets and credentials must be stripped before model-visible context.
    
5.  Enterprise mode must apply redaction policies before indexing.
    

---

### 21\. Agent Scheduling Engine

#### 21.1 Purpose

The Agent Scheduling Engine enables non-interactive, recurring, and event-driven execution — unlocking the full class of autonomous agent operations.

**Use cases:**

-   Recurring daily or weekly reports
    
-   Monitoring and alerting jobs
    
-   Threshold-triggered automations
    
-   Nightly sync and backfill tasks
    
-   Lead enrichment pipelines
    
-   Scheduled outreach sequences
    
-   Compliance sweep and audit jobs
    

#### 21.2 Supported Trigger Types

Trigger Type

Description

`cron`

Time-based recurring schedule

`interval`

Fixed interval repeat

`event`

Internal or external event signal

`webhook`

Inbound HTTP trigger

`threshold`

Data-condition trigger

`dependency`

Triggered on completion of another task

`manual_replay`

Explicit user-initiated replay

#### 21.3 Scheduler Architecture

#### 21.4 Scheduler Job Contract

{
  "schema": "gao.scheduler.job.v1",
  "job_id": "job_xxx",
  "agent_id": "agt_xxx",
  "owner_domain": "merchant.gao",
  "trigger": {
    "type": "cron",
    "expression": "0 9 * * *",
    "timezone": "America/Chicago"
  },
  "policy_profile_id": "pol_xxx",
  "priority": "normal",
  "retry_policy": {
    "max_retries": 3,
    "backoff": "exponential"
  },
  "execution_target": "server",
  "status": "active"
}

#### 21.5 Scheduling Invariants

1.  Every scheduled execution must create a new GAR session.
    
2.  Scheduled tasks must re-evaluate policy at execution time, not at schedule creation time.
    
3.  Idempotency must be enforced for all retryable side effects.
    
4.  Missed schedules must not silently replay destructive actions.
    
5.  Manual replay must generate a new independent trace lineage.
    
6.  Threshold-triggered jobs must record triggering evidence in the audit log.
    

#### 21.6 Scheduling and Budget Rules

Scheduler integrates with Payment and Policy profiles for:

-   Job-level spend ceiling enforcement
    
-   Monthly budget cap enforcement
    
-   External API quota awareness
    
-   Connector rate limit compliance
    
-   Automatic pause on budget exhaustion with audit event
    

---

### 22\. Agent Memory Graph

#### 22.1 Purpose

The Agent Memory Graph is the persistent operational reasoning graph for Gao Agent Builder. It links sessions, tasks, artifacts, knowledge objects, connector events, user interactions, deployed apps, and policy events into a reusable, domain-scoped operational memory system.

#### 22.2 Memory Graph Node Types

Node Type

Description

`session`

Individual GAR execution session

`task`

Long-running workflow or objective

`artifact`

Output object from sandbox, browser, or tool execution

`knowledge_object`

Indexed and retrieved knowledge entity

`entity`

CRM record, customer, project, document

`connector_event`

Imported event from Slack, Gmail, GitHub, etc.

`policy_event`

Gate decision, approval, or escalation event

`deployment`

Hosted app or runtime deployment object

#### 22.3 MemoryGraph Contract

{
  "schema": "gao.memory.graph.v1",
  "graph_id": "memg_xxx",
  "owner_domain": "merchant.gao",
  "nodes": [
    { "node_id": "task_123", "type": "task", "label": "CRM Build Workflow" },
    { "node_id": "art_456", "type": "artifact", "label": "Generated CRM App Bundle" }
  ],
  "edges": [
    { "from": "task_123", "to": "art_456", "type": "produced" }
  ]
}

#### 22.4 Memory Graph Functions

-   Entity linking across multiple sessions
    
-   Artifact-to-task lineage traversal
    
-   Connector-origin correlation
    
-   Repeated task pattern recognition for planner optimization
    
-   Reusable context grounding for subsequent prompts
    
-   Deployment history lookup
    
-   Post-hoc audit traversal
    
-   Memory-aware planning queries
    

#### 22.5 Planner Integration Flow

#### 22.6 Memory Graph Invariants

1.  All graph nodes must be domain-scoped unless explicitly shared.
    
2.  Graph edges must preserve provenance of all relationships.
    
3.  Tainted sources remain tainted through graph traversal until cleared by policy.
    
4.  Memory graph access must respect RBAC and policy profiles.
    
5.  Sensitive nodes must support redaction and retention controls.
    
6.  Memory graph writes must produce audit events.
    

---

### Complete Execution Pipeline (v2.5)

Pipeline Component

Gao Layer

Operations console

Layer 1 — Workspace

Approvals and gateway

Layer 2 — Browser

Developer tooling

Layer 3 — SDK

Payment and receipts

Layer 4 — Payment

Identity and authority

Layer 5 — Domain

Remote transport

Layer 6 — Network

Heavy compute

Layer 7 — DePIN

Standards and runtime

Layer 8 — AI OS / GAR

---

_Gao Agent Builder — Public Developer Documentation — GAB/2.5_