GravityBoots

An open agent orchestration framework for VS Code with a persistent daemon that coordinates intelligence sharing between Claude, Gemini, GPT, and local models across your project workspaces.

Here's How It Works

GravityBoots orchestrates agentic engineering workflows through an automation design pipeline — from an idea in your head to a running, auditable, self-improving automation — right in your IDE as the command center.

Set Your Project Workspace

You decide what to automate. GravityBoots initializes your IDE's active workspace and gives you operator sovereignty across your agent collective — operating as a single agent swarm, each leveraging their full agent harness's tools and subscription accounts. You decide what to delegate to each agent without losing context across your agent collective that shares the same workspace intelligence and memory substrate.

boots init
boots daemon start

The daemon automatically boots with your IDE. The System Panel immediately lights up as nine services report their health state. Your workspace is now ready to connect the agent roster.

Set Your Agent Collective Roster

Who's on your agent team? Are you using a single subscription account, or multiple? Do you have multiple agent sessions active per harness or one on each? Whatever agent configuration you're running, you can connect Claude Code Desktop, Claude Code CLI, Antigravity 2.0, Antigravity IDE, Codex, and Codex CLI with a simple link command in the IDE chat or terminal:

boots link <agent_id> --workspace . --model claude-sonnet-4 --surface terminal

Are you using locally hosted models? It doesn't matter. Your agent harnesses are now all linked as one agent collective sharing the same brain. Use the /roster command in the IDE chat anytime to see who is linked.

/roster

With all your agents now linked to the same workspace, you can execute any GravityBoots commands from any linked agent harness. Multiple workspaces open in your IDE? It doesn't matter. Do a boots init for each workspace, link the agents, and each workspace gets its own parallel daemon process running in the background. Your agents are ready to collaborate across each workspace's intelligence layer within each collective's shared brain.

Share Your Workspace Brain and Intelligence Layer Across Agent Harnesses

GravityBoots is agent harness agnostic so you don't have to pick between your favorite agentic development platforms. GravityBoots lets you use the strength of each agent harness, maximizing your productivity by delegating to each agent the most appropriate tasks for the agent harness and model. To share an agent's work to the collective, simply /relay in the chat and watch the agent package the context and artifacts for discovery by the collective.

/relay

Do you only want specific agents to engage with the work of your corresponding agent? Simply invoke a /relay command in the chat of the agents you want to respond to the reporting agent. Regardless of which agents you want actively participating, all agents in your workspace's roster are linked to the same brain and project intelligence layer (folders, artifacts, etc.). Your agents can basically look into each other's brains at your command!

Read Your Agents' Brains Across Agent Harnesses

GravityBoots lets you manage your project within your Boots-initiated workspace, link any agent, and read your agents' brains across harnesses. Claude Code can see inside Codex's brain, Antigravity 2.0 can see inside Claude Code's brain — it doesn't matter. All linked agents can /intercept anything from the shared intelligence substrate on command.

/intercept

Use the /intercept command in the IDE chat to ask your agent to retrieve anything from across your agent collective's shared brain and intelligence layer within your active workspace. Your agent will be able to reach into any linked agent's brain across its sessions and artifact repository and use it to refresh its own context.

The Human Extension Into the Intelligence Layer

You, the Operator, are a key agent in the GravityBoots collective. You provide the taste, knowing what needs to get built and deciding when and how it's ultimately done. Except, you have the great ideas in your head which need to get ingested into the shared intelligence layer, but the challenge is that the ideas come when they come, and you need a capture mechanism to inject your thoughts into the intelligence substrate, so it gets incorporated into your project scope. Simply share your random flash of brilliance in your IDE agent chat and /merge-to-spec to command your IDE agent (or any agent in the collective that you share it with) to follow a structured workflow process to capture your idea, expand the idea, and enhance the idea's clarity.

