Hi, I’m lightlost. I’ve been focusing on agent architectures and complex AI systems, especially orchestration, interoperability, evaluation, reliability, and the boundaries between frameworks and runtimes. ADK and A2A have been areas I’ve followed closely, and I’ve also been participating in recent ADK community discussions.
One question that came up for me recently is how we should think about the boundary between framework-owned orchestration and runtime-owned execution as agent APIs take on more lifecycle responsibilities.
ADK is no longer only about defining an agent and giving it tools.
The current API surface increasingly covers parts of the execution lifecycle itself:
ADK
Agent / BaseAgent
│
├── Sequential / Parallel / Loop
├── Workflow / delegation
│
Runner / App
│
├── callbacks / plugins
├── tool lifecycle
├── session state
├── memory
├── context compaction
└── resumability / HITL
At the same time, Agents CLI adds another engineering layer around these primitives.
Its workflow connects understanding the task, studying reference recipes, scaffolding, implementation, evaluation, deployment and observation.
The reference material also points to patterns such as the long-horizon harness, where concerns such as sandboxing, cross-session memory, skills, guardrails, delegation, durable human approval, scheduling and long-running execution are composed around ADK and managed runtime primitives.
That gives me a rough picture like this:
ADK APIs
│
Agent / Workflow / Runner
Session / Memory / Tools
Resume / Compaction / HITL
│
▼
Agents CLI
│
Skills / Recipes / Workflow
│
▼
Harness
│
policy / guardrails / context
delegation / long-horizon logic
│
▼
Runtime
persistence / execution /
infrastructure / recovery
I do not think these layers need to be strictly separated.
In fact, some overlap seems useful and probably unavoidable.
What interests me more is how ownership should work when multiple layers participate in the same lifecycle concern.
One simple way I have been trying to think about this is:
Capability
│
├── Mechanism
│
├── Policy
│
└── Authority
For example, a framework may provide a resumability mechanism, while a surrounding harness decides when an execution is allowed to resume, and the final authority may still belong to an application policy or a human approval boundary.
The same distinction seems useful for memory, retries, context compaction, tool execution and delegation.
Resumability mechanism
≠
Recovery policy
≠
Authority to continue execution
Memory persistence
≠
Memory policy
≠
Ownership of remembered state
Tool execution capability
≠
Execution policy
≠
Permission to cause a side effect
So I am starting to wonder whether the boundary is becoming less about simply asking:
Framework or runtime?
and more about asking:
Who provides the mechanism?
Who defines the policy?
Who remains authoritative?
I may be oversimplifying some of these boundaries, especially as ADK, Agents CLI and managed agent runtimes continue to evolve.
I’m mainly interested in whether this is a useful way to reason about real ADK systems, and where others have found the boundary becoming visible in practice — particularly around state, recovery, resumability, delegation and long-running execution.