Jonathan Boniface
4fefe0ab33
Some checks failed
validation / verify (push) Failing after 10s
Record the direction and build plan for replacing the upstream google-cloud-solution-architecture skill with a portable agent. - ADR-0002: Agent Skills are the portable unit of behaviour, loaded by the framework's native skill runtime; discovery and grounding use each Cloud provider's hosted remote MCP servers. - ADR-0003: LangGraph holds Execution state, checkpoints and interrupts; a ReAct Orchestrator and Specialists run as ADK LlmAgents with SkillToolset. Supersedes ADR-0001. - CONTEXT.md: domain glossary (Execution, Phase, Approval, Revision, Orchestrator, Specialist, Deliverable, Dependency, Cloud provider). - .scratch/solution-architect-agent/spec.md: build spec with the dependency graph, Revision rules, tool tiers, MCP allowlists, A2A interaction, tests and nine build increments. - .scratch/phase-pipeline/spec.md: superseded; kept as decision log. - CLAUDE.md and docs/agents/: agent skill configuration (local markdown issue tracker, triage labels, domain docs). - README.md: direction note; flags current ADK classes as stubs. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2.3 KiB
2.3 KiB
status, supersedes
| status | supersedes |
|---|---|
| accepted | ADR-0001 |
LangGraph holds Execution state; ADK agents reason and act
An Execution is a hierarchy of ReAct agents shaped by the dependencies between Deliverables (ADR-0002).
- LangGraph holds the Execution. A LangGraph
StateGraphholds the dependency graph and each Deliverable's state. It checkpoints after every step and pauses withinterrupt()whenever the user must answer or approve. This follows the KAB workflow standard and the platform'slanggraph-workflow-agent. - ADK agents reason and act. The Orchestrator and every Specialist is an ADK
LlmAgent, each running its own ReAct loop, with aSkillToolsetfor progressive Skill loading. This follows the platform'sgoogle-adk-base-agent/app/skills_integration.py. - Agents sit behind one interface. Each agent runs behind a single agent-runtime interface, so LangChain Deep Agents can be added as a second implementation without touching the graph.
The dependency graph is declared as data in code. The Orchestrator picks what to do next through tools that refuse work whose dependencies aren't met. Dependencies are guaranteed by code, while ordering and parallelism are the model's choice.
Considered Options
- ADK end to end (root
LlmAgentwithsub_agents/AgentTool, and ADK sessions for pauses): rejected. It departs from the KAB workflow standard, and LangGraph's checkpointedinterrupt()is the proven platform path for resumable user Approvals. - Deep Agents end to end (
create_deep_agent(skills=, subagents=)): viable, and it compiles to LangGraph. It was deferred rather than rejected: ADKSkillToolsetalready has working prior art on this platform, and Deep Agents stays reachable as the second implementation of the agent-runtime interface. - Code runs the dependency graph with no Orchestrator model: rejected. The top level wouldn't be ReAct, and the Skill's conversational flexibility (such as skipping work the user says is already approved) would need hand-coding.
Consequences
- There are two frameworks in one process. Framework types stay inside the agent-runtime implementation and never appear in graph state.
- ADK Skills are Experimental (Python ≥ 1.25.0), so pin the version.