Decompiled Code Patterns — 10 Architectural Patterns from 3305 Functions

Overview

Systematic analysis of 3,305 decompiled functions from the agy Go binary (language_server_hub) reveals 10 distinct architectural patterns. These patterns define the internal structure of the JETSKY platform and reveal how Google's agent runtime is engineered at scale.

The binary's internal package root is github.com/anthropics/jetsky/internal/.... All function names, package paths, and structural relationships were extracted via Ghidra MCP decompilation.

mindmap
  root((JETSKY Binary<br/>3305 Functions))
    Cascade Architecture
      CascadeManager
      Trajectory orchestration
      Battle Mode
    Trajectory Persistence
      Serialization to disk
      Resume from saved state
      ProtoStore
    Battle Mode
      Multi-model A/B
      Winner selection
      Step replacement
    Subagent Architecture
      InvokeSubagentHandler
      Task mode
      Inbox management
    MCP Integration
      Stdio + HTTP transports
      System MCP
      Tool routing
    Browser Automation
      CDP client
      Screenshot capture
      JS execution
    Knowledge Management
      Knowledge Items
      Document manager
      Web scraping
    CEL Enforcement
      Expression evaluation
      Request authorization
      Sandbox proxy
    Feature Flags
      UnleashWrapper
      Experiment configs
      Gradual rollout
    Hardcoded Permissions
      getHardcodedGrants
      Access control
      Permission system

Pattern 1: Cascade Architecture

What Is a Cascade?

The "cascade" is the core agent execution loop. It is the fundamental unit of agent computation in JETSKY. A cascade manages a trajectory (conversation session), handles model calls, tool execution, and state transitions.

Key Functions

Function	Package	Size	Purpose
CascadeManager.New	cortex	~8KB	Creates the cascade manager
CascadeManager.EndBattleMode	cortex	—	Ends battle mode for a cascade
CascadeManager.applyBattleModeWinner	cortex	—	Applies winning model from A/B test
CascadeManager.ensureTrajectoryLoaded	cortex	—	Loads trajectory from disk if needed
CascadeManager.getBaseTrajectory	cortex	—	Gets the root trajectory
CascadeManager.getTrajectoryMetadata	cortex	—	Gets trajectory metadata
CascadeManager.normalizeWorkspaceURI	cortex	—	Normalizes workspace paths
Server.StartCascade	language_server	—	Starts a new cascade on the server

Architecture

graph TB
    subgraph "CascadeManager"
        CM["CascadeManager<br/>Orchestrates all cascades"]
        CM -->|"manages"| C1["Cascade 1<br/>trajectory: main"]
        CM -->|"manages"| C2["Cascade 2<br/>trajectory: subagent-1"]
        CM -->|"manages"| C3["Cascade 3<br/>trajectory: subagent-2"]
    end

    subgraph "Per-Cascade"
        direction TB
        Traj["Trajectory<br/>(conversation state)"]
        Exec["CascadeExecutor<br/>(execution engine)"]
        Gen["Generator<br/>(model API calls)"]
        Tools["Tool Manager<br/>(tool execution)"]
        
        Traj --> Exec
        Exec --> Gen
        Exec --> Tools
    end

    C1 --> Traj
    C2 --> Traj
    C3 --> Traj

    style CM fill:#2a4a6b

Relationship to SDK

The SDK's LocalConnection maps to a single cascade. The cascade_id in HarnessConfig identifies which cascade the SDK is connected to. Subagents create additional cascades tracked by the CascadeManager.

Pattern 2: Trajectory Persistence

What Is a Trajectory?

A trajectory is the serialized state of a conversation -- including all steps, tool calls, model responses, and metadata. It can be saved to disk and resumed later.

Key Functions

Function	Package	Purpose
protoTrajectory	trajectory	Converts internal trajectory to protobuf
StepHeaderMetadata	trajectory	Metadata header for each step
StepHeaderTaskDetails	trajectory	Task-specific step details
ChatModelHeader	trajectory	Model information header
GeneratorMetadataHeader	trajectory	Generator metadata
PlannerResponseStepView	trajectory	Planner response visualization
processPendingUpdates	traj	Processes queued trajectory updates
startCommitWorker	traj	Background trajectory persistence worker
Manager	trajectorystore	Trajectory store manager
ProtoStore	trajectorystore	Protobuf-based storage backend