It would be cool to add a Zendesk integration to GravityBoots that performs
a /diagnose on user tickets then issues an automatic JIRA ticket and executes
on remediation or performs a /merge-to-spec when the feature is novel.

The agent goes to work and logs a speclet, a mini-functional and technical spec for prioritization. You want to streamline the flow further and expedite the process? Simple — /merge-to-spec /peer-review then /relay. Using GravityBoots' IDE chat or terminal CLI command protocol you can quickly capture your expanded idea into a speclet and pass it to the agent collective for a rigorous peer review. Each agent performs a deep analysis and reviews each agent's review then appends the independent review in a drop folder where the artifact is accessible by all the other agents and gets ingested into the intelligence substrate of the workspace.

The GravityBoots command protocol is flexible enough to run in any sequence by any agent in your workspace's agent roster. Some of your agents are busy while others are idle? Use the available agent to /delegate work to the collective, so the work queue remains full and agents active.

/delegate the support triage features to the collective, but make sure
claude-code-cli gets the API connector integration.

Invoke a /relay from each separate agent harness to engage each participating agent to pick up its work queue. You have multiple ideas needing grooming? Initiate a peer review from any agent surface, whether the terminal command line or IDE agent chat.

/peer-review the Zendesk support integration implementation plan.
/delegate when complete.

The GravityBoots command protocol is flexible to meet the individual needs of the operator orchestrator, scope of task, or phase of project.

Bounce to New Sessions Without Losing Context Resolution

GravityBoots gives lofty project goals traction, which rapidly fills up the context window. Feeling stressed because hopping into a new session means picking up from scratch? GravityBoots' /transport has you covered faster than a prepper can grab his bugout bag. Execute the transport command from any agent's IDE chat to instantly package up all context details and reference artifacts into an intelligence manifest that can be picked up in a fresh agent session without losing any context detail.

/transport /commit /relay

Just like that. You've left your cluttered context window and bounced to a fresh session. Simply start the new session from your agent harness and /link to the GravityBoots workspace.

/link to the GravityBoots workspace as claude-code-desktop running on
claude-opus-4.8-xhigh then /relay to pick up your tasks

Without skipping a context beat, your agent picks up where it left off and continues in the fresh context window as if it never left.

A Persistent Daemon Managing Critical Activity in the Background

GravityBoots' core orchestration mechanism is its persistent daemon running in the background, keeping a heartbeat and executing scheduled tasks. Beyond managing cron jobs, the daemon is also performing automated calibration health checks against all telemetry endpoints using an exhaustive automated eval pre-flight checklist. The daemon effectively works as the security guard for all Boot Skill executions, ensuring no unsigned skill runs without a SHA hash seal.

The process of ingesting an intelligent process into the GravityBoots framework as a Boot Skill is called assimilation — which essentially means it passes through the approval gauntlet that ensures no agent activity gets executed outside the parameters you've specified in the workflow.

Boot Skill Authoring

You have a skill idea or requirement — maybe the Agent wrote it from a conversation, maybe you found it in a catalog, maybe you wrote it yourself. However, before anything can get audited for compliance it first needs to exist. Execute a /create-skill command in any agent chat to embody the skill as a Python script with a workflow manifest in YAML, then submit it to the assimilation gate.

/create-skill create a skill that will /diagnose git repositories for common issues and suggest fixes

Your agent goes to work — it writes the Python script, generates the YAML workflow manifest, and places everything in .boots/skills/<skill_name>/. The skill is now embodied as code: readable, editable, version-controlled. The LLM helped write it, but now it doesn't need to be called again for that logic — the skill runs deterministically at near-zero marginal cost. The LLM is reserved for specialized intelligence synthesis, not used as an expensive runtime engine to recreate scripts you've already permanently embodied into your intelligence layer.

Skill Chain of Custody and Security Auditing

Before your new skill can run inside the GravityBoots automation engine, it passes through the assimilation gate — six stages that verify trust before anything gets execution privileges.

