By Chirag Patil · · 3 min read
Why I’m Building open-services-agent-starter-pack (Google ADK, without the cloud lock-in)
After building with LangGraph and Google ADK, I prefer ADK’s developer experience—but many core services assume Vertex AI. This WIP starter pack is my attempt to make ADK feel ‘first-class’ on non-GCP infrastructure.
I’m building a WIP project called open-services-agent-starter-pack: an opinionated way to run Google ADK-style agents using open services instead of the Vertex AI-managed dependencies.
This is closely related to (and currently overlaps with) my earlier/parallel effort:
Background: LangGraph vs Google ADK
I’ve built primarily with LangGraph and Google ADK.
After working with both, I’ve found ADK is simply nicer to build with:
- The API surface feels more “productized” for agent apps.
- The patterns (sessions, memory, artifacts) map cleanly to how real systems evolve.
- The ergonomics are strong when you run it the “intended” way.
LangGraph is powerful and flexible, but for the kind of apps I’m shipping, ADK has been the better day-to-day developer experience.
The catch: ADK assumes Vertex AI services
The main downside is that a lot of ADK’s surrounding infrastructure is effectively Vertex-first.
In particular, parts of the ecosystem assume managed services like:
- Session management
- Memory management
- Artifact store
When you’re on Vertex AI (especially using Agent Engine as intended), this is great: it “just works” and it works well.
But if you want to use ADK as an open-source framework and bring your own infrastructure (Postgres, Redis, S3/GCS, local dev, Kubernetes, on-prem), there’s a real gap.
Why I’m doing this
I keep seeing the same fork in the road:
- Option A: “Use ADK properly” → commit to Vertex AI and its managed services.
- Option B: “Go off-road” → rebuild the missing pieces yourself, inconsistently, per project.
That second option is expensive. It slows you down, and it makes agent systems harder to standardize across environments.
So the goal of open-services-agent-starter-pack is straightforward:
- Provide open-service equivalents for the key ADK-adjacent capabilities.
- Make them feel boring (in a good way): predictable, observable, testable.
- Keep the interface surface small so you can swap implementations without rewriting your app.
What “starter pack” means here
This project is intended to be a drop-in alternative to the official starter pack pattern that assumes substantial cloud resources bootstrapped via Terraform:
To be clear: the official starter pack is excellent if you’re all-in on GCP.
My problem statement is different:
- I want a starter pack that works when you don’t want Terraform-driven GCP primitives as the baseline.
Design constraints (the rules I’m building by)
- Drop-in mental model: keep the concepts aligned with ADK’s workflow (sessions, memory, artifacts), even if the implementation is different.
- Open by default: prefer infrastructure that can run anywhere (local → Docker → Kubernetes).
- Minimal magic: explicit configs, clear storage boundaries, readable failure modes.
- Upgradeable later: start with a practical implementation, not a “perfect abstraction layer.”
Current status (WIP)
This is not “done.” It’s a working project in progress.
What I’m focusing on first is getting a cohesive baseline where:
- you can run an agent locally,
- persistence is real (not a demo stub),
- swapping a backing service doesn’t require rewriting your agent logic.
As it stabilizes, I’ll document concrete recipes (e.g., Postgres + Redis + S3/minio; or pure local for dev), and I’ll add migration notes for teams starting from the Terraform-heavy baseline.
Why this matters (to me)
I want the ecosystem to have a path where you can choose:
- Google ADK for the framework, and
- your own infra for the services,
without it feeling like you’re fighting the tooling the whole way.
If you’re building agent systems and you’ve felt this pain too, I’d love to hear what services you needed to replace first (and what you used).