Persistence Flow

sequenceDiagram
    participant Agent as Agent Loop
    participant Store as TrajectoryStore
    participant Worker as Commit Worker
    participant Disk as Filesystem

    Agent->>Store: Add step to trajectory
    Store->>Store: Queue pending update
    
    Worker->>Store: Poll for pending updates
    Store-->>Worker: Batch of updates
    Worker->>Worker: Serialize to protobuf
    Worker->>Disk: Write trajectory file
    
    Note over Disk: Path: ~/.gemini/antigravity/<session-id>/trajectory.pb
    
    Agent->>Store: Session resume requested
    Store->>Disk: Read trajectory file
    Disk-->>Store: Protobuf bytes
    Store->>Store: Deserialize trajectory
    Store-->>Agent: Restored trajectory state

SDK Integration

The SDK can resume sessions via the initial_trajectory field in HarnessConfig:

config = LocalAgentConfig(
    conversation_id="previous-session-id",
    save_dir="/path/to/saved/trajectory",
)

The harness reads the saved trajectory from save_dir and passes it as initial_trajectory bytes in the handshake.

Pattern 3: Battle Mode

What Is Battle Mode?

Battle Mode is an internal A/B testing mechanism that runs multiple models in parallel on the same input and compares their outputs. The winning model's output is used.

Key Functions

Function	Package	Purpose
CascadeManager.EndBattleMode	cortex	Ends battle mode for a cascade
CascadeManager.applyBattleModeWinner	cortex	Applies the winning model's output
trajectoryWithReplacer	battlemode	Step replacement logic
trajectoryWithReplacer.clone	battlemode	Clones trajectory for parallel execution
Step status indexing	battlemode	Tracks step completion across models

Architecture

graph TB
    Input["User Input"] --> BM["Battle Mode Manager"]
    
    BM -->|"Clone trajectory"| M1["Model A<br/>(e.g., gemini-2.5-pro)"]
    BM -->|"Clone trajectory"| M2["Model B<br/>(e.g., gemini-3.5-flash)"]
    BM -->|"Clone trajectory"| M3["Model C<br/>(e.g., deepseek-v4)"]
    
    M1 -->|"Response A"| Judge["Winner Selection<br/>(quality metric)"]
    M2 -->|"Response B"| Judge
    M3 -->|"Response C"| Judge
    
    Judge -->|"Winner"| Apply["applyBattleModeWinner()<br/>Replace trajectory steps"]
    Apply --> Output["Final Response"]
    
    style BM fill:#6b2a4a
    style Judge fill:#4a6b2a

How It Works

1. Clone: The current trajectory is cloned for each competing model
2. Execute: All models process the same input in parallel
3. Compare: A quality metric (human feedback, automated scoring, or heuristic) evaluates outputs
4. Select: The winning model's trajectory replaces the original
5. Discard: Losing trajectories are discarded

This is likely used for internal quality benchmarking and model selection optimization.

Pattern 4: Subagent Architecture

Key Functions

Function	Package	Purpose
InvokeSubagentHandler.Handle	handlers	Main subagent invocation
InvokeSubagentHandler.handleTaskMode	handlers	Task-mode subagent
DefineSubagentSubHandler.Handle	handlers	Subagent definition
ManageInboxSubHandler.handleList	handlers	Inbox management
ConversationSubagentManager	subagent	Subagent lifecycle manager
SubagentUpdateForwarder	agent_state_component	Forwards updates from subagent to parent
mergeParallelArrays	agent_state_component	Merges parallel subagent results
mergeTrajectoryUpdates	agent_state_component	Combines trajectory state from subagents

Subagent Invocation Flow

sequenceDiagram
    participant Parent as Parent Agent
    participant Handler as InvokeSubagentHandler
    participant CM as CascadeManager
    participant Sub as Subagent Cascade

    Parent->>Handler: Tool call: start_subagent(task="...")
    Handler->>Handler: handleTaskMode(task)
    Handler->>CM: Create new cascade
    CM->>Sub: Initialize subagent trajectory
    
    loop Subagent execution
        Sub->>Sub: Process task
        Sub->>Handler: SubagentUpdateForwarder
        Handler->>Parent: Forward updates to parent trajectory
    end

    Sub->>Handler: Task complete
    Handler->>Parent: Return subagent result
    CM->>CM: Clean up subagent cascade

