Moonshot AI / build
Kimi K3
A 2.8T-parameter MoE (896 experts, 16 active) with Kimi Delta Attention, native text/image/video input, and a 1M-token context window, positioned explicitly for long-horizon agentic software engineering — with a vendor demo of a single 48-hour autonomous run building, optimizing, and verifying a 45nm chip design (4mm² die, timing closure at 100 MHz, 1.46M standard cells) using open-source EDA tools and a vision-in-the-loop cycle of screenshots feeding back into code. Hosted via kimi.com, Kimi Code, API, and OpenRouter at $3/$15 per Mtok; open weights committed for Jul 27.
The demo is a vendor claim until the tech report and independent replications land, but the positioning is the signal: multi-day autonomy with built-in verification is now the frontier battleground, and vision-in-the-loop (look at the output, not just the logs) is the verification pattern to steal regardless of model. Engineering leaders should hold evaluation until the Jul 27 weights drop, then test long-horizon reliability on their own tasks rather than trusting a demo with unpublished prompts — and start designing supervision models for runs measured in days, because every lab is heading there.
Anthropic / build
Claude Code v2.1.208-214 (four releases in-window)
v2.1.212 shipped the delegation-budget layer (search and subagent session caps, MCP auto-backgrounding), /fork to spin a conversation into a new background session, and subagents inheriting the parent's permission mode; v2.1.214 fixed single-segment dir/** allow rules that were auto-approving nested writes anywhere in the tree, added message.uuid, client_request_id, and tool_source OpenTelemetry attributes for tool provenance, and put permission prompts on docker daemon-redirect flags; v2.1.211 made 'always allow' rules persist at repo root across worktrees and fixed a prompt-caching regression billing trailing system context as fresh input on Bedrock, Vertex, and other enterprise routes; v2.1.208 added CLAUDE_CODE_PROCESS_WRAPPER to route every self-spawned process through a corporate wrapper.
Two items are do-this-week material: audit your allow rules, because the dir/** glob bug meant rules you thought were scoped were approving writes across the whole tree — and glob semantics can silently change again on any harness update, so re-test rules after upgrades. Second, the OTel tool-provenance attributes plus the process wrapper are the raw material for a real agent audit trail; platform teams should start streaming them now rather than reconstructing provenance after an incident.
Cursor / cowork
Cursor in Slack (3.12)
Slack-invoked agents now respond with a plan before beginning work and post step-by-step status updates as they execute; named multi-repo environments define what an agent can touch; a mid-task 'Switch repository' button lets the human renegotiate the permission boundary while work is in flight; and agents can read and post across channels they are invited to.
The plan-first gate is the transferable pattern: when an agent is invoked from a chat surface — where prompts are casual and context is thin — forcing a stated plan before execution catches misunderstood scope at the cheapest possible moment. Adopt the gate on every chat-invoked agent whatever the vendor. Before rolling this integration out, review which channels the bot can reach: cross-channel read and post access is a data-flow decision disguised as a convenience feature.
Microsoft / cowork
Sales Agent + Service Agent GA, Copilot Cowork worldwide
Sales Agent and Service Agent reached general availability in M365 Copilot, grounded in Work IQ and Dynamics 365 data, with Dynamics plugins targeting team-scale workflows in Copilot Cowork; Cowork itself went GA worldwide on usage-based Copilot Credits with admin-configurable budgets and hard caps, and GPT-5.6 became the preferred model across Word, Excel, PowerPoint, Chat, and Cowork.
Function-specific agents on usage-based billing with admin hard caps is the enterprise distribution template the rest of the market will copy — the vendor productivity framing is a claim, but the billing architecture is a fact worth studying. Automation owners on the suite should set credit budgets and caps before adoption spreads organically, and treat the GA as the trigger to define who owns agent spend per function: the CRM admin, the Copilot admin, or finance.
xAI / build
Grok Build (open-sourced CLI agent harness)
The full source of the grok CLI agent harness landed on GitHub (xai-org/grok-build) under Apache 2.0: the Rust runtime with leader, stdio, and headless modes, the tool layer (terminal, file editing, search), and a VCS-aware workspace with checkpoints. The model endpoint is configurable — including air-gapped deployments — and headless mode targets CI; external pull requests are not accepted.
A production harness you can read, pin, fork, and run against any model endpoint is exactly the dependency posture the same week's Gemini CLI wind-down argues for. Platform teams should evaluate it less as a product and more as a reference architecture — the checkpoint and workspace design is worth studying even if you never deploy it — and note the no-external-PRs stance: this is source-available insurance, not a community project, so plan to maintain your fork.
Google / automate
Gemini CLI wind-down → Antigravity CLI (agy)
The individual-tier Gemini CLI shutdown completed this week: the agy successor is closed-source and cloud-required, with an 'agy plugin import gemini' migration path, skills relocating from .gemini/skills/ to .agents/skills/, and MCP servers moving into mcp_config.json profiles. Enterprise Gemini CLI continues under paid licenses only.
Any automation shelling out to the gemini binary on an individual tier is now dead code — inventory your scheduled jobs and CI pipelines for it this week, because these failures surface as silent skips, not alerts. The strategic read pairs with the grok-build release: free vendor CLIs are revocable infrastructure, so before wiring any agent CLI into a pipeline, ask whether you can pin the version and fork the source. If the answer is no to both, the dependency needs a documented exit plan on day one.