Building the agent toolchain: any-framework CLIs, agent-scale git, durable workflows

Framework-agnostic agents

Google introduced the Agents CLI Extension System so developers can use LangChain, LangGraph, or custom enterprise stacks while retaining a unified deployment and evaluation workflow. A first-party LangChain template scaffolds, runs, and deploys agents without requiring the Agent Development Kit, and platform teams can author custom extensions to enforce policies — the worked example is automated software bill of materials (SBOM) scans during deployment. The message is that agent development is growing up into platform engineering: bring your framework, keep the guardrails. m:…6322

The extension model matters because it moves governance into the deployment path rather than leaving it as documentation. Custom extensions can enforce policies during deployment, which means a platform team can require SBOM scans, data-handling checks, or approval gates as code — the same way infrastructure teams standardized CI checks years ago. For enterprises with custom stacks, the system explicitly supports stacks that are neither ADK nor LangChain, avoiding a rip-and-replace of whatever agent code already exists. m:…6322

Git for the agent era

GitHub is migrating its Git infrastructure to Azure, saying the timing and shape of the move were driven by the agentic shift: exponentially growing traffic, a hard ceiling on data-center power capacity, and physical supply-chain constraints. The engineering changes are deep — per-reference serialization so only writes contending on a shared reference wait, decoupling storage from compute so read replicas scale on demand from Azure Blob Storage, and a first fully ephemeral virtual write replica that bridges to object storage. In internal testing with realistic traffic, writes to different references saw 3-4x higher throughput at lower latency. Azure now serves about half of Git traffic, and 99.99999 percent of repositories live in both GitHub data centers and Azure. m:…1835

Long-running work

Oracle shipped two pieces of the same puzzle. The Service Execution Workspace, released in the 26D update, is an agentic application for service teams shifting from transaction-based work to outcome-oriented processes: representatives get workload insights and priority requests, can investigate with Ask Oracle, and review AI-generated procedures against an Evidence Locker before submitting them for knowledge creation. AI-prepared resolutions require human review, acceptance, or modification before reaching customer communication, and the workspace respects existing access controls without creating new data access. Capabilities like knowledge authoring and SLA management are explicitly not in this release. m:…1941

For the plumbing underneath, Brijesh Deo's writeup on Oracle MicroTx Workflows and TxEventQ tackles processes that run for hours or days — beyond any HTTP request-response lifecycle. The pattern: decouple business logic from execution state, resume from recorded state after worker restarts rather than replaying entire claims, support HTTP, SQL, agentic, human, and wait tasks, and use idempotency keys, correlation IDs, and causation IDs so retries and events cannot create duplicate work. A queue alone moves messages, the piece argues; it does not own the business process, its state, its deadlines, or its recovery decisions. m:…8327

What it means

This is my read, not a reported fact: three layers of the same realization. Agents are now first-class producers of work — code, commits, service resolutions — and the tooling is catching up: policy enforcement at deploy time, elastic infrastructure underneath, durable state for long runs. Developers should expect agent-ready to become a procurement checkbox the way SSO did, and the teams that instrument agent activity early will have the cost and governance data everyone else scrambles for later. m:…6322 m:…1835