Parent-Child Relationship

• Parent trajectories track subagent IDs in _active_subagent_ids
• Subagent trajectories have unique trajectory_id values
• The connection only goes idle when ALL trajectories (parent + subagents) complete
• mergeParallelArrays combines results when multiple subagents run in parallel

Pattern 5: MCP Integration

Key Functions

Function	Package	Purpose
setUpMcpManager	language_server	Initialize MCP manager
setUpSystemMcpManager	language_server	Initialize system-level MCP
McpServersSection.Content	mixins	System prompt section for MCP
MCP server management	mcp / mcpcore	MCP protocol implementation

Transport Support

graph LR
    subgraph "MCP Manager"
        MM["McpManager"]
    end

    subgraph "Stdio Transport"
        ST["Subprocess<br/>stdin/stdout<br/>JSON-RPC 2.0"]
    end

    subgraph "HTTP Transport"
        HT["HTTP Client<br/>Streamable HTTP<br/>SSE support"]
    end

    subgraph "System MCP"
        SM["Built-in MCP servers<br/>managed by harness"]
    end

    MM --> ST
    MM --> HT
    MM --> SM
    ST -->|"tool call"| Ext1["External MCP Server 1"]
    HT -->|"tool call"| Ext2["External MCP Server 2"]
    SM -->|"tool call"| Built["Built-in Tools"]

System Prompt Injection

MCP servers are injected into the system prompt via McpServersSection:

## Available MCP Servers

### server-name
Tools:
- tool1: Description of tool1
- tool2: Description of tool2

This is generated by the mixins.McpServersSection.Content function and appended to the system instructions.

Pattern 6: Browser Automation

Key Functions

Function	Package	Purpose
CommonBrowserHandler.handleInternal	browser	Main browser operation handler
BrowserSubagentHandler.internalHandle	browser	Browser subagent handler
BrowserSubagentHandler.handleStopRecording	browser	Stop recording
Operator.CaptureScreenshot	browser	Screenshot capture
BrowserPage.evaluateCDP	browserabstractions	CDP command execution
captureContextsMetadata	browserabstractions	Capture page context
NewCaptureBrowserScreenshotHandler	browser	Screenshot handler factory
NewCaptureBrowserConsoleLogsHandler	browser	Console log handler
NewListBrowserPagesHandler	browser	Page enumeration
NewReadBrowserPageHandler	browser	Page content reader
NewBrowserScrollHandler	browser	Scroll control
executeJavaScriptAction	browser	JS execution
mouseWheelAction / pressKeyAction	browser	Input simulation

CDP Integration

graph TB
    subgraph "Browser Subsystem"
        BH["Browser Handler"]
        BP["Browser Page"]
        CDP["CDP Client"]
    end

    subgraph "Chrome DevTools Protocol"
        Screenshot["Page.captureScreenshot"]
        DOM["DOM.getDocument"]
        JS["Runtime.evaluate"]
        Input["Input.dispatchMouseEvent<br/>Input.dispatchKeyEvent"]
    end

    subgraph "Output"
        PNG["Screenshot PNG"]
        Content["Page Content"]
        Console["Console Logs"]
    end

    BH --> BP
    BP --> CDP
    CDP --> Screenshot
    CDP --> DOM
    CDP --> JS
    CDP --> Input
    Screenshot --> PNG
    DOM --> Content
    JS --> Content

Browser Capabilities

Capability	Function	CDP Method
Screenshot	CaptureScreenshot	Page.captureScreenshot
DOM Reading	ReadBrowserPage	DOM.getDocument
JS Execution	executeJavaScriptAction	Runtime.evaluate
Mouse Events	mouseWheelAction	Input.dispatchMouseEvent
Keyboard Events	pressKeyAction	Input.dispatchKeyEvent
Console Logs	CaptureBrowserConsoleLogs	Runtime.consoleAPICalled
Page Navigation	ListBrowserPages	Target.getTargets

Media Output

Screenshots are converted to protobuf format:

• imageToPNGImageProto -- converts raw screenshot to PNG protobuf
• makeClickFeedbackPNG -- generates visual feedback for clicks
• makeDragFeedbackPNGs -- generates visual feedback for drag operations

Pattern 7: Knowledge Management

Key Functions

