A Comparative Study of Agentic Frameworks and Multi-Agent OrchestrationÂ
Earlier this week, we explored how Bruce Mcpherson’s gas-fakes agent provides a secure, sandboxed alternative to my initial experiments with the Workspace CLI. While securing local execution is a necessary step, it surfaces an entirely new operational headache. As we build out these agentic behaviours, what happens when your AI has access to too many tools?
As Kanshi Tanaike identifies, these systems hit a cognitive wall known as ‘Tool Space Interference’, a concept recently detailed by Microsoft researchers, which is widely recognised across the industry as context bloat. As noted in Google’s recent engineering piece on architecting context-aware frameworks, “single-agent systems struggle with context bloat; multi-agent systems amplify it.” If you load an agent’s active memory with 160 different Workspace functions, its reasoning accuracy degrades significantly; your token costs also spiral out of control.
Tanaike tackles this phenomenon head-on in his latest comparative study. He contextualises my own CLI skill-based prototyping and Bruce’s local emulation, mapping them against the architecture of the newly announced Gemini Enterprise Agent Platform at Google Cloud Next ’26.
I must admit, while I was proudly figuring out how to chain a few CLI commands together without crashing my terminal, Tanaike was already designing complex orchestration networks using multiple autonomous agents to resolve this friction.
Delegating to Sub-Agents
To combat Tool Space Interference, Tanaike proposes dynamic tool creation. Rather than pre-loading an agent with functions, a primary orchestrator delegates tasks to sub-agents that write, test, and deploy custom Google Apps Script code on the fly. This entirely removes the need to store static skills in the agent’s memory.
Alternatively, he suggests using the Agent-to-Agent (A2A) protocol to shift large libraries of predefined skills onto remote Apps Script Web Apps. By bypassing complex cross-domain authentication using local agent cards, this method clears the main agent’s active memory while retaining frictionless access to legacy macros.
The Conscious Expert: Zero-Trust Routing and Caching
To safely manage these multi-agent delegations, Tanaike introduces two advanced frameworks: the Federated Context-Aware Routing Architecture (Federated CARA) and the Self-Optimising Tool Caching Network (SOTCN). From a data governance perspective, these concepts provide a fascinating blueprint for enterprise security when combined.
Federated CARA acts as a zero-trust architecture that evaluates the classification of the data involved in any given prompt. Based on this sensitivity, it dynamically routes the AI task to either a containerised emulation environment or a remote A2A subagent. This design maps perfectly to the Agent Gateway and Agent Identity features introduced within the Gemini Enterprise Agent Platform, ensuring that native IAM access control policies are strictly enforced to guard against data exfiltration.
Building on this secure routing pipeline, SOTCN functions as an additional security perimeter by treating skills as modular assets kept in “cold storage”. By using semantic search, the network programmatically retrieves and inserts only the necessary capabilities into the agent’s prompt during a given session. This approach has just been validated by the launch of Google’s official Agent Skills repository at Next ’26. By publishing compact, agent-first Markdown files to be loaded entirely on demand, Google is signalling a wider industry push towards “Context Engineering”.
Tanaike’s synthesis offers a highly scalable roadmap for multi-agent orchestration. I highly recommend reading his full paper and watching the accompanying explanatory video to see how these architectures align with Google’s new enterprise standards.