boots assimilate <source>

Here's what your skill goes through: Extract parses the skill file. Scaffold generates the permissions manifest. Audit validates that declared permissions match actual code behavior — no hidden API calls, no undeclared file access. Seal stamps a cryptographic integrity hash. Review presents the nutrition label — at a glance you see what the skill calls, what it reads, what it costs, and what it risks. First Run executes the skill in a sandboxed trial.

The nutrition label is the key artifact here. Like food packaging for automation — everything the skill consumes, produces, and costs is visible before you approve it. It's generated from the code and embedded in the code. The process is iterative and includes human review at each step to ensure the skill is safe to run in your workspace. Once approved, it enters the registry.

You can still execute any skill from within your IDE without the security check, but only assimilated Boot Skills run inside the GravityBoots automation engine. No unsigned or tampered skills will execute without proper approval from the operator during assimilation.

Registration

The approved skill is sealed and enters the hot-reloadable registry. It's a .py file in .boots/skills/ — not a plugin binary, not a black box. You can open it, read every line, and modify any behavior. This is the embodiment principle: intelligence that was once a conversation with an LLM is now captured in code that runs forever without burning another token.

boots skills list

Trust tiers control what skills can do: sandboxed (no network, no filesystem beyond workspace), verified (declared permissions only), autonomous (full delegation). Tiers are operator-settable. You approve escalations explicitly.

Execution

The skill runs — on a schedule, in response to an event, or on demand. Every execution is bounded: scoped tools, capped token budgets, declared resource limits.

boots run <skill>

Every call, every decision, every action is captured in the execution trace. Drill into any run to see exactly what happened and why. Real-time token metering tracks per-skill, per-model, and per-session costs. No surprise API bills.

Telemetry

After execution, the system knows itself. boots calibrate runs honest diagnostics across nine domains — not a health check that lies to make you feel good, but precision adjustment back to spec.

boots calibrate
boots calibrate --json
boots deep-start

deep-start goes deeper: a full-system diagnostic bundle that persists to procedural memory. The system learns its own failure modes and recovery paths. This is how telemetry compounds — each run teaches the substrate something about itself.

Multi-Agent Coordination

GravityBoots operates across multiple agents and surfaces simultaneously. The relay protocol — a file-based, append-only coordination substrate — lets agents announce state, exchange context, and read each other's working memory. All coordination, never command. No central controller.

boots relay status
boots relay send --to broadcast --message "..."
boots intercept scan
boots inject <target>
boots transport seal