Function	Package	Purpose
localManager.scanKILocked	knowledge	Scan Knowledge Items
Document management	document / documentmanager	Document lifecycle
Document parsing	doc	Document content extraction
Notebook support	notebook	Jupyter/notebook integration
Web scraping	web_scraping	Web content extraction

Knowledge Item System

graph TB
    subgraph "Knowledge Sources"
        Files["Local Files"]
        Web["Web Pages"]
        Docs["Documents"]
        NB["Notebooks"]
    end

    subgraph "Knowledge Manager"
        KM["localManager"]
        KI["Knowledge Items<br/>(structured memory)"]
        Index["Index<br/>(searchable)"]
    end

    subgraph "Agent Access"
        Agent["Agent Loop"]
        Context["Context Injection"]
    end

    Files --> KM
    Web --> KM
    Docs --> KM
    NB --> KM
    
    KM --> KI
    KI --> Index
    Index --> Agent
    Agent --> Context

The Knowledge system provides structured memory for agents. Knowledge Items are scanned, indexed, and injected into the agent's context when relevant.

Pattern 8: CEL Enforcement

Key Functions

Function	Package	Purpose
celEnforcer.IsRequestAllowed	sandboxproxy	CEL-based request authorization

What Is CEL?

CEL (Common Expression Language) is Google's expression language for policy evaluation. It is used in JETSKY for fine-grained request authorization.

flowchart TD
    Req["Incoming Request"] --> CEL["CEL Enforcer"]
    CEL --> Eval{"Evaluate CEL<br/>Expressions"}
    Eval -->|"Allow"| Process["Process Request"]
    Eval -->|"Deny"| Reject["Reject with Error"]
    Eval -->|"Condition"| Check["Check Additional<br/>Conditions"]
    Check -->|"Pass"| Process
    Check -->|"Fail"| Reject

Use Cases

• Per-user rate limiting: request.user.rate_limit < 100
• Feature gating: request.feature in user.enabled_features
• Geographic restrictions: request.geo in allowed_regions
• Resource quotas: request.tokens + user.used_tokens < user.quota

Integration with Sandbox Proxy

The CEL enforcer sits in the sandboxproxy layer, intercepting all requests before they reach the backend:

sequenceDiagram
    participant Client as Client Request
    participant Proxy as Sandbox Proxy
    participant CEL as CEL Enforcer
    participant Backend as Backend Service

    Client->>Proxy: gRPC Request
    Proxy->>CEL: IsRequestAllowed(request)
    
    alt Allowed
        CEL-->>Proxy: true
        Proxy->>Backend: Forward request
        Backend-->>Proxy: Response
        Proxy-->>Client: Response
    else Denied
        CEL-->>Proxy: false
        Proxy-->>Client: PERMISSION_DENIED
    end

Pattern 9: Feature Flags (Unleash)

Key Functions

Function	Package	Purpose
UnleashWrapper	unleash	Feature flag wrapper
UnleashWrapperFactory	unleash	Factory for creating wrappers
contextFieldState	unleash	Context field management
InitializeFactory	unleash	Factory initialization
mergeExperimentConfigs	unleash	Merge experiment configurations
setUpUnleash	language_server	Initialize feature flags at startup

Architecture

graph TB
    subgraph "Unleash System"
        UW["UnleashWrapper"]
        Factory["UnleashWrapperFactory"]
        Context["contextFieldState"]
        Config["ExperimentConfigs"]
    end

    subgraph "Feature Checks"
        F1["Feature A: enabled"]
        F2["Feature B: disabled"]
        F3["Feature C: gradual rollout 10%"]
    end

    subgraph "Components"
        Server["Language Server"]
        MCP["MCP Manager"]
        Browser["Browser System"]
        Agent["Agent Loop"]
    end

    Factory --> UW
    UW --> Context
    UW --> Config
    Config --> F1
    Config --> F2
    Config --> F3

    Server -->|"check feature"| UW
    MCP -->|"check feature"| UW
    Browser -->|"check feature"| UW
    Agent -->|"check feature"| UW

Feature Flag Flow

1. At startup, setUpUnleash initializes the Unleash client
2. Feature configurations are fetched from the GetUnleashContextFields API
3. mergeExperimentConfigs combines local and remote configurations
4. Components check features via UnleashWrapper.isEnabled(feature_name)
5. Gradual rollouts use the installation ID for consistent hashing

Pattern 10: Hardcoded Permissions

Key Functions

