This is an Apache 2.0 open source project

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

Making Kubernetes a centre of everything. This one, they won’t sunset, because it helps selling GCP services.

I told this exact thing to my gf few days ago and somehow she was mad at me for it

You know you're on the right path when Kate Satan turns up.

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.

That's not fair. Sometimes they kill it off quickly.

https://killedbygoogle.com/

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.

yet they "maintain" the pinned state on the org page

https://github.com/googleworkspace

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.

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.

Don't forget `cgroups`, eh? That was a huge Linux contribution.

or Android Open Source Project?

I assume they expect agents will be writing most of those

Not GP, but you start with Kubernetes…

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.

This /looks/ at least more official. Most unofficial Google projects have a disclaimer in the repo.

Does Filament claim that it's Google's in the repo description? It's a valid title.

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.)

Agent Substrate is being moved to CNCF: https://github.com/cncf/sandbox/issues/523

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 agree on both accounts fwiw.

It is not, it is intentionally not-interoperable walled garden, unlike Gemini CLI.

Is it superior in terms of license?

And anyone who bothers to just do a side-by-side feature comparison can immediately see how many features antigravity is still missing compared to Gemini CLI even today.

The reality with releases like this is that I'm 90% sure most Google bigwigs have never heard of it

Google has around 200,000 employees. They probably haven't heard of most things Google releases.

It's got a formal announcement on the blog. 4 months ago.

https://cloud.google.com/blog/products/ai-machine-learning/a...

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/)

Everyone and their mother are vibe coding their own solutions like this, all the time.

This is bound to cause some confusion with the other tool called Ax for agentic development: https://axllm.dev/ (which is DSPy for other languages)

this is nice, basically virtual threads for kubernetes.

what are your points of comparison ?

Part of what's happening is this is running on Kubernetes, which is oft described as "Overly complex; yaml files, heavy framework" but has value regardless, as perceived by being an industry standard. All the things you describe are well and good, but do not address how one runs many of them reliably (from an infra stand point)

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.

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.

Dropbox comment

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.

KYAML seems eerily close to json5.

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.

Its docs have zero support

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.

Did something change with it for depth of integration? Goose has been able to use local models via OpenAI compatible endpoints for at least a year

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.

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.

i built something with a similar philosophy https://github.com/khimaros/hrns

pi.

Always Pi.

What are you using Jules for? I want to like it but it fails too often. If I could use Gemini 3.8 I would be happy but 3.6 rarely succeeds.

This is news to me, do you have a link to docs for the configuration option?

Deepseek Harness is great, at least with deepseek.

Hmm, that phrasing is misleading - it's an open-source project: the core is AGPL, the extensions are permissively licensed

For microVM, smolvm is quite impressive.

For further isolation, I like to use nono inside a smolvm instance.

I thought the whole point of a microVM is that it does provide isolation ?

But smolvm provides kernel-level isolation. Much closer to firecracker than docker.

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.

Supports direct filesystem access and who knows what else. It is unsuitable for running untrusted code on Linux.

I'm keeping an eye on another Google Cloud orchestrator

https://googlecloudplatform.github.io/scion/overview/

Scion wraps the harnesses (9x) we all use every day and is closer to OpenClaw on Kubernetes

you can run it yourself, it's open source, you can use any harness (req. custom image), you can use any token vendor (config)

A DAG?! Holy innovation, Batman!

