ETAP · Feasibility Investigation
Is it possible to let a workspace pick Anthropic Managed Agents or Google ADK as its build-and-run backend, keep the same menu structure, and align each screen to the chosen framework? Short answer: yes — but the two backends are not the symmetric pair the framing assumes, and one piece of the idea (“build & upload via agents-cli”) is by far the heaviest and most divergent. This is investigation-only; implementation is a separate decision.
Verdict: technically feasible, strategically a fork in the road.
The platform-services half of ETAP (workspaces, members, credentials, run-index, triggers/cron, Knowledge-Graph/MCP, analytics) is already a clean seam and would absorb a second framework with modest work. The session / streaming / event-rendering half is deeply Anthropic-shaped and is the real cost. And the specific phrase “build & upload agents via agents-cli” imports an agent CI/CD pipeline ETAP does not have today and which collides with two of its DNA principles. Recommendation below: if you want ADK, do the bind-and-drive variant (Option B), not the in-platform build pipeline.
The mental model is “pick Anthropic or Google when creating a workspace.” But those two are not mirror images of the same thing. They differ on two independent axes, and the proposal silently couples them.
LlmAgent), or a declarative Agent-Config YAMLThree consequences fall out of this table:
agents-cli brings Python packaging, container builds, Cloud Build, Artifact Registry and Terraform inside the product. That’s a whole new lifecycle, and it’s optional (see Option B).| Dimension | Finding |
|---|---|
| What it is | Open-source (Apache-2.0), code-first agent SDK — not a managed runtime itself. Python & Java are the mature SDKs; TS/Go/Kotlin newer. Released Apr 2025; runs two tracks today — v1.x (1.35) and v2.x GA (2.0 on 2026-05-19, graph workflows). |
| Agent definition | Primarily in code — LlmAgent/Agent (model + instructions + tools), composed via sub_agents, workflow agents (Sequential/Parallel/Loop), or v2 graphs. A declarative “Agent Config” YAML path also exists. |
| Models | Model-agnostic. Gemini native; Claude via a native Vertex Model-Garden class or LiteLlm("anthropic/…"); OpenAI/Cohere/local via LiteLLM/Ollama. |
| Runtime | Runner + cooperative event loop: agent yields Events, the SessionService appends them to history. Streaming via async generators (run_async / run_live). adk api_server exposes a self-hostable FastAPI surface (/run, /run_sse). |
| Sessions/artifacts | Persisted server-side when backed by a durable SessionService — InMemory, your own SQL (DatabaseSessionService), or managed VertexAiSessionService. Managed sessions/events are queryable over REST: …/reasoningEngines/{id}/sessions/{sid}/events. Separate MemoryService (incl. managed Vertex Memory Bank) for cross-session memory. |
| Deployment targets | Vertex AI Agent Engine (“Agent Runtime”; fully managed, in your GCP project — the close analogue to Anthropic Managed Agents), Cloud Run (container), GKE, or self-hosted container. Agent Engine deploy = source tarball → managed ReasoningEngine resource. |
| MCP | Both directions ADK agents are MCP clients (McpToolset over Streamable-HTTP/SSE/stdio) and can expose tools as an MCP server. → An ADK agent can consume ETAP’s existing KG MCP endpoint unchanged. |
| Scheduling | No native scheduler. Triggers come from Cloud Scheduler / Application Integration / Eventarc — i.e. external infra, exactly like ETAP’s “trigger = config on a binding” model. |
| Auth | Production path: GOOGLE_GENAI_USE_VERTEXAI=TRUE → ADC / service-account, no key material (identical pattern to ETAP’s KG Vertex setup). API-key mode for local dev only. |
agents-cli actually isgoogle/agents-cli is a lifecycle toolchain that wraps ADK (distinct from ADK’s own lower-level adk CLI). Apache-2.0, v0.5.0, pre-GA. Its tagline: “the CLI and skills … to create, evaluate, and deploy AI agents on Google Cloud.”
| Dimension | Finding |
|---|---|
| What it builds | create/scaffold a Python ADK project; deploy dispatches on a manifest deployment_target = agent_runtime (tarball → managed runtime) · cloud_run (container) · gke (container + Terraform). |
| Config | agents-cli-manifest.yaml (name, agent_directory, create_params) + pyproject.toml (depends on google-adk[gcp]≥2.0) + .env. Model / tools / instructions live in code (app/agent.py) — not in YAML. |
| Stack it pulls in | Python 3.11+, uv, Node.js, and for deploy: gcloud, Cloud Build, Artifact Registry, Terraform, Vertex AI / Agent Engine APIs, optionally Secret Manager. |
| Headless? | Mostly yes --auto-approve, --no-confirm-project, --no-wait, --dry-run (prints the underlying gcloud), --json. Caveat: login is interactive → a server would supply ADC out-of-band (standard GCP pattern). |
| Bonus idea | A deep eval suite (eval generate/grade/optimize, GEPA prompt optimization) — conceptually adjacent to ETAP’s own Model-Fit Evals epic, though it operates on ADK/Gemini agents. |
Your instinct that most screens stay shared is largely right. Roughly 70% of the surface is framework-neutral; the divergence concentrates in two screens.
| Screen / surface | Disposition | Why |
|---|---|---|
| Members roster · workspace list | Shared | Pure ETAP domain — no framework content. |
| Cron / trigger schedule UI | Shared | POSIX cron + prompt template; the firing path already calls a framework-neutral run-driver, not Anthropic. Your “cron on GCP works for both” is correct. |
| Knowledge Graphs (create/ingest/attach) | Shared | MCP is a standard; an ADK agent consumes the same KG endpoint. Zero rework. |
| Analytics / cost dashboards | Shared | Metrics are generic (tokens, duration). Only a per-framework price table is new. |
| Agents list (per workspace) | Shared | Reads the run-index; displays name/model/last-run. |
| Workspace credential admin | Variant | Add a parallel “Google ADK / GCP project” credential block beside the Anthropic key — reuses the KMS envelope pattern. |
| Agent / binding editor | Variant | Anthropic = Console agent + environment_id + versions. ADK = model + instructions + tools (+ optional build/deploy). Genuinely different forms. |
| Session detail (event timeline) | Per-framework | The hardest screen. Event types, stop_reason, tool inspection, usage are Anthropic-shaped; ADK’s event model differs. Needs a framework-aware renderer. |
Clean seams ≈ 8 person-days
lib/google-adk-secrets.ts mirroring the KMS envelope; workspace doc carries both creds’ display fields.sessionId doc-key concept to runId + add a frameworkSessionId. Backward-compatible.framework discriminator on agentBindings (+ workspace default).Hard seams ≈ 18–30 person-days
client.beta.sessions.create() is Anthropic-shaped (agent/environment/vaults). ADK create is unrelated.define_outcome / usage normalization / outcome_evaluations are all Anthropic.Keystone: a FrameworkAdapter interface (createSession · streamEvents · sendMessage · retrieve · normalizeUsage) with two implementations. Build the seam first; a 3rd framework then costs ~half.
Total estimate for a full second framework: ~25–40 person-days (best case clean ADK contract; worst case the event model diverges sharply). The in-platform build pipeline (agents-cli inside ETAP) is on top of that, and is the least-leverage piece.
Full dual-framework with in-platform build heaviest
The literal vision: per-workspace choice, and ETAP builds & uploads ADK agents via agents-cli. Adds Agent Engine + Cloud Run/GKE + Terraform + Cloud Build + a packaging pipeline, plus the session/streaming/UI adapters. ~40+ days and ongoing ops. Flips the content-ownership principle. Not recommended as a first move.
Recommended ADK agents, bind-and-drive (no in-platform build)
ADK agents are deployed to Agent Engine out-of-band (an operator or CI runs agents-cli deploy once), and ETAP simply binds them and drives sessions via the Agent-Engine reasoningEngines/…/sessions REST API — structurally symmetric to how it binds Console agents today. Keeps ETAP a control plane, reuses every clean seam, and still gets you Gemini/other models + EU-owned session data. You build only the FrameworkAdapter + credential + session-detail variant. This is the sweet spot if you want ADK at all.
Model expansion only
If the underlying want is “run Gemini / non-Claude,” note Anthropic Managed Agents are Claude-only — so the path to other models is ADK-bind-only (Option B), just framed by motive rather than by “framework choice.”
Don’t add now — harvest the ideas
Keep one framework; adopt agents-cli’s eval ideas into the Model-Fit Evals epic, and bank the confirmation that the KG MCP endpoint already serves any future ADK agent. Revisit when a concrete Gemini/residency requirement lands.
Before committing to any build, de-risk the single hard seam with a one-agent spike on staging:
agents-cli deploy --dry-run first to capture the exact gcloud calls).reasoningEngines/…/sessions/…/events REST surface from a throwaway route and render the event stream — this validates whether the FrameworkAdapter + session-detail renderer is tractable.That spike answers the only question with real uncertainty (can we render & drive ADK sessions cleanly?) for a day of effort, and everything else in this doc is already well-understood.
Investigation only — no production code changed. Confidence notes: agents-cli is pre-GA (v0.5.0) so its surface may shift; exact Vertex Agent-Engine IAM service-agent roles should be read from the live quickstart before provisioning; ADK v1.x-vs-v2.x track choice is deliberate. Sources: adk.dev & adk-docs, github.com/google/agents-cli + its docs site, Google Cloud Agent-Platform/Agent-Runtime docs, and a full coupling sweep of the ETAP codebase (sessions, run-index, secrets, triggers, MCP/KG, UI).