Function	Package	Purpose
getHardcodedGrants	permissions	Returns hardcoded permission grants
Permission management	permissions	Permission system infrastructure

What Are Hardcoded Grants?

The binary contains a set of baked-in permission grants that cannot be overridden by configuration. These define the minimum set of capabilities available to all users.

graph TB
    subgraph "Permission System"
        HG["getHardcodedGrants()<br/>Always active"]
        CP["Config Permissions<br/>User/team configurable"]
        DP["Dynamic Permissions<br/>Runtime evaluation"]
    end

    subgraph "Effective Permissions"
        EP["Effective Permission Set<br/>HG ∪ CP ∪ DP"]
    end

    HG --> EP
    CP --> EP
    DP --> EP
    
    EP -->|"Check"| Tools["Tool Access"]
    EP -->|"Check"| Features["Feature Access"]
    EP -->|"Check"| Resources["Resource Access"]

Implications

The presence of getHardcodedGrants means:

1. Some permissions are non-negotiable -- they cannot be denied
2. The permission system has a baseline that all configurations build upon
3. These grants likely include basic read operations and system-level access

Subsystem Function Map

Core Server (language_server.*)

Function	Size	Purpose
CreateLanguageServerAndServe	~15KB	Main entry point -- massive initialization
setUpLogging	—	Logging configuration
setUpFS	—	Filesystem setup
setUpFSInjection	—	Filesystem injection (virtual FS)
setUpTracing	—	Distributed tracing
setUpInstallationID	—	Installation ID generation
setUpMetadataProvider	—	Metadata provider setup
setUpServerPortListeners	—	Port binding
setUpUnleash	—	Feature flag initialization
setUpExtensionServerClient	—	Extension server connection
setUpClients	—	Client initialization
setUpWorkspaceManager	—	Workspace management
setUpConversationAnnotationsManager	—	Conversation annotations
setUpMcpManager	—	MCP manager initialization
setUpSystemMcpManager	—	System MCP initialization
setUpCustomizationOptions	—	Customization setup
setUpTrajectorySaver	—	Trajectory persistence setup
setUpGoMaxProcs	—	Go runtime configuration

Agent State (agent_state.*)

Function	Purpose
component.mergeParallelArrays	Merges parallel subagent results
component.mergeTrajectoryUpdates	Combines trajectory state
component.buildFullStateUpdateLocked	Builds complete state snapshot
SubagentUpdateForwarder	Forwards subagent updates to parent

Handlers (handlers.*)

Function	Purpose
InvokeSubagentHandler.Handle	Main subagent invocation
InvokeSubagentHandler.handleTaskMode	Task-mode subagent
DefineSubagentSubHandler.Handle	Subagent definition
ManageInboxSubHandler.handleList	Inbox management
CodeActionHandler.ApplyCodeEdit	Code action application

Serialization (serializers.*)

Function	Purpose
stepToMessage	Converts internal steps to wire format
checkpointSummaryOutput	Generates checkpoint summaries

Git/VCS (git.*, vcs.*)

Function	Purpose
CreateOrUpdatePullRequest	PR management
GitStatusShell	Git status
GetDiffsFromUncommittedChangesConfig	Diff computation
VcsCache.FindCodeiumYamlForDir	Config file discovery
Repository.createPatchForOneUntrackedFile	Patch generation

Utils (utils.*)

Function	Purpose
TrajectoryToCascadeSummary	Summarize trajectory for display
DOMTreeJSONToProto	Convert DOM tree to protobuf
StepToMarkdown	Convert step to markdown

Cross-References

• sdk-test-localharness — How these patterns manifest in the SDK-harness communication
• sdk-test-protobuf — Protobuf messages used by these patterns
• sdk-test-hooks-deep — Hook points where these patterns are intercepted
• sdk-test-auth-chain — Auth subsystem functions
• sdk-test-grpc-protocol — gRPC services and descriptors
• sdk-test-reverse-engineering — Full RE analysis (3305 functions, subsystems)
• sdk-test-deepseek-heartbeat — DeepSeek integration and heartbeat protocol

---

Source: Ghidra MCP decompilation of agy binary. 3,305 .c files in reverse_engineering/language_server_hub/decompiled/. Entry point: language_server_CreateLanguageServerAndServe (~15KB). Core agent loop: cortex_ptrCascadeManager_New (~8KB).