How does it compare to kagent (https://kagent.dev/)?

As usual, Google makes it "googley" by building an incompatible monolith with the kitchen sink included.

"Is giving the agent a temporary scratchbox really that valuable?"

Yes, but, wrong layer here. Giving the agent a computer use (a la bash) is what folks are after. A temporary sandbox with lots of control knobs and security bits is how you do that in (as you noted) an enterprise.

I was expecting whack-a-mole as well when designing my sandbox software, but mostly it didn't happen.

As a test, I built a sandbox with only the host-side filtering proxy allowed for networking. 99% of traffic was HTTP. No QUIC at all.

npm, pip, apt, go, curl and git-over-HTTPS all worked on the standard proxy environment variables alone. No mirrors or other coaxing needed.

DNS is disallowed through the chokepoint, but that's no problem because the proxy resolves host-side anyway.

at least this one is pre-named for past tense when that day arrives /s

Hey, Dialogflow still appears to be alive and kicking after over a decade. Given how much money they have spent marketing their agent plaform I could see this lasting a while.

Google already dumped their original agent framework on the Linux foundation after they realized noone really liked it and the overzealous managers who immediately bought into the hype would go apeshit if they dropped support so fast. Agentic tools have a lifetime measured in months.

Like Kubernetes?

Yahoo would like a word with you

What about:

Gmail for Your Domain/Google Apps for Your Domain/Google Apps/Google Apps Premier Edition/Google Apps for Business/Google Apps for Work/G Suite/Google Workspace

Gears has been superseded, not canceled

Actually, I think it's drowning.

I was @ Google I/O at live keynote when they announced/demoed it. Ironically, at the exact same time, me and the guy next to me said (in different words), "Why do we need this?" That was a collaborative Google Wave moment IRL.

I think the negative impact lots of humans regularly experience from Google's approach to business is far more than the benefit of the very, very specific learning that "this idea doesn't make enough money for Google the way Google did it".

Yes thats fine, but i would never trust to use one of their productions in production so to speak.

Yeah I wouldn’t build anything on Google’s products that might not exist in x years

I would expect Google to maintain this and other tooling around this for years to come

"Gosh, that Italian family at the next table sure is quiet"

I for one read it as intentional sarcasm.

ditto

Tell us more about your grandma.

I think my dog has spent all weekend refactoring its own framework to integrate Jev.

I would expect Google to maintain this and other tooling around this for years to come.

First time?

The way I do it is each worktree gets its own .env, with dev credentials to whatever it needs access to, and my coworkers have theirs set up to have an isolated Postgres database per worktree, but I didn’t bother with that in my setup— maybe I will, though. It’s a simple script to create a worktree and properly prepare it.

Tasks are a good scope for zero trust permissions

For my example where I modify both the OSS and private repos, I sometimes have one agent coordinate both changes (maybe with subagents), or if the work is modular and separate, I have disjoint agents do the work separately.

That said, most of the time, I only want an agent to work in one repo. I could give it multiple repos at once and instruct it to work in just one, but that risks it forgetting my instructions and it can load more context into the agent's window.

I think my main point was to have flexibility about the topology of VMs, repos, and agents.

From what I've seen, the vast majority of agent sandboxes with funding aren't for developers to use when coding, but for production applications that want to have LLMs do work. It's just a different model - APIs are better than a great terminal experience for a coding harness.

I've been working on https://lullabot.github.io/sandbar/latest/ which works with Proxmox for VMs (and lima for locals or regular linux hosts over ssh). There's a diagram in https://lullabot.github.io/sandbar/latest/why/#recommended-w... with what we're currently recommending. Though, after some feedback, I'm in the process of integrating a colleague's web-based review tool as it turns out many preferred fully reviewing locally instead of using draft PRs.

It's got some opinions in terms of default tools for our team and industry so it may not fit yours. Forgive some of the AI-isms in the docs, I want to get the UX and feature set to a solid place before doing a full review.

I don't mind that as long as that system gets regularly wiped. If you don't wipe it, you can't reasonably measure the actual output and it's pets Vs cattle all over again, only with agents.

I love how I don't even know how many years after they were created mainstream languages haven't yet figured out that the only sandboxing that works is default deny, like Tcl or Lua.

Especially with autonomous agents, it's the only way to sanity.

We might need new OS abstractions.

I've worked on that as well, and agree with you. You do need the "build this thing" flow, but that just shifts the bottleneck. You also need a whole infrastructure around it, where the jira-to-production pipeline isn't the interesting part.

What do you mean by the "React" of this space? The overall base layer has more or less converged on Kubernetes + MicroVM, which makes total sense. But if you mean how to interact with it as well as how permissions should work, yeah I agree.

Yes, but what I'm saying is that it is much easier to put a limit on the read_file tool or the http tool rather than sandboxing your whole environment.

You only really need to sandbox when you provide access to tools that are almost impossible to filter correctly, such as a bash tool or a tool for arbitrary code execution.

I spent today doing forensics on ten compromised WordPress sites sharing one hosting account.

I used two agents: One with network access to collect the evidence, and one with everything except the model endpoint cut off, which did the analysis.

The second agent's entire input was attacker-authored. So PHP droppers, obfuscated loaders, database rows, filenames, blah blah.

In this case I'm more worried about hostile input attacking the agent, and I need to contain the damage. My sandboxing solution does that by restricting access to the source data, making it read-only. The work dir can only transfer data via patch and apply (like a git workflow), so even my workspace can't be modified until I approve each change. And then restricted network means that any compromise ain't going noplace.

The second agent couldn't even install PHP or contact any CVE site to check if it was looking at a known attack, and that was by design. All it could do is write up a report about what it observed, not make assumptions about what it is. I could then take its (much smaller) clean output and pass that to a third agent with network access.

This is forensic work, so of course not your median dev's bread & butter. But the attack surface is only just starting to be plumbed. Compromising input can turn your agent into their agent, planting things as easily as planting worms was back in the early internet days when people connected without a firewall.

Security by obscurity is just a bet on weights, a belief that the economic motivations for attacking are insufficient. That worked before, but developments in ML calls to account all the debt we’ve accumulated through that practice.

Well, presumably AI lowers the bar for entry so more people (and very specifically people with revolutionary ideas, but without corresponding implementation skills) could get in on the action.

https://chatgpt.com/ is a good starting point. Enable voice control and ask the robot to draw a pelican riding a bicycle. Much wow, very revolutionary. More to come.

My advice: stop your fomo. Just get useful work done.

I think at this point there is also lots of wild enthusiasm and not that much proof mass-agent anything + orchestration is actually financially viable or even useful.

I've been still just like, making VM's with proxmox, then putting my agent in the machine and letting it run free

I outgrew this when I wanted to bring different sets of skills and templates to different machines, wanted to be able to share a small number of credentials, different agents in different machines, different egress rules etc. I wrote https://github.com/pjlsergeant/byre which gives you a TUI and some machinery for doing this easily on top of Docker or Podman.

Yup. I'm also working more and more in a terminal typing English sentences to my computer. It looks like a very smart adventure game UI from the 80s.

A little git log, show, diff almost always in another terminal.

A customer of mine wants to standardize his developers on a Jetbrains IDE for python but I think that he is late by one year. Furthermore he is using the subsidized plans for Claude, not paying for token, so it makes sense to keep using the Claude TUI.

Doing the same more or less, replacing vscode for vim. Usually three/four panes open, one codex running in a container so it doesn't share my host filesystem, one pane for git diffs/git, one for general shelling and one for neovim basically. One of these per project/task/worktree I'm working on, usually 1-2, maximum 3 at the same time.

Not sure what all the other folks are doing, but the industry/ecosystem tends to over-engineer every single thing instead of just working on the thing, while I just want proper code, proper design/architecture, and proper high-quality results.

It's kinda true. I use the terminal approach too, but I wouldn't trust every type of user with this long of a leash. There's a place for instituting systems that share context, manage authentication, and is permissions-aware.

Perhaps. This was also before CDNs were a thing, so they may have decided they can't afford to be one, as more and more people discovered just how versatile the Public/ folder is.

Either way, this was the peak of Dropbox; after shutting down direct Public/ links, it was still useful for its main job as seamless cross-machine, cross-platform "folder that syncs", but gradually lost market share as OneDrive and Google Drive became more broadly useful (and had the advantage of being first-party on their respective platforms), and then Dropbox the company itself lost focus and tried a bunch of failed pivots in the direction towards cloudification, away from "just syncing files".

End result for end users? We now have zero options for bullshit-free, file-first, seamless "folder that syncs" experience for non-tech users (techies that like fiddling with things have Syncthing). Only cloud-first options remain, and they're full of footguns and enshittified to the core (which becomes apparent the moment you want to share a file outside of the vendor's cloud ecosystem).

