af3c65088e
This is the initial release of the Agent Substrate. Agent substrate is a system built on top of Kubernetes which manages agent-like workloads to achieve higher scale and efficiency than Kubernetes alone can offer, with lower latency. It builds on top of Kubernetes features like Pods and Pod autoscaling, but takes the Kubernetes control-plane out of the critical path to achieve lower latency. It can run on any Kubernetes cluster and does not inhibit “regular” use of Kubernetes in any way. Kubernetes provides the infrastructure provisioning and management for all types of workloads, while Agent Substrate provides agent-specific scheduling and control. At its core, Agent Substrate maps a larger set of “actors” (applications such as agents) onto a smaller set of ready “workers” (Kubernetes Pods), relying on the fact that agent-like applications tend to be idle most of the time to achieve heavy multiplexing. It provides functionality to manage an actor’s lifecycle (e.g. create/destroy, suspend/resume), to assign actors to workers in real time, and to route incoming traffic to them. Agent Substrate is intended to be a low-opinion system. The workloads it manages don't have to be literal AI agents, but those are the best example of the kind of applications it is designed for. It is not an SDK for building agents, but rather a system for running them at scale. Agent Substrate is currently in VERY early development. It is not ready for production use, and the APIs are almost guaranteed to change. We are not making any guarantees about backward compatibility at this stage, and everything in this project may be changed. Co-authored-by: Alex Bulankou <alexbu@google.com> Co-authored-by: Benjamin Elder <bentheelder@google.com> Co-authored-by: Bowei Du <bowei@google.com> Co-authored-by: Dmitry Berkovich <dberkov@google.com> Co-authored-by: Fabricio Voznika <fvoznika@google.com> Co-authored-by: Francisco Cabrera <fclieutier@google.com> Co-authored-by: Haven Xia <haoyuxia@google.com> Co-authored-by: Julian Gutierrez Oschmann <juliangut@google.com> Co-authored-by: Kevin Steuer <ksteuer@google.com> Co-authored-by: Max Smythe <smythe@google.com> Co-authored-by: Maya Wang <mymaya@google.com> Co-authored-by: Michael Taufen <mtaufen@google.com> Co-authored-by: Shruti Nair <shrutinair@google.com> Co-authored-by: Taahir Ahmed <taahm@google.com> Co-authored-by: Tim Hockin <thockin@google.com> Co-authored-by: Zoe Zhao <zoezhao@google.com>
2.7 KiB
How to Contribute
We would love to accept your patches and contributions to this project. Before you spend a lot of time on a contribution, please review the following guidelines.
Before you begin
Sign our Contributor License Agreement
Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project.
If you or your current employer have already signed the Google CLA (even if it was for a different project), you probably don't need to do it again.
Visit https://cla.developers.google.com/ to see your current agreements or to sign a new one.
Review our Community Guidelines
This project follows Google's Open Source Community Guidelines.
Contribution process
This is a very new project, so we are still working out exactly how it is going to be developed. For now, we are focused on iterating quickly to find the right design and architecture. This has implications for contributors:
-
Things are moving quickly, so PRs may need to be rebased or updated frequently. Small PRs that are focused on a single issue or feature are easier to review and update than large PRs that touch many different parts of the codebase.
-
While we welcome new contributors, we are really focused on the minimal capabilities needed to make this project useful. Before you start a new contribution, please discuss it with us first (if there is an issue open, comment there and if not, open one). We want to make sure that your work is aligned with our near-term goals for the project and that we are not duplicating work that is already in flight.
-
PRs which are not aligned with our near-term goals may be closed without extensive review. We are not trying to be discouraging, but we need to make sure that we are focused on the most important work.
Code Reviews
All submissions, including submissions by project members, require review. We use GitHub pull requests for this purpose.
All code changes should be accompanied by tests. We will not merge code that does not have tests, and we will not merge code that causes tests to fail.
Copyright Headers
Every file containing source code must include copyright and license information. This includes any JS/CSS files that you might be serving out to browsers. (This is to help well-intentioned people avoid accidental copying that doesn't comply with the license.)
Our standard headers for various filetypes can be found in ./hack/boilerplate.