Antigravity tightens the sandbox, GPT-Live splits tools from speech, and Stripe scales skills (2026)

A CLI release made .git read-only, fixed runaway subagents, and stopped background MCP calls from blocking a turn. OpenAI's realtime stack moved tool work behind an asynchronous boundary. Stripe's internal agent now has more than 1,000 skills, and a startup raised $20 million to make enterprise deployment less dependent on consultants.

Those details point in one direction: the agent is becoming a managed system with an operating contract. The model still matters, but the hard product work is now in permissions, state, scheduling, verification, and the path from a recommendation to a real action.

This issue covers material published from August 2, 09:00 through August 4, 09:00, Asia/Shanghai, with the newest items weighted most heavily.

The read in one minute

Signal	What changed	Why it matters
Antigravity CLI 1.1.10	The GitHub release adds a read-only `.git` directory, earlier hook execution, bounded scheduling, correct subagent shutdown, and MCP background-call fixes. 1	Runtime safety is moving into defaults and lifecycle behavior, not only prompts.
GPT-Live's agent path	OpenAI separates continuous media handling from asynchronous delegation and tool work, while preparing warm model handoffs and context compaction. 2	Latency-sensitive work needs a different failure boundary from slow agent work.
June's funding round	June emerged from stealth with a reported $20 million pre-seed round and a system that maps legacy workflows into agent deployment steps. 3	Enterprise deployment itself is becoming an investable product category.
Stripe's Kai	A LangChain case study describes a company-wide agent built on Deep Agents, with 500+ internal MCP tools and 1,000+ skills; the team reports quality degradation beyond 150 skills in one context. 4	Skill routing and context budgets are architecture constraints at scale.
Production security checklist	A fresh MarkTechPost guide recommends inventorying agents, MCP servers, credentials, prompts, model versions, and data reach before adding runtime guardrails. 5	The first security control is knowing what exists and what it can touch.

The runtime is where autonomy gets bounded

Antigravity CLI's 1.1.10 release is a useful changelog because it treats failure modes as product behavior. The release makes a repository's .git directory read-only inside the terminal sandbox. The agent can inspect repository metadata, but it cannot rewrite that metadata from inside the sandbox. 1

It also moves hooks.json hooks ahead of built-in termination checks. That lets PostInvocation hooks see the final invocation and allows Stop hooks to run instead of being hidden behind the termination path. The schedule tool now accepts integral DurationSeconds and MaxIterations values as numbers, while rejecting non-integral values with an explicit error. 1

The more consequential fixes concern lifecycle edges. Stopping a subagent tree now stops descendant subagents and their background tasks. MCP tools marked to run in the background no longer block the turn, and an unexpected MCP disconnect no longer leaves a process behind. The release also fixes silent fallback when --model or --effort is supplied to interactive or headless runs. 1

For a builder, the checklist is concrete:

What can the agent write even when the task does not require a write?
Which hook can observe or veto the final action?
What happens to descendants and background work when the coordinator stops?
Can an MCP failure leak a process or stall the user-visible turn?
Which model and effort setting actually ran?

These are not exotic red-team questions. They are ordinary questions about whether a runtime keeps its promises under interruption, delegation, and partial failure.

OpenAI's August 3 engineering post describes GPT-Live as a full-duplex voice system: audio streams into and out of the model without waiting for discrete turns. The application separates a fast media path from slower application work, including delegation and tool use, with an asynchronous RPC boundary between them. 2

That choice solves a familiar agent problem. A tool call may take seconds or minutes, while the user expects the conversation to keep moving. If both share one blocking loop, the slow operation becomes a speech outage. OpenAI's design keeps the live path responsive while the application handles work elsewhere. The post also describes warming replacement model instances, carrying session context into them, and switching over without interrupting the media stream. 2

Context compaction is handled as another managed transition rather than as a surprise inside the live request. A replacement instance receives the compacted context before the system cuts over. The same architecture lets GPT-Live consult a frontier model such as GPT-5.5 without blocking the voice path. 2

The lesson transfers beyond voice. Separate at least three paths in an agent product:

Interaction path: the user sees status, can interrupt, and gets a bounded response.
Reasoning path: the system plans, retries, compacts context, or asks another model.
Action path: tools change files, call APIs, send messages, or create durable records.

A single queue is simpler to start with. It is also where latency, retries, cancellation, and side effects become entangled. The OpenAI post is an architecture report, not an independent benchmark, but its boundary choice is easy to test in another system: block the action path and see whether the interaction path still behaves correctly.

June is selling the missing layer between a demo and deployment

TechCrunch reports that June emerged from stealth with a $20 million pre-seed round led by Marc Benioff's Time Ventures, with additional backing from Michael Dell, Aaron Levie, and George Kurtz. June says its platform scans existing systems and business processes, identifies bottlenecks, and turns the findings into a step-by-step roadmap for deploying agent-powered workflows. 3