Pros and cons. The sloppy approach actually works well for Claude because its memory retrieval is more reliable than AGENTS.md style instructions.

I wrote a little program to spin up isolated rootless workspaces: https://github.com/jgillich/tpd

Works pretty well for me but I haven't put any effort into promoting it

Personally I think microVM are the future but nothing wrong with a solid proxmox setup.

Probably we'll converge on a virtualised IO / Storage layer running microVMs beneath for isolation and security. Keep the network and storage layer separate for compatibility running a variety of stuff and a second security boundary.

From their own example "Setting up a Python 3 environment" is best it can do.

An even simpler "sandbox" is to create a separate user and home dir for your LLM.

I think you might be confusing "what people should be doing" from "what some people think they can make money from". imho the whole "agent sandboxing" thing is vastly premature and un-thought-out.

I wonder if Google stole this code too like they did with minitap

An example of this, Moonshot (kimi) open sourced this: https://kvcache-ai.github.io/AgentENV/latest/getting-started...

billions? who is running BILLIONS of agents?

tens, hundreds, maybe a couple thousand at a time? absolutely.

I think it will be, but I don't think you need a standalone machine! If you run things inside a VM, you can get safety and control over access and networks

A standalone machine is nice if you need more compute resources or if you want an always-on machine you can connect to from your laptop, phone, etc.

It doesn't look like Google's AX is quite the plug-and-play fit for running agents on a computer you own, since it requires setting up a K8S cluster, etc.