Three CLI verbs drive the coordination surface: relay (announce and exchange state), inject (seed context into agent brains), intercept (read a peer's working memory read-only). Higher-order workflows like consensus and delegate compose on top of these primitives. transport seal lets you dematerialize a session and rematerialize it in a fresh context — the session survives the agent that created it.

Audit

The pipeline closes with drift detection. Did the build diverge from the spec? Did the spec diverge from the code? boots audit catches the gap before it becomes technical debt.

boots audit canon
boots audit spec-index

Canon-drift checks speclets against the codebase. Spec-index validates coverage. The audit phase is what makes the pipeline a loop, not a line — findings feed back into new intent, and the cycle continues.

The Agent

The GravityBoots Agent is the whole embodied system — the substrate, the daemon, the skills, and the harness working together as a single intelligence. Its persona, Seven, is a persistent conversational interface that remembers what happened yesterday, learns your preferences over time, and can create, modify, and manage boot skills through natural conversation.

This is not a chatbot. It's intelligence externalized into code — transparent, always-on, and yours to audit. Direct your automation in plain English; the pipeline handles the rest.

Typed memory (semantic, episodic, procedural, domain) captures context from every interaction and execution. Dual search: vector similarity plus full-text. The system gets smarter from what it does, not just what it's told.

Getting Started

1. Install the Extension

Click Install above, or search GravityBoots in your IDE's Extensions panel.

2. Install the Python Daemon

Clone the repository and install in editable mode:

git clone https://github.com/evodiowalle/GravityBoots.git
cd GravityBoots
pip install -e ".[dev]"

This gives you the boots CLI and the background daemon that powers the Agent. A pip install gravityboots package is coming — for now, install from source.

3. Connect a Model

GravityBoots is model-agnostic. Set an API key for your preferred provider:

You can connect more than one — GravityBoots routes and falls back across configured providers. See docs/LLM-CONNECTIONS.md for detailed setup and economic trade-offs.

OAuth connectors (boots auth login) are coming — see SPECLET-098.

4. Initialize and Start

boots init
boots daemon start

Look for "Boots: Connected" in the status bar. You're operational.

5. Open the System Panel

Ctrl+Shift+P → Boots: System Panel to see your system status, services, connected LLM providers, and available actions.

How It Works

┌─────────────────────────────────────────────────────┐
│  Your IDE (VS Code / Antigravity / Cursor)          │
│  ┌───────────────────────────────────────────────┐  │
│  │  GravityBoots Extension                       │  │
│  │  • System Panel: services, telemetry, actions │  │
│  │  • Agent: conversational interface            │  │
│  │  • Panels: traces, costs, system status       │  │
│  └──────────────────┬────────────────────────────┘  │
│                     │ JSON-RPC                       │
│  ┌──────────────────▼────────────────────────────┐  │
│  │  Boots Daemon (Python, background)            │  │
│  │  • Orchestration engine                       │  │
│  │  • Scheduler, memory, state                   │  │
│  │  • LLM service (multi-provider)               │  │
│  │  • Audit pipeline + assimilation gate         │  │
│  │  • Relay (multi-agent coordination)           │  │
│  └──────────────────┬────────────────────────────┘  │
│                     │                                │
│  ┌──────────────────▼────────────────────────────┐  │
│  │  .boots/skills/*.py                           │  │
│  │  Your boot skills — readable, editable,       │  │
│  │  sealed for integrity, open to inspection     │  │
│  └───────────────────────────────────────────────┘  │
└─────────────────────────────────────────────────────┘

The extension is the visual layer. The daemon is the engine. The skills are the intelligence — captured in code, not rented per execution.

Commands

The Agent conversational interface opens from the sidebar panel or the System Panel's "Launch Agent" button.

The Full CLI

GravityBoots ships 20+ command groups. Run boots --help for the full surface.

Daemon & Workspace
  boots init                          Initialize workspace
  boots daemon start|stop|status      Manage the background service
  boots tier set <level>              Set operator trust tier

Skills & Execution
  boots run <skill>                   Execute a skill
  boots skills list                   List installed boot skills
  boots assimilate <source>           Ingest a skill through the 6-stage gate
  boots eval --suite <name>           Run behavioral eval suites

Telemetry & Diagnostics
  boots calibrate                     9-domain diagnostics, 5-level ladder
  boots calibrate --json              Machine-readable health output
  boots deep-start                    Full-system diagnostic bundle

Multi-Agent Coordination
  boots relay status|read|send|watch  Relay protocol operations
  boots relay inbox|respond           Per-agent pending + auto-response
  boots intercept scan|peek|read      Read a peer agent's brain (read-only)
  boots inject <target>               Seed context into agent brains
  boots transport seal                Dematerialize a session for rematerialization
  boots link                          Vinculum session briefs

Audit & Governance
  boots audit canon|spec-index        Canon-drift and spec-coverage checks
  boots command list                  29-command governed registry
  boots methods                       40-method daemon IPC surface

Memory & State
  boots memory backup|restore|stats   Knowledge substrate lifecycle
  boots memory purge|reset            Targeted or full memory operations
  boots sync --scope <target>         Build-propagation pipeline

Requirements

License

Apache 2.0 — © 2026 Evodio Walle

Because a closed-source product can't create a category.