I'm not sure why, exactly. But I don't pay any attention to news like this from Google. I don't know if there's some marketing which has me writing them off or if it's something else.
What I do know is that the Gemini integration into sheets is surprisingly incapable of performing basic tasks. This is where I expect Google to really shine. I expected Sheets + Gemini to be magical like Google Photos was. I hardly try anymore besides some basic math questions when I don't feel like inputting the formula myself.
The other thing I know is Google's propensity to sunset products. For many things, it's not a huge deal. And it may not be for this. But, why? When there are alternatives - both open and closed.
I have been ignoring GCP Account folks forever and I previously posted about how useless those motherfuckers are and how I tell them I am NOT going to speak with them again, ever.
Recently, they went to our Co-President and he, similarly and thankfully, ignored them. So what did those fucking assholes do? They went to our board members and got one of them to make me have to do a bunch of needless work responding, in depth, to one of their LLM-generated decks that is generic and doesn't at all consider anything we're doing, a good bit of which was centered around agentic-foo bullshit.
* Conversational Client Analytics in Looker: Deploy natural language conversational data discovery
* AI Agent Development Kit Core: Construct autonomous analytics agents with Google Agent Development Kit
* Generative Search Performance Tracker: Track brand visibility across AI answer engines using Gemini 3.1 Pro.
* Autonomous Retail Media Campaign Orchestrator: Automate retail media catalog enrichment and ad optimization with Gemini
* Agentic Workforce Collaboration in Workspace: Deploy Gemini Enterprise wall-to-wall for automated agency pitch creation.
---
They're exhausting. We already do most of these things better than they suggest (really; who the fuck thinks 'conversational analytics in Looker' is exciting in 2026? No one capable, that's for fucking sure) and it's clear that some MBA motherfucker just decided to use Gemini to push a bunch of garbage that is ignored by those who are technically and financially apt and elevate to the persons who don't know shit from shinola in order to try and get some consultant in the door to sell shit that companies already have and are doing.
It's fucking absurd.
I hope someone with some pull over there reads this and slaps this shit down and fast. It's really fucking annoying and needs to stop 4y ago.
On your Sheets + Gemini integration point, I've genuinely tried to give the Gemini integration into Google Docs & Google Sheets a chance. It is so incompetent that it is fully useless to me. I have not gotten a single correct solution each time I tried to use it, even something I consider table stakes. I often write my work reports in Vim in Markdown format, but they need to go to the corporate Google space. No matter how hard I tried, no matter how many prompts I have, it was completely unable to manage the command to "convert the Markdown format markers into native Google Docs markers". And I want to note, this was 2 pages of extremely simple Markdown with no "advanced" patterns, like tables or quotes, I think all I used was heading-marks, bolding, italicizing, and code blocks. This is something I would expect even GPT 3.5 to succeed in, and even more so Luna, but somehow it destroyed the formatting throughout half the document. This leads me to believe that they apply the absolute cheapest model they have there, or they have the model a harness which can barely be considered working.
I found it absurd when I found out that they suddenly made this Gemini integration an additional paid plan recently, there's absolutely no way I can consider that in good faith.
sorry if this isn't it. there is a hidden global setting that defaults to off that lets docs play nice with markdown. it's in file > settings i think. super annoying even if this is no help
Not sure if this is connected, but I've found Gemini pretty hopeless within its own notebooks. I've been doing some job applications, and added cv and docs into a notebook. I then create a new chat to say "here is a job description, help me write a cover letter" or some such.
After about 3 messages in any given chat, a follow-up to "rewrite that with a more friendly tone" will result in a letter for a completely different job from another chat within the notebook.
There is an assumption that AOSP is how OEMs receive Android updates from Google. However I am not sure that is the case. GrapheneOS is perhaps a minority player due to lack of hardware which they can use to get into a partnership agreement and advanced access.
My understanding is that this one was never really "official", and that the guy who released it wasn't following standard procedures. That's not even the official Google github account.
It depends on where they decide to go with it, I guess.
Kubernetes, Go, Tensorflow, Chromium, gRPC are some examples that obviously went incredibly well.
Yeah I'm actually less hesitant to try out Google open source projects than I am new Google products. I have no idea if this is accurate or just my impression, but I feel like I've been burned by the "killed by Google" meme almost exclusively on their software products, whereas there are plenty of open source efforts from Google that I think of as stable.
In addition to the ones you listed, I'd add the V8 runtime, Jax, Protobuf. Even some of their projects that wound up declining in market share (Angular, Tensorflow--both losing share to projects that wound up at Meta, ironically) are still actively maintained and pushed.
But I'm sure there's also a huge graveyard of open source projects they abandoned that just never hit my radar. Still, at least with their open source stuff, you can fork in the worst case.
Or if it becomes commercially valuable, then you can expect Google to take a third direction (embrace, extend, extinguish) : a la their current approach with android
I don't think that phrase means what you think it does. That only makes sense when there exists an open standard which a company builds an implementation for. Android was built from scratch and there was no standard.
I'd evaluated both Google's Agent Substrate (that underlies Ax) and their Scion project. I really enjoy how Scion operates with existing tools really well. Ax/Agent Substrate is much more a greenfield independent effort, it's own thing.
I think Scion has so much more mature a disosition: you could write OpenCode plugins that enhance the runner, and use that locally, and use it in Scion. With Ax/Agent Substrate, you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate. I do think their actor model is pretty neat! It's neat having the agent have such primacy! But it feels so much less integrative, is such it's own thing. Scion, to me, is much more interesting an effort, that similarly helps scale out agentic workloads.
> you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate
The website makes me think the contrary: It is described as “low opinion” and explicitly mentions that the running tasks don’t even have to be AI agents. Can you explain in what ways you’re more locked in than the website suggests?
> You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443).
> make deploy AX_IMAGE_REPO=<your-registry>
> This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.
Indeed, there's much less, and that's lower opinion. But you also can't run normal workloads. You have to build for Agent Substrate / Ax.
What's nice about Scion is that it runs existing systems. It runs Claude, it runs Code, it runs Pi, it runs OpenCode. By contrast, "low opinion" means build something new, from scratch, atop this brand new platform.
Note that both of these are designed to work at some scale. Agent Substrate specifically is somewhat coupled to Kubernetes, is my impression, but honestly that's fine with me. Scion can run on Docker, Podman, Apple Container, Kubernetes, or Cloud Run. It's good that we be able to run these relatively quickly, but (especially with LLM assistance) the idea of running some substantial dependencies / services to run these things does not seem like a bad thing. If anything, I'd prefer having some well known services underfoot to these all being recreated afresh.
The reality with releases like this is that I'm 90% sure most Google bigwigs have never heard of it, and it's misleading to label it as "Google's" in the title.
Yes, it was developed by Google employees, that does not imply it has the full backing of Google, or Deepmind, or GCP. Notably, the website doesn't seem to claim this either.
Fair enough, I missed that specific line. The point still stands that I wouldn't expect this to have GDM leadership backing. (If you're planning to use this at all, that matters for how much faith you should have in the product.)
Substrate is in the process of being donated to the CNCF as a vendor-neutral common ground (similar to K8s). (The agent-substrate org is currently Google's, but that will change).
I have no insider knowledge but https://x.com/rakyll is working on it and she is tweeting about it and I got the impression there is a quite a team behind it. It looks like an effort in GCP.
Yes, and one thing to understand about Google is that no AI framework or tool is guaranteed to survive unless it has the explicit backing of Google Deepmind.
"Effort in GCP" is a red flag. (See Gemini CLI, which was shut down in favor of Antigravity CLI.)
Disclaimer: I'm one of the co-creators of this project.
AX is a layer that is closer to job orchestration, it's NOT an agentic framework. We use Antigravity for a few generative features but are abstracting away some of these components so anyone can bring their own.
Google compute services are under GCP and I work on Kubernetes.
Yeah, anyone should think of this as an experimental side project that may be forgotten in 15min and make careful decisions about using them in production environments.
We have used a few of Google's (smaller) open source projects, and in the last 2-3 years most of them are getting fewer updates if any updates at all. Some became very bad tech debt and we had to spend a lot of time migrating them.
Of course, that is the nature of open source projects (written in the license terms), and there is nothing to complain. But it's important to point out these days Google's open source project are not any more trustworthy than a one man's project in terms of support and maintainability. Personally I would stay away from them as far as possible. Especially if you look at what happened to Android, Gemini CLI etc.
(To be honest, even if it were officially supported by Google, that barely means anything. https://killedbygoogle.com/)
I really don't think any of these SOTA labs are doing agentic engineering correctly. Skills are the universal language of all agent harnesses. If you abstract the taste and prescription out of the skills and into guidance docs, then leave the skills as basically just workflow scaffolding, you can build task-specific workflows that work with any harness like Claude Code, Codex, Antigravity, etc. Technically, you only really need 2 skills, work and review, and with these you can build infinitely complex workflows including self-improving loops. I built this out and have been using it for months. It's been extremely nice. https://github.com/DanMcInerney/orchflows
Overly complex; yaml files, heavy framework. Same mistake as Claude Code's Dynamic Workflows. Why not just use the dehydrated skills as the workflow skeleton and use custom guidance docs to hydrate the skills with taste and preference depending on the domain of the task? Now you can build a library of small workflows that compose into larger workflow, and you can export any workflow as a single skill to be used in other harnesses. For example, I have a code.md. It's really small, just a bit of taste preference. If I'm using it to hydrate orch-work for coding tasks, then maybe I want to create a code.api.md which hydrates for further specificity if the task is about creating APIs. Then when new models come out, I can just delete code.api.md and leave it as code.md for /orch-work to read from within a workflow because newer models won't need as much prescription.
The OP is not really a workflow manager, it’s a workspace manager that facilitates creating controlled environments where your skills can run. Everything you said is compatible with (and complementary of) the OP project.
With that said, I’ll somewhat disagree with you. I’ve been down the path you’re talking about and while it is incredibly flexible and powerful, it became too difficult to maintain, and too inconsistent between workflow runs, and a pretty hefty waste of tokens to use AI on things that could instead be handled by deterministic scripts. I ended up creating an orchestrator for myself that uses skills as the primary way to tell agents how to execute a step in a workflow, but also directly orchestrates running scripts and managing state in a deterministic way rather than leaving it all up to agents.
You really, really need different skills depending on the model.
If you are using Qwen 27B you need very prescriptive skills.
If you are using Astra you usually want very minimal skills (because it will follow them but be unnecessarily constrained in some contexts)
If you are using Fable then it depends - it will take the skills as general guidelines but ignore them a lot more than Astra does. Sometimes this is good, sometimes not at all.
Right. That's what modular guidance documentation is for. You could have astra.code or qwen.code.api. All reusable in different workflows. Prescription doesn't belong in the skill itself.
Future of platforms is operators in k8s to abstract the developer need to the underlying systems. On local it maps to kvm, on gke it maps to their stuff, on AWS to RDS. It's "interfaces" on a platform level so devs can just ask for a thing.
Overall I agree though, this is a bit of an abuse of that concept.
EDIT: I'm sure op is familiar with this workflow but I'm being overly verbose to clarify what I think they mean and my thoughts.
Google already has gVisor running in Kubernetes as a product (GKE Sandbox), which provides the security guarantees necessary for secure sandboxes (regular k8s isn't great in this respect). They also have pod snapshots running at scale (which run on gVisor), so you can spin up process(es) and snapshot the memory and fs of a pod at a point in time, ship it to a blob in GCS, and then rehydrate those snapshots very quickly (or fork into new instances), which allows for the fast/cheap startup and suspend times and the instant scaling they advertise here. One of these snapshots can be created in one cluster and spun up in another.
Not sure if this is an extension of tech they already have had in their systems, but I've experimenting with it to build my own orchestrator and it's been a pretty neat set of tools and abstractions so far.
I can launch Astra to deploy changes to my homelab via creating Forgejo issues from my phone. That kind of system is pretty hard to set up without kubernetes.
Even if you confine yourself to a dev workstation, having 5 agents concurrently building testing deploying code makes your computer loud and/or hot.
I have been happy with Google's Antigravity harness and Jules so looking forward to playing with this. Thanks for sharing. Simultaneously I am looking to also revisit local offline models.
While I feel like I have a decent understanding of the model landscape I'm feeling a bit lost at which agentic harness to leverage for local models. Hermes, Cline, Aider, Qwen Code, Goose, Pi, OpenCode, something else? I live in the terminal so Desktop UX is a bonus but not a must have.
Can I modify the antigravity settings/program to point to a local model? Where should I spend my energy?
What's going on with Goose? Seems like Block donated it to some consortium; I can't tell if that's a good signal or a bad one. With so many "contenders", if Goose is going into maintenance mode it'd be helpful to know.
I'm stuck on Windows, so oh-my-pi has been really nice. The others I've tried such as kilo do alright but tool calling can mess up a bit.
Only complaint is that connecting the agent harness to my local model took more work getting configured right than I'd like, but that's been true of most harnesses I've tried as well. Most assume you're using a cloud model and local model configuration is a bit of an afterthought.
I tried many of these pi extensions but they have tons of paper cuts. Don't remember which one had which issue but here are some I ran into:
* commands run by me (! prefix) are also sandbox blocked
* agent has no way to _request_ unsandboxed execution (e.g. if `kubectl whatever` is rejected by the sandbox, the model should have the chance to request permission)
* does not understand shell composition patterns (e.g. if `git status` is allowed and `git log` is allowed, then `git status && git log` should be allowed automatically)
* sandbox only supported on mac or linux. not both
All of that can be fixed by yourself. That's certainly the spirit of pi. But if you want strong defaults and batteries included (like omp promises) then that's just annoying.
- instruct model to write a markdown file with a phased plan to implement whatever feature or change I want
- start a new context, instruct model to implement one phase of the file
- review changes manually, then start a new context and have it do the next phase
- repeat as needed
I've never seen omp touch a file outside of the directory I start it up in, and the few times where I've been unhappy with a change git has been there to revert.
This could easily be a case of survivor bias but I've not had an issue with letting it go yolo yet.
Sometimes agents create huge half-minified one-off python/bash scripts to do some data processing. I'd prefer to neither review nor yolo these. Sandbox restricts reads/writes to designated directories, so at least there's no `rm -rf /` in there.
Since local models are largest constrained by context window you want to have a tiny system prompt. I know Hax: https://github.com/OleksandrChekhovskyi/hax was designed with local models in mind, but I haven't used it.
So the agent-substrate checks a _ton_ of boxes. Almost all of the things it offers should be table stakes for everywhere we run not only agents but most software.
(For context I built something very similar to this the past 2 weeks for my homelab, trying to solve many of these problems. This comment is an edited version of an unreleased blog post I wrote last week.)
- Run code in secure microVMs or gVisor. Docker is not good enough. Qemu is not good enough. A secure environment for running untrusted code is the bare minimum. I don't see Firecracker in the repo yet, but that's ok the idea is there.
- Fast resumption. In my homelab, time-to-first-message is around 11-12 seconds. That's half setting up the pod, and half resuming the CLI (e.g. `codex resume ..`). Why resuming? In my homelab agents are commonly blocked waiting for CI or waiting for me to approve an action, in this case I stop their container to keep resource usage low. Then for resumption, you definitely don't want to waste the agents time by giving a new ephemeral disk and forcing them to re-clone and re-build. For microVMs this is not actually straightforward, for example Firecracker only allows block devices, so re-attaching an agents disk workspace requires a custom storage interface
- Zero Trust. Codex CLI permissions for example are extremely broken. "Can I run this 500 line long command? or allow any command starting with first 100 chars always?" More reasonable grants are needed.
I don't understand yet how they will surface Zero Trust notifications. In my homelab it's a Forgejo comment linking to an auth service, and a ntfy.sh iOS notification which opens up the auth service.
I don't get why they to restore the RAM of the agent env. Maybe to fully optimize resumption. Idk, I don't have that much RAM in my homelab, my agents use a ton, testing stuff in Chromium making screenshots for me. I can't keep RAM for 100 workspaces from the past 24 hours in RAM.
MITM gateway is very cool.
I'm curious how they will integrate with microVMs. I just wrote yesterday[1] about how there are NO GOOD OPTIONS for this atm. Kata is decent but the attack surface it introduces makes me uncomfortable.
But anyway, even if this project is abandoned out of the gate by Google, we should be happy, it sets the bar where it should be. I'm excited to learn how they solved these problems differently than I did.
Restoring memory is useful if, when you resume an agent VM, you want the apps to be in the exact state when they were suspended.
But for most things, I find resuming with memory is more trouble than it's worth. If you always resume from memory, you lose the ability to control the state of a VM. It's much easier to define which services should run than to define which active RAM state should be purged
Similar to why "did you try turning it on and off again?" is good for system reliability.
> I don't get why they to restore the RAM of the agent env. Maybe to fully optimize resumption. Idk, I don't have that much RAM in my homelab, my agents use a ton, testing stuff in Chromium making screenshots for me. I can't keep RAM for 100 workspaces from the past 24 hours in RAM.
This is going to be decomposed. I believe the plan is to offer resumption with disk state only as well (and the RAM snapshots will need to be discarded from time to time, if you update the underlying code of the agent, or switch CPU types).
By the way, the RAM snapshots are not kept in RAM, they are serialized to disk, or uploaded to object storage.
284 comments
[ 0.23 ms ] story [ 89.0 ms ] threadWhat I do know is that the Gemini integration into sheets is surprisingly incapable of performing basic tasks. This is where I expect Google to really shine. I expected Sheets + Gemini to be magical like Google Photos was. I hardly try anymore besides some basic math questions when I don't feel like inputting the formula myself.
The other thing I know is Google's propensity to sunset products. For many things, it's not a huge deal. And it may not be for this. But, why? When there are alternatives - both open and closed.
Recently, they went to our Co-President and he, similarly and thankfully, ignored them. So what did those fucking assholes do? They went to our board members and got one of them to make me have to do a bunch of needless work responding, in depth, to one of their LLM-generated decks that is generic and doesn't at all consider anything we're doing, a good bit of which was centered around agentic-foo bullshit.
* Conversational Client Analytics in Looker: Deploy natural language conversational data discovery
* AI Agent Development Kit Core: Construct autonomous analytics agents with Google Agent Development Kit
* Generative Search Performance Tracker: Track brand visibility across AI answer engines using Gemini 3.1 Pro.
* Autonomous Retail Media Campaign Orchestrator: Automate retail media catalog enrichment and ad optimization with Gemini
* Agentic Workforce Collaboration in Workspace: Deploy Gemini Enterprise wall-to-wall for automated agency pitch creation.
---
They're exhausting. We already do most of these things better than they suggest (really; who the fuck thinks 'conversational analytics in Looker' is exciting in 2026? No one capable, that's for fucking sure) and it's clear that some MBA motherfucker just decided to use Gemini to push a bunch of garbage that is ignored by those who are technically and financially apt and elevate to the persons who don't know shit from shinola in order to try and get some consultant in the door to sell shit that companies already have and are doing.
It's fucking absurd.
I hope someone with some pull over there reads this and slaps this shit down and fast. It's really fucking annoying and needs to stop 4y ago.
After about 3 messages in any given chat, a follow-up to "rewrite that with a more friendly tone" will result in a letter for a completely different job from another chat within the notebook.
Genuinely not knowledgeable here
https://grapheneos.social/@GrapheneOS/117282080803799576
> Google should not be gatekeeping security patches to the standard Android platform code from Android OEMs but that's what they've started doing.
https://killedbygoogle.com/
https://github.com/googleworkspace
In addition to the ones you listed, I'd add the V8 runtime, Jax, Protobuf. Even some of their projects that wound up declining in market share (Angular, Tensorflow--both losing share to projects that wound up at Meta, ironically) are still actively maintained and pushed.
But I'm sure there's also a huge graveyard of open source projects they abandoned that just never hit my radar. Still, at least with their open source stuff, you can fork in the worst case.
or Android Open Source Project?
I think Scion has so much more mature a disosition: you could write OpenCode plugins that enhance the runner, and use that locally, and use it in Scion. With Ax/Agent Substrate, you are opting in to a pretty huge stack that is just Agent Substrate, that is their runners, their harness, their substrate. I do think their actor model is pretty neat! It's neat having the agent have such primacy! But it feels so much less integrative, is such it's own thing. Scion, to me, is much more interesting an effort, that similarly helps scale out agentic workloads.
https://github.com/googlecloudplatform/scion
The website makes me think the contrary: It is described as “low opinion” and explicitly mentions that the running tasks don’t even have to be AI agents. Can you explain in what ways you’re more locked in than the website suggests?
> You need a Kubernetes cluster, ko (brew install ko), a container registry your cluster can pull from, and a reachable Agent Substrate Control API (in-cluster default: api.ate-system.svc.cluster.local:443).
> make deploy AX_IMAGE_REPO=<your-registry>
> This deploys Redis, then builds and deploys the control plane images with ko. Everything lands in the ax-system namespace.
What's nice about Scion is that it runs existing systems. It runs Claude, it runs Code, it runs Pi, it runs OpenCode. By contrast, "low opinion" means build something new, from scratch, atop this brand new platform.
Note that both of these are designed to work at some scale. Agent Substrate specifically is somewhat coupled to Kubernetes, is my impression, but honestly that's fine with me. Scion can run on Docker, Podman, Apple Container, Kubernetes, or Cloud Run. It's good that we be able to run these relatively quickly, but (especially with LLM assistance) the idea of running some substantial dependencies / services to run these things does not seem like a bad thing. If anything, I'd prefer having some well known services underfoot to these all being recreated afresh.
Yes, it was developed by Google employees, that does not imply it has the full backing of Google, or Deepmind, or GCP. Notably, the website doesn't seem to claim this either.
A random example E.g https://github.com/google/filament#disclaimer
This is not an officially supported Google product.
> This is not an officially supported Google product. This project is not eligible for the Google Open Source Software Vulnerability Rewards Program.
https://github.com/GoogleCloudPlatform/scion
"Effort in GCP" is a red flag. (See Gemini CLI, which was shut down in favor of Antigravity CLI.)
AX is a layer that is closer to job orchestration, it's NOT an agentic framework. We use Antigravity for a few generative features but are abstracting away some of these components so anyone can bring their own.
Google compute services are under GCP and I work on Kubernetes.
We have used a few of Google's (smaller) open source projects, and in the last 2-3 years most of them are getting fewer updates if any updates at all. Some became very bad tech debt and we had to spend a lot of time migrating them.
Of course, that is the nature of open source projects (written in the license terms), and there is nothing to complain. But it's important to point out these days Google's open source project are not any more trustworthy than a one man's project in terms of support and maintainability. Personally I would stay away from them as far as possible. Especially if you look at what happened to Android, Gemini CLI etc.
(To be honest, even if it were officially supported by Google, that barely means anything. https://killedbygoogle.com/)
Would be about time we get benchmarks for these ... so these can also be gamified just like with the LLMs.
With that said, I’ll somewhat disagree with you. I’ve been down the path you’re talking about and while it is incredibly flexible and powerful, it became too difficult to maintain, and too inconsistent between workflow runs, and a pretty hefty waste of tokens to use AI on things that could instead be handled by deterministic scripts. I ended up creating an orchestrator for myself that uses skills as the primary way to tell agents how to execute a step in a workflow, but also directly orchestrates running scripts and managing state in a deterministic way rather than leaving it all up to agents.
If you are using Qwen 27B you need very prescriptive skills.
If you are using Astra you usually want very minimal skills (because it will follow them but be unnecessarily constrained in some contexts)
If you are using Fable then it depends - it will take the skills as general guidelines but ignore them a lot more than Astra does. Sometimes this is good, sometimes not at all.
Overall I agree though, this is a bit of an abuse of that concept.
EDIT: I'm sure op is familiar with this workflow but I'm being overly verbose to clarify what I think they mean and my thoughts.
Not sure if this is an extension of tech they already have had in their systems, but I've experimenting with it to build my own orchestrator and it's been a pretty neat set of tools and abstractions so far.
Even if you confine yourself to a dev workstation, having 5 agents concurrently building testing deploying code makes your computer loud and/or hot.
While I feel like I have a decent understanding of the model landscape I'm feeling a bit lost at which agentic harness to leverage for local models. Hermes, Cline, Aider, Qwen Code, Goose, Pi, OpenCode, something else? I live in the terminal so Desktop UX is a bonus but not a must have.
Can I modify the antigravity settings/program to point to a local model? Where should I spend my energy?
Only complaint is that connecting the agent harness to my local model took more work getting configured right than I'd like, but that's been true of most harnesses I've tried as well. Most assume you're using a cloud model and local model configuration is a bit of an afterthought.
In case of omp, not sure if it's already at the node module package but you can just grab it from the links I shared and set it up.
* commands run by me (! prefix) are also sandbox blocked
* agent has no way to _request_ unsandboxed execution (e.g. if `kubectl whatever` is rejected by the sandbox, the model should have the chance to request permission)
* does not understand shell composition patterns (e.g. if `git status` is allowed and `git log` is allowed, then `git status && git log` should be allowed automatically)
* sandbox only supported on mac or linux. not both
All of that can be fixed by yourself. That's certainly the spirit of pi. But if you want strong defaults and batteries included (like omp promises) then that's just annoying.
- instruct model to write a markdown file with a phased plan to implement whatever feature or change I want
- start a new context, instruct model to implement one phase of the file
- review changes manually, then start a new context and have it do the next phase
- repeat as needed
I've never seen omp touch a file outside of the directory I start it up in, and the few times where I've been unhappy with a change git has been there to revert.
This could easily be a case of survivor bias but I've not had an issue with letting it go yolo yet.
Always Pi.
I'm not a fan of open-core apps.
https://github.com/agent-substrate/substrate
(For context I built something very similar to this the past 2 weeks for my homelab, trying to solve many of these problems. This comment is an edited version of an unreleased blog post I wrote last week.)
- Run code in secure microVMs or gVisor. Docker is not good enough. Qemu is not good enough. A secure environment for running untrusted code is the bare minimum. I don't see Firecracker in the repo yet, but that's ok the idea is there.
- Fast resumption. In my homelab, time-to-first-message is around 11-12 seconds. That's half setting up the pod, and half resuming the CLI (e.g. `codex resume ..`). Why resuming? In my homelab agents are commonly blocked waiting for CI or waiting for me to approve an action, in this case I stop their container to keep resource usage low. Then for resumption, you definitely don't want to waste the agents time by giving a new ephemeral disk and forcing them to re-clone and re-build. For microVMs this is not actually straightforward, for example Firecracker only allows block devices, so re-attaching an agents disk workspace requires a custom storage interface
- Zero Trust. Codex CLI permissions for example are extremely broken. "Can I run this 500 line long command? or allow any command starting with first 100 chars always?" More reasonable grants are needed.
I don't understand yet how they will surface Zero Trust notifications. In my homelab it's a Forgejo comment linking to an auth service, and a ntfy.sh iOS notification which opens up the auth service.
I don't get why they to restore the RAM of the agent env. Maybe to fully optimize resumption. Idk, I don't have that much RAM in my homelab, my agents use a ton, testing stuff in Chromium making screenshots for me. I can't keep RAM for 100 workspaces from the past 24 hours in RAM.
MITM gateway is very cool.
I'm curious how they will integrate with microVMs. I just wrote yesterday[1] about how there are NO GOOD OPTIONS for this atm. Kata is decent but the attack surface it introduces makes me uncomfortable.
[1]: https://srcreigh.ca/posts/auditable-kata/
But anyway, even if this project is abandoned out of the gate by Google, we should be happy, it sets the bar where it should be. I'm excited to learn how they solved these problems differently than I did.
But for most things, I find resuming with memory is more trouble than it's worth. If you always resume from memory, you lose the ability to control the state of a VM. It's much easier to define which services should run than to define which active RAM state should be purged
Similar to why "did you try turning it on and off again?" is good for system reliability.
This is going to be decomposed. I believe the plan is to offer resumption with disk state only as well (and the RAM snapshots will need to be discarded from time to time, if you update the underlying code of the agent, or switch CPU types).
By the way, the RAM snapshots are not kept in RAM, they are serialized to disk, or uploaded to object storage.
https://googlecloudplatform.github.io/scion/overview/
Scion wraps the harnesses we all use every day and is closer to OpenClaw on Kubernetes