I think what's needed is something like a zero-setup combo of Tailscale and Firecracker

I'm trying to work towards that with my startup (https://github.com/gofixpoint/amika) but the bring-your-own-computer part doesn't work quite yet.

You might be right, it likely needs a full proper PC setup with the test suite stuff. I was looking at this vendor, https://www.gmktec.com/collections/all there's this whole AI mini-pc market but they aren't quite a full dev machine replacement

Depends a lot on your workload. I build large Rust projects so really only one can build and test at a time.

Interesting, we had developed a very similar framework for our internal agents: https://github.com/apoxy-dev/clrk For us main use-case was intercepting all network I/O including LLM providers, HTTP, and random TCP/UDP calls

yes, has a bad smell of k8s

Fully agreed. Google just can't stop losing.

There are two hard problems in computer science, naming things, cache invalidation and off-by-one errors:

https://github.com/google/ax/issues/356

If there's a criticism here, it's that they don't mention k8s right up front. It's completely opaque what this tool is. "Orchestration" can mean literally anything.

The web page presents ax as a typical developer tool, but it's actually not for developers.

Kubernetes is the last thing I wanted to see recreated for agents. It’s like Multics of cloud, now for agents. Complexity for the sake of it, powered by your favourite YAML slop bowl.

Am I being gaslighted into thinking over engineered systems are not?

Interesting approach. How does it compare to LangGraph for multi-step agent workflows? The orchestration layer always seems to be the hardest part to get right in practice.

Drawing on agentic runtime research from Google DeepMind alongside deep experience in large-scale isolation, resumption, and scheduling, AX is being built as an open, declarative control plane purpose-built...

The project seems like an open-source initiative born out of the experience of some Googlers but not being used at Google. So, the title appears a bit misleading - people will be misled.

Anyone who uses this promotion packet fodder for anything important is a fool

Same. I don't get it.

The best part of all of this is the most if not all people have no idea what the hell is going on when every day a new paradigm/tooling/harness emerges. It's hard to keep up. On the plus side, it's a great equalizer.

Offload the work of an LLM agent to a box in the cloud, so it doesn’t run on your laptop. This has security benefits (no access to your laptop’s files) and you can scale it up (run a lot of agents at the same time).

Then put a “sandbox” around these agents, that word has many meanings. In this case they fence the network traffic, so likely some kind of allowlist for network requests so that the agent doesn’t exfil crap to random websites. They also limit the resource limits of the sandbox, so that is beneficial to the cost of running these agents.

Everything is always better with more YAML, are you perhaps new to this industry?

Next we also need an instruction style guide and CoC. It's important to treat your agents with respect. I almost forgot, the YAML template meta-language to YAML the YAML. Then we will need a foundation employing 12 FTEs to maintain it all and of course to run the certification process. You are certified, right? Statistics show a 10x increased chance of an agent going rogue and hacking competitors if it has been mistreated or been run in an unvalidated sandbox. It goes without saying the sandbox certification process is separate and must be repeated yearly by a trusted third party auditing company.

k8s, but for agents

must look cool for people who want to solve every problem with k8s

it starts with interesting misnomers like "Task" which is not a work item but a sandbox.

"billions of tasks" is a "solution" to problem nobody has (maybe some RL labs? but they solve it other way and with orders of magnitude better optimizations).

freezes design too early – unless they'll actually focus on developing it and make tons of breaking changes it looks shit.

shared state in the same workspace, identity, authority, etc – stuff like that needs to be solved

No to confuse with Ax, the DSPy inspired agent framework

https://axllm.dev/

Unnecessary complexity packaged as product!

The real difficult in arranging agents is not to run them, but to identify the state change - to judge whether an agent stops to wait for you, or is stuck, or finished, and whether the two should be handled automatically or someone should be found. You have made this judgment for 12 agents, and you need to know how unreliable it is.

It looks great from a security standpoint, but it also feels like overkill.

K8s jobs don’t run in a secure runtime. K8s jobs don’t give you dynamic zero trust permissions scopes. Restoring a harness in 500ms is really fast, much faster than naively creating a new job downloading session and ‘codex resume’ etc.

not exactly for agent orchestrator, but I did make something similar in terms of design: https://github.com/yash-srivastava19/cadence

Surprising no mention of Google on the page or domain.

Oh no, Kubernetes for agents. I guess all roads lead to complex YAML.

"2. Deploy the control plane

You need a Kubernetes cluster"

LOL. Bye!