The startup's pitch is that building an agent template is the easy part. The difficult work sits in duplicate fields, fragmented data, old integrations, and undocumented process knowledge. June says users can click build on individual roadmap tasks after the system identifies what must be cleaned up or connected. 3

The article includes a customer account from CMG, a U.S. mortgage lender. Its chief strategy officer says the team had moved software engineering to Claude Code but stalled on Salesforce integration; June gave them a clearer deployment path. This is a customer and company claim reported by TechCrunch, not a controlled study of deployment speed or safety. 3

The investment signal is narrower than "AI deployment is solved." It says there is capital for the translation layer between a model's capability and an enterprise's actual system of record. A buyer should ask whether a deployment product leaves behind a repeatable map of data dependencies, approvals, owners, and rollback points, or whether it simply moves consulting work into a nicer interface.

Stripe's scale problem is skill selection, not skill collection

LangChain's case study says Stripe built Kai, its company-wide Knowledge AI Platform, on LangChain, LangGraph, and the open-source Deep Agents harness. The stack has a Deep Agents base layer, a Stripe-specific harness, a configuration layer for custom agents, and a user interface. Kai connects to Stripe's internal data warehouse, Slack, and Google Suite, and produces persistent reports, dashboards, and documents. 4

The implementation details matter more than the adoption headline. Stripe uses skills as agent-executable modules that describe how to do work and which tools to load. Skill ownership is federated across teams. allowedTools lists support dynamic loading, while foundational skills can be pinned so they remain available when the model unloads other material. 4

The case study also describes a virtual filesystem backed by S3, synchronized around sandbox execution, plus middleware for analytics, file processing, and long-running context summarization. Stripe reports more than 500 internal MCP tools and 1,000+ skills. It also reports quality degradation when more than 150 skills are combined with the system prompt. 4

Those numbers are company-reported, but the constraint is plausible and testable: more capability descriptions can make the agent worse if the selection layer cannot keep the active context focused. The next design question is not "How many tools can we expose?" It is "What is the smallest tool and skill set that can solve this task, and how do we know the selection was correct?"

The reported adoption figures are also company-reported: Kai grew from 296 users to more than 5,000 in roughly four weeks, with 83% of Stripe using it weekly and more than 60,000 sessions. They are useful as a deployment signal, not as an independently audited benchmark. 4

Security starts with an inventory that can drive a decision

A MarkTechPost guide published August 3 proposes a five-layer map for securing agents: interaction, agent configuration and memory, integrations such as MCP, the model layer, and generated code. The guide recommends recording an agent's identity, model dependency, autonomy level, tool permissions, credential scope, data reach, MCP endpoints, prompt location, and last review. 5

Its strongest practical advice is to turn discovery into a control loop:

scope credentials to specific resources and avoid sharing them between agents;
require human approval for high-impact tools;
keep system prompts in version control;
authenticate MCP servers and inspect tool descriptions before adoption;
pin model versions and assign an owner for end-of-life changes;
attach evidence to automated false-positive closures, and send unexplained cases to a human. 5

This is a sponsored, prescriptive guide rather than an independent measurement of security outcomes. Its value is the field list. A policy that says "protect the agent" is hard to implement; a record containing identity, permission scope, data reach, and review date can trigger an approval, a block, or a re-test.

What these signals add up to

The fresh evidence comes from different source types: a GitHub release, an OpenAI architecture post, a reported funding round, a vendor case study, and a sponsored security guide. They do not prove that one framework is best. They do show the same pressure appearing at different layers:

Execution: sandbox writes, hooks, schedules, descendants, and MCP processes need defined behavior.
Continuity: interaction, reasoning, and action paths need separate cancellation and latency rules.
Context: skills and tools need routing, persistence, and budget limits.
Deployment: enterprise agents need a map of legacy data and workflow dependencies.
Evidence: security controls need inventories and traces that can support a decision.

The practical frontier is therefore not simply a smarter model. It is a system that can say what it is allowed to do, what it actually did, and what happens when the work is interrupted.

What to do next

For builders: take one agent workflow and write down its three paths: interaction, reasoning, and action. Add a cancellation test, a tool-permission test, and a replayable trace before expanding its tool list.

For security teams: inventory agents, skills, MCP servers, prompts, credentials, and model versions. Treat missing ownership or unexplained data reach as a finding, even when no vulnerability identifier exists.

For founders: separate deployment mapping from agent generation in the product plan. The buyer may pay for the integration graph, approval path, and rollback evidence rather than for another chat surface.

For investors: read adoption metrics with their evidence label attached. A case study can show that a workflow exists and has users; it does not independently establish reliability, cost, or safety.

Scope note

No new agent-focused arXiv submission with a verifiable publication time inside this 48-hour window qualified for inclusion. The technical-research slot uses OpenAI's first-party engineering account of GPT-Live's delegation and context architecture instead of backfilling with older papers. The issue therefore supports a narrower conclusion: the newest signals were about shipping and governing the runtime around agents, not a fresh benchmark result.