Two days ago, I started using Google Antigravity through Google's AI Pro student offer. As a cybersecurity student, I wanted to use an agent to organize my classes the way I already did with other harnesses.
I quickly missed a reliable way to carry work from one session to the next: the goal, the decisions, and what was still unfinished.
It felt like returning to a workbench with no notebook. Before I could continue, I had to reconstruct where I had left off. That frustration became Antigravity Operator (agyo), my first open-source project.
A session needs a notebook the agent can use
A coding agent is the model plus the vendor's harness—its tools and orchestration—and the user harness around the repository. I wanted a small, inspectable place for the part of that setup I control: project context and session state.
agyo init creates Markdown files in the project:
.agents/session/
├── state.md # goal and current status
├── decisions.md # decisions and trade-offs
└── todo.md # active and pending tasks
The agent can keep those files current. agyo session status summarizes fields and checkboxes it recognizes; it cannot judge whether the recorded decisions are correct or complete. Markdown is easy to inspect and version, but it is still a record that needs human and agent discipline.
From session notes to a local dashboard
The project has grown beyond session scaffolding. agyo session watch follows the local Antigravity transcript and summarizes recent activity. With --tree, it displays subagent launches and inter-agent messages that appear in that transcript. It observes those events; it does not orchestrate the agents.
The visual piece is agyo dashboard:
agyo session watch --tree
agyo session export --format=html --out=session-report.html
agyo dashboard
The local dashboard refreshes every two seconds with session progress, host checks, tabs in the dedicated Chrome profile, and recent activity. The export command produces a Markdown or standalone HTML report. For direct browser operations, agyo browser can list tabs, open or close one, evaluate JavaScript, and capture a screenshot through Chrome DevTools Protocol.
That combination changed how I think about the tool. The session files preserve a working record; the watcher and dashboard make activity easier to see; the export gives the session a portable summary. My favorite addition is the dashboard because it makes the agent's work legible without asking the model to narrate every step.
Guides and sensors—and the limits of each
I use the guide-and-sensor vocabulary from Harness engineering for coding agent users (Birgitta Böckeler, published on martinfowler.com): a guide shapes work before it happens; a sensor checks what happened afterward.
| Concern | Guide (inferential) | Sensor (computational) | Axis and limit |
|---|---|---|---|
| Session continuity | Templates and Antigravity rules | session status checks expected fields and tasks | Behaviour; it cannot judge whether the state is meaningful |
| Host readiness | Repository setup instructions | agyo doctor checks Git, Chrome, DevTools, and other prerequisites | Maintainability; a passing check does not prove an agent workflow |
| Browser isolation | Rule to use the dedicated profile | browser status checks the process and DevTools endpoint | Behaviour; DevTools remains a privileged interface |
| Changes to agyo | AGENTS.md and contribution guidance | CI is configured for go vet, race-enabled tests, builds, and cross-compilation | Maintainability and architecture fitness; it checks agyo, not model behavior |
There is also a Git pre-commit hook, but its current implementation prints the session status and exits successfully. Treat it as a reminder, not a blocking quality gate. A configured check is not automatically an enforcing sensor. These sensors run locally or in CI; the project does not claim continuous production monitoring.
A separate Chrome profile is not a sandbox
agyo browser start launches Chrome with its own user-data directory and a local debugging port. That helps keep agent browsing separate from my personal Chrome profile. The DevTools endpoint is still privileged: a process that can reach it may control that browser session.
The dashboard binds to 127.0.0.1 and displays session details, browser tabs, and activity. I keep it local and avoid putting secrets or personal data in session files. On headless Linux, the operator may use Chrome's --no-sandbox flag; that disables a browser protection and should be treated as an explicit environment trade-off. None of these features creates a complete sandbox for agent commands or web content.
The CLI is written in Go and embeds its templates, so running it does not require a separate Python or Node runtime. Browser automation still requires Chrome or Chromium, and some MCP setups may require npx. The repository is now at v0.4.1, with CI configured for Ubuntu and macOS and a release workflow for five OS/architecture targets.
What I learned by building it
I began with a personal study problem, not a plan to build a platform. The first useful step was making session state visible and easy to resume. From there, I added tools around the same workflow: inspect activity, see the isolated browser, and export a report.
agyo is a community project, not an official Google product. The student offer gave me a reason to try Antigravity; the missing session workflow gave me a reason to build. The README still talks bigger than the CLI: the useful product is the session notebook and the local dashboard. Phrases like autonomous OS or safe sandbox go past what the sensors actually enforce. I also shared the project in the Google AI Developers Forum.
If you use coding agents locally, what would help you most: persistent session state, a live activity view, visibility into subagents, or a separate browser profile?