I was expecting that, in the AI era, even Google will start using Rust for everything. But they chose Go for the this project.

Didn't you see the example on the website? It can set-up a Python 3 environment. Duh!

Yeah, my grandmother also did something on this https://github.com/nillebco/varda

Essentially there is no out of the box solution about orchestrating agents and increasing LLMs sandboxing. That's why everyone and their grandmother are re-inventing the wheel.

At the same time, it's an incredibly complicated problem, with a variable perimeter (OS support, sandboxing primitives support).

I am quite happy about my own solution (because it supports my use case!) but I hope something with a decent dev UX will appear one day. AX definitely is NOT.

ah...! I never would have guessed in a hundred years, but after googling a picture I can see it now

I believe it's a stylized lo-fi rendition of an axolotl.

It's most likely an axolotl.

Kubernetes but for agent ?

Agent Substrate was built to provide a few (important) things over Agent Sandbox:

* More efficient usage of compute by timeslicing agents (Substrate Actors), which requires fast suspend and resume (using gVisor or cloud-hypervisor snapshots), as well as keeping the K8s control plane out of the critical path (so agents can't be stored as resources in the K8s database).

* Deep inspection of outgoing requests using an egress gateway

* Minimizing the exposure of credentials to unpredictable agent control (so they can't upload access tokens to pastebin).

Achieving those goals ultimately required a significantly different design from Agent Sandbox.

This is different from langchain etc because lanchain works at the app layer but this one works at the infra layer with tool calls etc?

It's crazy how far behind Google has fallen in this space in just a single year

We have built similar abstractions directly on top of Kubernetes [1]

I was looking at this project a couple of months ago, and I did not understand why not use Kubernetes instead of rebuilding the abstractions. The reason is that Kubernetes already provides other abstractions to run services and batch job, gang scheduling, gpu and other accelerators enabled workflow.

[1]: https://polyaxon.com/docs/sandboxes/overview/

It's easy, just add this thing.

lmao found the dev who's only ever worked on the dev side of things.

One thing I quickly learned when I got into GCP was that you must absolutely not try to use that interface. If it can’t be done with the CLI, it’s best to just close the computer and go outside instead.

As with everything in software engineering, any average dev can fire up a few containers with Docker, but running anything in a real environment takes a whole team of people who actually understand the platforms involved in order to deliver a fully functional service, hopefully via properly designed code (TF) for ease of reusability. Most devs simply don't care to think about that part, and then throw it over the fence for "someone else" to deal with. Just as long as they can say "DONE!" (I created a thing!), that's all that matters.

Obligatory https://youtu.be/3t6L-FlfeaI

Google operates at such a scale with a wide surface area of serious production considerations that even “ergonomic” solutions internally feel extremely heavyweight externally.

Source: I’m an Xoogler

Easier from enterprise perspective.

Classic AI solution, you do the hardwork so that you can chat to an agent to do the easy part.

Googles Agent Identity is already built around SPIFFE but others are not.

I believe the substrate egress-gateway needs to handover the internal SPIFFE one to an external system (e.g. Entra Agent ID). Not sure if that should be part of substrate or kagent/ax/..

Agent Substrate is solving this - similar to K8s, Substrate is an OIDC (and also SPIFFE) IDP. Credentials containing the actor's identity can be injected into outbound requests using the Substrate egress gateway.

(This is work in flight, but it will land within a few weeks)

I agree, also the problem is the substrate is still in beta. So this is a beta on another beta: it seems not fully mature.

I'd prefer a K8s Operator or plugin (like Istio) to get all the pack.

Heavily biased a kube admin but make kube clusters is easy now - its literally one command (aws eks create-cluster/gcp ... something something haven't done it in awhile after doing it multiple times a day in a past life) - I think its more familiarity with the tools that is the challenge - creating a vm is also easy if you know how, brew/apt/yum install is easy if you know how, setup.exe is easy etc)

One thing I’d say, is that I find it progressively more interesting/fun to rollout your “everything”. I mean… hello security, but by the time I’ve read somebody’s documentation I’ve already halfway done making thing exactly how I want it.

Kubernetes but for agents :(

Since hearing the word orchestrator in ai context it was clear that ClanKernetes was coming.

We want to make dealing with agentic infrastructure easier > Kubernetes

Pick one.

Have they axed it yet?

I have an application usecase where this will be very helpful indeed.

How many months before Google kills this in favour of the next shiny thing?

The terminal gif is the most confusing slop I've seen from Google. It doesn't explain anything and it just seems to be a collection of random commands that someone ran to test, not something that tries to explain what the tool does.