Powered by Claude Agent SDK & GKE Standard

Dynamic AI Agent
Orchestration Platform.

Nova dynamically generates, executes, and coordinates AI agents. MicroVM-level isolation, stateful context, and multi-layer network security—built for modern, safe engineering.

# 1. Launch an agent job with a single command
nova run -p playground "Implement the new billing API endpoint"
{"instance_id":"agent-5b8f2","status":"Running","project":"playground"}

# 2. Send a follow-up prompt to a waiting agent
nova prompt agent-5b8f2 "Add error handling for invalid input"
{"instance_id":"agent-5b8f2","status":"Running"}

# 3. Check job status and list running agents
nova job list -p playground --limit 5
{"jobs":[{"instance_id":"agent-5b8f2","status":"Completed","model":"claude-opus-4-5"}]}

Engineered for Absolute Security.

A resilient, stateful, and defense-in-depth foundation for running autonomous code agents in production.

Dynamic & MicroVM-Isolated Execution

On-demand agent creation via Kubernetes Jobs. Each AI agent runs inside a dedicated MicroVM powered by Kata Containers and Cloud Hypervisor (nested virtualization). This provides uncompromising hardware-level boundary protection, ensuring absolute workload isolation and security from the host OS and other running pods.

Agent-A
Agent-B
+ N
Each agent gets its own MicroVM — no shared kernel, no shared filesystem

Stateful Checkpoints with Resume & Fork

Every agent turn creates a checkpoint persisted to GCS. From any checkpoint, you can Resume to continue where the agent left off, or Fork to branch into a parallel execution path—like git for agent state. All commits are signed and submitted via Pull Requests; agents never push directly to main.

Resume Turn 1 Turn 2 Turn 3 Fork Turn 5 Turn 6 Turn 7 Turn 5' Turn 6' Turn 7' main execution forked branch Every turn = GCS checkpoint Resume from any checkpoint · Fork into parallel paths

3-Layer Network Defense

Defense-in-depth with three distinct security layers. Network Policy controls L3/L4 pod-to-pod traffic. FQDN Policy restricts external egress to allowlisted domains only. Authorization Policy enforces L7 request-level access control per service identity.

Separately, Istio's ExtProc (External Processing) filter dynamically injects short-lived credentials at the mesh layer—agents never hold long-lived tokens directly.

L3/L4  Network Policy L4/L7  FQDN Policy L7     AuthZ Policy

Fine-Grained Authorization

Powered by OpenFGA with Terraform-managed hierarchy. Permissions inherit through a folder tree (folder:root → folder:nova → folder:playground), so granting access at any level cascades down to all child resources.

Relationship Tuples
# User → project folder ownership
resource "openfga_relationship_tuple" {
  user   = "user:yanolab@mercari.com"
  relation = "owner"
  object  = "folder:playground"
}
Permission Tuples
# SA → spawn-agent permission
resource "openfga_relationship_tuple" {
  user   = "service_account:claude-agent@..."
  relation = "owner"
  object  = "permission:spawn-agent"
}

Multi-Agent Orchestration by Agent Chaining

An agent analyzes the task context—such as a new GitHub Issue—and autonomously decides which specialized agents to spawn through Agent Chaining. Each spawned agent completes its work, and its output (e.g., a PR) triggers the next agent via GitHub Webhooks. The result is an adaptive, branching workflow that scales from simple fixes to complex multi-agent engineering pipelines.

DESIGN REVIEW New Issue Coordinator "SWE + Architect" SWE Agent Architect Pass? No revise design Yes IMPLEMENTATION Coordinator "spawn SWE impl" SWE Agent Create PR webhook CODE REVIEW Coordinator "assign reviewers" Code Review Security QA Agent Pass? Yes Merge No fix & re-review Webhook Spawn Review loop

Knowledge Graph RAG

Agents query a LightRAG-powered Knowledge Graph built from GitHub Issues, Pull Requests, and documentation. Before writing code, agents understand past decisions, related implementations, and design rationale—enabling context-aware choices instead of starting from scratch every time.

Issues PRs Docs Knowledge Graph query Agent "Similar fix in PR #142..."

Event-Driven Agent Workflows

External events from GitHub, Linear, and Agent lifecycle automatically trigger new agent jobs. Build sophisticated automation pipelines: a merged PR kicks off a documentation agent, a new Issue spawns a triage agent, or an agent's own completion triggers the next stage. Combine these primitives to create self-learning evolution workflows and Agent Experience Scoring—agents that improve themselves based on review feedback and outcome metrics.

GitHub Linear Agent Event issue.opened pr.merged · job.completed Event Router match → dispatch Triage Agent Docs Agent Scoring Agent feedback loop — agents emit events that trigger new agents

Project Shared Memory

Every agent in a project reads from and writes to a shared memory layer persisted across sessions. Coding conventions, past mistakes, architectural decisions, and team preferences accumulate over time—so agents learn from each other. Teams collectively nurture and evolve their agents simply by working with them, building institutional knowledge that every future agent inherits.

A Dev A B Dev B C Dev C Agent 1 Agent 2 Agent 3 Shared Memory conventions · feedback decisions · patterns evolve agents get smarter

Nova CLI — Universal Integration Interface

The nova CLI turns the platform into a composable building block. Call it from CI/CD pipelines, cron jobs, Slack bots, or any system that can run a shell command. And because agents themselves have access to the CLI, Nova can call Nova—agents autonomously spawn, coordinate, and communicate with each other through the same interface humans use.

External Integration
# CI/CD: auto-fix on test failure
nova run -p myproject \
  "Tests failed: fix $ERROR"

# Slack bot: on-demand agents
nova run -p myproject \
  "$SLACK_MESSAGE"

# Cron: scheduled audits
nova run --preset Auditor \
  "Review open PRs for staleness"
Agent-to-Agent via CLI
# Agent A spawns Agent B
nova run -p myproject \
  "Implement the API from design.md"

# Agent A sends follow-up
nova prompt $CHILD_ID \
  "Add rate limiting middleware"

# Agent A checks result
nova job get $CHILD_ID
CI/CD Slack Cron nova CLI Nova Platform Agent A Agent B nova run

Built-in Developer Tooling

Agents come pre-equipped with a full development environment for real-world engineering tasks.

Code Server

Browser-based VS Code via per-instance HTTPRoute. Live debugging, terminal access, and file editing directly inside running agent pods.

Auto Dependency Clone

Dependency repositories are automatically cloned alongside the target repo. Agents browse upstream source, trace APIs across repos, and understand cross-service contracts.

Pre-installed Toolchain

mise, gh CLI, jq, pytest, Playwright—ready out of the box. Agents run tests, capture screenshots, and interact with CI/CD without setup overhead.

Two-Layer Architecture.

Separation of concerns between infrastructure orchestration and secure multi-step LLM execution.

External Layer
User Request / Webhooks (GitHub, Slack, Linear)
↓ GKE Gateway API (Strict HTTPRoutes)
System Layer
API Gateway (Hono, Node.js + OpenFGA Authorization)
↓ Orchestrates secure Kubernetes Jobs
Infrastructure
GKE Standard (nova cluster + Network Policies)
↓ Mounts emptyDir & Syncs GCS Context
Agent Layer (MicroVM)
Kata Container Worker Pod (Claude Agent SDK + Token Injection)