Introducing Shieldstral.

Shieldstral introduces a 3B open-weights multimodal safety classifier that outperforms models up to 7x its size by framing content moderation as a policy-adaptive question-answering task. Unlike traditional guardrail models, it accepts plain-language policies at inference time, unifying text and image safety evaluation without retraining. Released under Apache 2.0, it delivers calibrated safety scores across diverse benchmarks while running efficiently on a single 16GB NVIDIA GPU.

A 3B open-weights, policy-adaptive multimodal safety classifier that matches models up to 7x its size on text safety and sets a new state of the art on multimodal moderation.

“Does this content promote violence against a protected group? Is this image safe to show to a minor? Did the assistant refuse the request?”

Every product that ships a model needs to answer questions like these — but the right answer depends on the product, the audience, and the moment. The same content can be fine for a cybersecurity research tool and harmful on a mental-health platform. Most guardrail models bake a fixed taxonomy of harm categories into their weights, so re-targeting them to a new deployment context means retraining. And because safety definitions differ across applications and domains, there is no single "correct" set of categories to model in the first place.

Shieldstral takes a different approach: you write the policy as a plain-language question at inference time, and the model returns a calibrated safety score. No retraining, one interface for text and images, and a verdict from a single token. Please refer to our technical report here.

As an inaugural member of the Open Secure AI Alliance with NVIDIA and other organizations, today we're releasing Shieldstral as open weights under Apache 2.0, available for download here.

Moderation as a question

Shieldstral frames content moderation as a binary question-answering task. Each request has three parts:

• <Instruct> — the evaluation context, strictness, and (optionally) a definition of what counts as unsafe content.
• <Query> — a single yes/no question, e.g. "Does this content promote physical violence?"
• <Document> — the content to judge: a prompt, a response, a prompt–response pair, or an image with optional text.

At inference the model reads out only the yes and no logits and softmax-normalizes them into a continuous safety score. This one simple formulation does a lot of work: it unifies prompt classification, response moderation, refusal detection, and toxicity detection into a single problem; it lets policies live entirely in the prompt, so one checkpoint adapts to novel policies at deployment time.

Highlights

• Strong performance — matches or outperforms open guard models up to 7× its size across text safety, refusal detection, policy adaptability, and multimodal benchmarks.
• Adaptive and flexible — a single natural-language interface covers text, image, and text+image content across prompts, responses, and prompt–response pairs. Policies are supplied as free-form queries and re-targeted at inference time, without retraining.
• Small, trained on heterogeneous sources — a 3B model that runs on a single 16GB GPU, trained on real and synthetic data with diverse label formats and taxonomies, consolidated into one framework.
• Continuous safety score — returns a calibrated yes/no probability from a single forward pass, so you can threshold or rank by confidence rather than relying on a discrete label.
• Open — Apache 2.0 weights.

Benchmarks

We evaluate Shieldstral against open guard models up to 7x its size across four axes. All evaluation samples are held out from training.

• Text safety
• Refusal detection
• Policy adaptability
• Multimodal safety

How we built it

The core idea is that a small model can beat much larger ones if the data is right. Getting the data right meant solving four problems:

Unify heterogeneous data. Public safety datasets disagree on taxonomies, labels, and annotation conventions — from binary safe/unsafe flags to fine-grained multi-label taxonomies. We convert every dataset into the same instruction–query–document format with a per-dataset processor, and we vary the wording of instructions, queries, and prompt–response delimiters so the model generalizes across phrasing instead of overfitting to one style. We also calibrate strictness per source — strict for adversarial jailbreaks, lenient for response-quality data — so the model learns calibrated decision boundaries. This lets us consolidate sources that would otherwise be incompatible.

Teach discrimination, not memorization. If trained on a fixed set of policy labels, a model learns only to classify those predefined policies, rather than reasoning about the precise boundaries of a given policy. This prevents generalization to novel policies. Instead, we construct sets of deliberately similar, easily confused policies and ask an LLM to rewrite safe text into contrastive pairs: each rewrite is engineered to violate one policy but not its sibling. This trains the model to distinguish which specific policy a piece of content violates, a skill that transfers to unseen, user-defined policies at inference time.

Ground safety in images. Unsafe images can't be synthezised by an LLM the way text can, so visual safety data is scarce. We supplement limited moderation datasets with general-purpose image datasets as high-quality negatives, mutate queries to augment the dataset, and filter every image–query pair through a vision–language reranker to reduce mislabeled data and hallucinations.

Combine complementary checkpoints. We fine-tune with LoRA and merge — via SLERP — a checkpoint calibrated on public data, one that adds fine-grained policy discrimination from generated data, and the base instruct model. The merge recovers common policy calibration and policy adaptability in a single model, and instruction-following from the base model transfers to the moderation task.

Forge. We built Shieldstral end to end on Forge, our platform for training, aligning, and evaluating custom models. Forge managed the infrastructure, data and model sharding, metrics, and logging on top of state-of-the-art distributed training, so the team could stay focused on the data which is what determines the safety model's quality.

What's next

Shieldstral is a step toward moderation that adapts to context instead of forcing every product through one frozen taxonomy. We're continuing to push on multilingual coverage, longer-document robustness, and broader multimodal safety — and we'd love to see what the community builds on top of it.

Today, we release LFM2.5-2.6B, an agentic model that runs entirely on-device. It is small enough to run on a phone, fast enough to stay responsive on a CPU, and capable enough to power agentic workflows: planning, calling tools, and tackling multi-step tasks.

Unlike agents that depend on cloud APIs, local agents give you free inference, low latency, and real privacy. Removing the per-token cost changes how developers build: agents can now be massively parallelized on local hardware, running background tasks that burn through millions of tokens at no marginal cost. When token spend is no longer a constraint, agents can be run everywhere around the clock.

The base (LFM2.5-2.6B-Base) and post-trained (LFM2.5-2.6B) models are available today on Hugging Face. Check out our docs on how to run and fine-tune them locally.

Training

LFM2.5-2.6B is a 2.6B parameter model specifically trained for agentic workloads. It's pre-trained on ~34T tokens. To better support non-Latin scripts in LFM2.5, we doubled the vocabulary to 128K by extending the existing tokenizer in place rather than retraining the model from scratch, using the same procedure as in LFM2.5-8B-A1B. Mid-training includes a dedicated 128K context-extension phase so the model can handle the long inputs that agentic workloads require.

The schematic summarizes the four-stage post-training pipeline that turns LFM2.5-2.6B-Base into the agentic LFM2.5-2.6B: Supervised Fine-Tuning (SFT), Teacher Specialization, Multi-Domain On-Policy Distillation (MOPD), and Agentic Reinforcement Learning (Agentic RL).

Supervised fine-tuning. Post-training begins with two consecutive SFT stages: starting with broad coverage across all domains, followed by targeted shaping on priority skills like agentic tasks, reasoning, and tool use. Across the two stages, the SFT training mix is about seven times the size of the one used for LFM2.5-8B-A1B, with heavier weighting toward agentic tasks such as tool use, web search, software engineering, and agent traces. The final SFT checkpoint serves as both the student model and the initialization checkpoint for training a set of specialist teachers for a later distillation stage.

Teacher Specialization. From the shared SFT checkpoint, we train one expert per target domain through a focused SFT round on a reweighted mix, followed by reinforcement learning with verifiable rewards (RLVR). The resulting specialists cover instruction following, math, knowledge including hallucination control, code, tool use, and long context. Training them separately lets each expert optimize deeply for its own domain, using targeted data and rewards without competing updates from unrelated objectives.

MOPD. We then use the specialized experts as teachers and distill their capabilities into a single student model. Unlike off-policy distillation, where the student learns from trajectories generated by another model, MOPD lets the student roll out under its own policy. Each prompt is routed to the teacher for its corresponding domain, which supervises the student's response with token-level feedback.

Because the teachers branch from the same SFT checkpoint as the student, their feedback stays close enough to the student's distribution to guide learning without destabilizing training. This dense, routed supervision helps the student converge quickly while integrating domain-specialized capabilities into a single model.

Agentic RL. The final stage teaches the model to operate inside real agent environments. We run multi-turn agentic RL through real agent harnesses, where the model works through realistic productivity tasks that evaluate its ability to research, write, code, analyze data, manage documents, use external tools, and automate multi-step workflows.

During training, we sample a task and randomly select a corresponding harness. Each rollout runs in a dedicated sandbox with its own runtime. We optimize with GRPO, using an outcome-based reward that combines an LLM-as-a-judge rubric, programmatic checks, and a hard safety gate. Training directly inside Hermes Agent, OpenClaw, and other harnesses exposes the model to their tools, system prompts, and interaction patterns, helping it work reliably across agent environments.

The training pipeline separates model optimization, inference, and environment execution into distinct components. The Training Engine (FSDP) optimizes the model, while the Rollout Engine (SGLang) generates actions using the latest policy. The RL framework (verl) orchestrates the training loop by launching rollouts, collecting trajectories and rewards, and updating the model.

Benchmarks

We evaluated LFM2.5-2.6B across benchmarks covering STEM, instruction following, tool use, and agentic workflows. Despite being the smallest model in the comparison, it is competitive with, and often outperforms, models nearly four times its size.

LFM2.5-2.6B leads on every instruction-following benchmark and nearly every tool use benchmark, trailing only Qwen3.5-9B on BFCLv4. On agentic tasks, it outperforms both Gemma models across the board and trades closely with the Qwen models. On STEM, it leads on AA Omniscience and trails only Qwen3.5-9B on math. Coding is the one area where the larger models keep an edge.

These results make LFM2.5-2.6B a strong fit for high-volume agentic workloads on edge devices, especially when speed, privacy, and local deployment matter. For more complex agentic tasks or coding-heavy workloads, larger models may still be a better fit.

Fast Inference Everywhere

LFM2.5-2.6B ships with day-one support across the inference ecosystem:

• llama.cpp — GGUF checkpoints for efficient edge inference
• MLX — Optimized inference for Apple Silicon
• vLLM — GPU-accelerated serving for production throughput
• SGLang — GPU-accelerated serving for production throughput
• ONNX — Cross-platform inference across diverse accelerators

CPU inference. Due to the efficient LFM2 architecture, LFM2.5-2.6B is the fastest model we tested at reading in prompts and generating answers, decoding 220 tokens/s on an M5 Max and 113 tokens/s on a Ryzen AI Max+ 395 while staying under 2.5 GB. It even holds 30 tokens/s on a phone, so a capable agent runs instantly and privately on your own device.

GPU inference. We also measure output throughput on a single NVIDIA H100 SXM5 GPU using a sustained-load setting. LFM2.5-2.6B is the fastest model in its size class, reaching almost 15K output tokens per second at high concurrency, roughly 1.3B tokens per day on a single H100.

Run local agents with LFM2.5-2.6B

LFM2.5-2.6B’s size, speed, and capabilities make it a great choice for high-volume agentic workloads on edge devices. Setting up your own local agent takes only two steps. First, serve LFM2.5-2.6B behind an OpenAI-compatible endpoint, then point your agent harness at it. It works out of the box with popular harnesses like Hermes Agent, OpenClaw, and Pi. Check out our guide for how to serve the model locally and connect it with the agent harness of your choice.

Get Started

Start building today with LFM2.5-2.6B and LFM2.5-2.6B-Base, available on Hugging Face.

With LFM2.5, we're delivering on our vision of AI that runs anywhere. These models are:

• Open-weight — Download, fine-tune, and deploy without restrictions
• Fast from day one — Native support for llama.cpp, MLX, and vLLM across Apple, AMD, Qualcomm, and NVIDIA hardware
• A complete family — From base models for customization to specialized audio and vision variants, one architecture covers diverse use cases

We can't wait to see what you build.

Citation

Please cite this article as:

Liquid AI, "LFM2.5-2.6B: Deploy Agents Everywhere", Liquid AI Blog, Aug 2026.

@article{liquidAI202626B,
  author  = {Liquid AI},
  title   = {LFM2.5-2.6B: Deploy Agents Everywhere},
  journal = {Liquid AI Blog},
  year    = {2026},
  note    = {www.liquid.ai/blog/lfm2-5-2-6b},
}

All the models were evaluated with vLLM and the following generation parameters:

• BFCLv4: temperature = 0.001, max output tokens = 4096.
• ToolSandBox: temperature = 0, max output tokens = 1024.
• PinchBench: temperature = 0.6, max output tokens = 8192.
• τ³-Bench, Claw-Eval: temperature = 0, no output limit. Qwen models use temperature = 0.6 (per the recommended settings), as greedy decoding degrades performance due to doom looping.
• Other evals: temperature = 0.6, max output tokens = 32768.

Full article content is not available for inline reading.

Read the original article →

Over the past four months, our AI code reviewer has flagged nearly a quarter of a million deviations from Cloudflare engineering standards (what we’ll call “violations” in this post) and blocked 16,000 merges. Our spec reviewer agent has evaluated close to 600 technical designs against the same standards before implementation began. Both systems draw from the Cloudflare Codex, a shared source of engineering guidance built for people and agents. This post explains why we built the Codex, how it supports the engineering lifecycle, and what we plan to do next.

Before the Codex (which we briefly introduced in a previous post about our AI engineering stack), developer guidance at Cloudflare lived in many places: formal documentation, repository files, chat threads, and the accumulated knowledge of individual engineers. Engineers often spent too much time searching for guidance instead of working on the problem they were trying to solve. Even after finding an answer, they could not always tell whether it was current, authoritative, or applicable to their situation.

As Cloudflare grew, that model became increasingly difficult to sustain. No engineer could read every standard, and reviewers could not reliably check every requirement. Institutional knowledge became harder to recover when people moved between teams, and guidance that was not consistently surfaced or enforced led to drift between projects.

We rebuilt this body of knowledge as the Cloudflare Codex: a governed set of engineering standards that agents can retrieve and apply at the point of work. The same guidance can now inform code review, technical design review, incident report review, and many other use cases, while engineers focus their time and judgment on the resulting findings.

Codex organization and workflow

A dedicated Codex governance model divides the Codex into distinct domains covering the engineering areas we care about. These include architectural matters (for example, frontend and control plane), cross-cutting concerns (security and reliability), specific languages (TypeScript and Rust), and several other areas. Each domain is led by an owner who is responsible for the content, consistency, and overall quality of the documents they oversee.

Codex standards use a Request for Comments (RFC) format. Requirements use the SHOULD and MUST keywords defined by RFC 2119. We also expect a front matter header to hold metadata such as the domain and RFC status. Any Cloudflare employee with a key interest and domain competency can propose an RFC through a merge request that follows the prescribed structure. The proposal then passes through several rounds of feedback from an increasingly broad group of reviewers. Once the domain owner gives final approval, the RFC becomes part of the Codex and is published to an Astro-powered internal site.

Approved RFCs can be consumed by Codex clients and agents, which may then start to flag Codex violations in code, configuration, or documentation immediately. However, they block based on Codex statements only after an RFC moves from the approved to the enforced lifecycle state. This separate promotion step gives teams time to absorb new requirements and accommodates cases where enforcement needs additional work.

The following diagram illustrates the steps in the Codex workflow:

Approved RFCs produce non-blocking findings; after explicit promotion, enforced RFCs block violations of MUST requirements

A naive process could stop here and feed the entire Codex to a large language model (LLM) as is. Given the increasing number of RFCs we have already (60+ and counting), however, the corpus volume would put a lot of stress on the context window and impact LLM results negatively. To help guide models to the most relevant RFCs, we invoke a purpose-built agent to automatically extract and compact the SHOULD and MUST statements into a dedicated JSON structure and enrich it with metadata that supports lazy discovery and progressive disclosure. The following abridged excerpt shows the result for our control plane services RFC:

{
  "rfc": 14,
  "title": "Control Plane Services",
  "status": "approved",
  "domain": "control-plane",
  "statements": [
    {
      "slug": "use-quicksilver-for-edge-configuration-propagation",
      "section": ["Proposal", "Infrastructure"],
      "level": "SHOULD",
      "text": "If you need to propagate system or customer configuration to the edge, use Quicksilver via the outbox pattern",
      "href": "/rfcs/014-control-plane-services/#infrastructure"
    },
    {
      "slug": "api-schemas-must-be-documented-in-openapi-spec",
      "section": ["Proposal", "API Gateway"],
      "level": "MUST",
      "text": "API request and response schemas MUST be documented using an OpenAPI spec",
      "href": "/rfcs/014-control-plane-services/#api-gateway"
    }
  ]
}

Each statement receives a stable slug identifier that remains unchanged during the extraction process even when its RFC is updated. The identifier lets us track the same statement across different systems over time, which is essential for monitoring, analysis, and exception handling.

Initially, we extracted the statements into another, more concise Markdown file rather than JSON. Over time, we moved to a richer structured format so that agents could filter the content they needed more accurately. We plan to include additional metadata for even tighter scoping, such as indicators for the software development life cycle (SDLC) stage a statement applies to (e.g., design, implementation, runtime).

Codex consumers

Several systems already use the Codex in day-to-day engineering work. Three agents show how the Codex works in practice: our AI code reviewer, spec reviewer, and incident report reviewer.

AI code reviewer

Our AI code reviewer agent, covered in a separate blog post, evaluates merge requests across several dimensions, including Codex compliance.

For each review, the agent retrieves the RFCs and parses the Codex statements. It loads full RFC bodies only when the model or coordinator needs additional context. In most cases, the statements provide enough information to explain a reported violation.

The distinction between SHOULD and MUST, together with an RFC’s status, determines how the reviewer responds. Findings from approved RFCs are non-blocking recommendations. Once an RFC is enforced, an unsatisfied MUST requirement causes the reviewer to withhold approval or block a merge request, depending on the severity.

Since the Codex’s inception earlier this year, the AI code reviewer has flagged close to 230,000 violations. Among these, almost 16,000 caused approval to be withheld (i.e., they referred to MUST statements on enforced RFCs).

Code review alternatives

A single AI code reviewer run usually takes a couple of minutes to complete due to the coordinator framework and sub-agent execution. Although the wait is very often worth the money (or tokens), engineers were calling out the delay and extra round trip involved in remediating the findings. We looked into how we could improve the experience and came up with two additional options:

1. For language-specific Codex requirements that can be verified mechanically, we provide custom linter configuration packages. These are aligned with our Codex specification and make it possible to surface problems in milliseconds. TypeScript was the first language to receive Codex linter support while also standardizing on oxlint (maintained by the VoidZero team who joined Cloudflare recently) for performant linter execution. A linter for Rust projects is currently under development, and Go will eventually follow to complete coverage of Cloudflare’s most commonly used languages.
2. To cut out the continuous integration (CI) leg from the review cycle, we made it possible to run the AI code reviewer locally through a command-line interface (CLI). It matches the coordinator functionality from CI and runs the same (OpenCode-based) agents against an automatically determined diff set, with results presented in the terminal.

We believe the linters would be useful to almost every developer and codebase, while the CLI remains an optional alternative for engineers who prefer it.

Spec reviewer

Engineers at Cloudflare regularly write design documents and technical specifications (or specs in short) before implementation. A significant subset of the Codex pertains to design, architecture, and other themes relevant to technical reviews. To catch architectural mistakes before implementation begins, we built the spec reviewer, an agent that discovers specs and evaluates them against relevant Codex requirements.

The spec reviewer operates on the Developer Platform: it runs as a Cloudflare Worker, stores its results and state in D1, routes model requests through AI Gateway, and kicks off scanning for new specs via a Cron Trigger. It starts by filtering the Codex by domains and sections relevant to specs (for example, language features and implementation-focused RFCs are disregarded). Several guiding prompts instruct the model on how to run the assessment and frame the results. The findings get rated based on severity (influenced by SHOULD and MUST keywords) and include general quality and architectural advice. On completion of a review run, a note is left on the spec document linking to a custom dashboard where review details can be inspected.

Since the beginning of May 2026, almost 600 unique open specs have been reviewed. Including reruns triggered on demand or by spec changes, we tracked over 3,200 review invocations to this date. The vast majority of findings had a “major” (65%) or “minor” (29%) severity, with “critical” findings being the minority (6%).

The following image gives an impression of what the spec reviewer UI looks like:

Incident report reviewer

The incident report reviewer applies the same approach to incident reports (also known as postmortems). In addition to checking that each report is complete, it evaluates whether the report clearly explains what happened, identifies contributing factors, documents the resolution, and proposes meaningful follow-up actions. These expectations are defined in a dedicated Codex RFC.

The incident report reviewer uses the same Developer Platform building blocks as the spec reviewer. This shared architecture is becoming a common pattern for our Codex agents.

Since May 2026, the reviewer has assessed more than 200 incident reports and identified gaps such as missing follow-up action items, incomplete timelines, and omitted detection signals. Among those reports, 93% covered incidents that were low-impact, internal-only, or declared preemptively. For high-severity incidents, we’ve made the reviewer mandatory as part of our comprehensive central review process, and reports are not considered complete until all findings have been addressed.

Future work

The Codex already supports agents that review code, technical designs, and incident reports. We plan to extend that model throughout the SDLC, allowing agents to surface issues consistently across design, implementation, and operations. The longer-term goal is for agents to identify issues as well as propose fixes with increasing autonomy, while engineers remain responsible for reviewing and approving those changes.

We are also expanding the Codex beyond engineering. Product, security, compliance, and trust and safety teams are beginning to add their own standards, allowing agents to evaluate work against considerations that extend beyond design and implementation alone.

Across a number of engineering workflows, Codex-backed agents have helped us surface issues sooner and apply standards more consistently. We have found AI most useful when it brings the right guidance to engineers at the point of work, and plan to keep extending the approach across Cloudflare.

Gateway API v1.6: TCPRoute and UDPRoute Graduate to Standard

The Kubernetes SIG Network community is thrilled to share the release of Gateway API v1.6.0, which was released on June 30th of this year!

Gateway API has become the standard for modern, role-oriented, and expressive service networking in Kubernetes. In previous releases, Gateway API established a production-grade foundation for HTTP and TLS layer 7 traffic. With version 1.6.0, Gateway API takes a major step forward by expanding standard layer 4 protocol routing and introducing cleaner API boundaries for experimental innovation.

Here is a quick summary of what's new in Gateway API v1.6.0:

• TCPRoute and UDPRoute Graduate to Standard: Raw L4 TCP and UDP traffic routing reach GA stability in the v1 API version.
• Experimental API Group Separation: Experimental resources transition to a distinct API group (gateway.networking.x-k8s.io) with an X prefix to make experimental vs. standard boundaries crystal clear.

Let's dive into the details!

TCPRoute and UDPRoute graduate to Standard

Until now, Gateway API only offered a stable routing model for HTTP and TLS traffic. Workloads that speak a raw protocol over TCP or UDP - databases, DNS, VoIP, gaming, IoT telemetry - had no portable way to plug into a Gateway. Users either fell back to a plain Kubernetes Service, or to an implementation-specific CRD that doesn't travel between Gateway controllers.

TCPRoute and UDPRoute close that gap: they route traffic to backends based on protocol and port alone, no L7 awareness required. With this release, both have graduated from the Experimental channel to Standard, and moved to the v1 API version. The v1alpha2 version of each was deprecated as of the v1.6 release, and will be removed in a future release.

How it works

A Gateway needs a listener that allows TCPRoute attachment:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: TCP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: TCPRoute

A TCPRoute then attaches to that listener and forwards traffic to a backend:

apiVersion: gateway.networking.k8s.io/v1
kind: TCPRoute
metadata:
  name: tcp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

Traffic arriving on the Gateway's port 12345 is proxied to the endpoints of my-foo-service on port 6000. Omitting sectionName and port from parentRefs attaches the route to every TCP listener on the Gateway instead of a single one.

UDPRoute follows the same pattern; swap the listener protocol and the route kind:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: example-gateway
spec:
  gatewayClassName: example-gateway-class
  listeners:
    - name: foo
      protocol: UDP
      port: 12345
      allowedRoutes:
        kinds:
          - kind: UDPRoute
---
apiVersion: gateway.networking.k8s.io/v1
kind: UDPRoute
metadata:
  name: udp-app
spec:
  parentRefs:
    - name: example-gateway
      sectionName: foo
  rules:
    - backendRefs:
        - name: my-foo-service
          port: 6000

XBackend arrives in Experimental

Gateway API v1.6 introduces the new XBackend resource, which is a general-purpose decorator for Service (and other backend types) within Gateway API.

The Service resource is an amazing, stable, and flexible object, but that comes with some costs: The flexibility creates a lot of edge cases that Gateway API needs to handle, and the stability makes it impossible to add new concepts to Service.

The XBackend resource builds on the ideas in the upstream EndpointSelector KEP, to add a Gateway API-native object that still targets the backend app, while allowing the community to extend it to handle use cases that are difficult or dangerous to handle with Service.

The first version of XBackend includes support for ExternalHostname destinations, which are ruled out from Service support in Gateway API because of the possibility of confused deputy attacks.

For XBackend, this support is an Extended/Optional feature, allowing implementations and users to opt in once they understand the security tradeoffs.

This support is very useful for egress use cases (which are most commonly used for cluster-hosted agentic workloads), which the community is also working towards formalizing in GEPs about Gateways for Egress.

The XBackend API is experimental and its behavior can change, do not assume it is ready for production

An example of a Gateway with an ExternalName backend that can be used for egress to a cloud AI API is as follows:

# Gateway-level TLS remains authoritative for incoming connections
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
spec:
  listeners:
  - name: https
    protocol: HTTPS
    tls:
      certificateRefs:
      - name: gateway-cert
---
# Backend resource for external destination
apiVersion: gateway.networking.x-k8s.io/v1alpha1
kind: XBackend
metadata:
  name: ai-provider-api
  namespace: ai-apps
spec:
  type: ExternalHostname
  externalHostname:
    hostname: api.ai-provider.com

---
# HTTPRoute referencing XBackend
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
spec:
  rules:
  - backendRefs:
    - name: ai-provider-api
      kind: XBackend
      group: gateway.networking.x-k8s.io

Experimental resources move off the standard API group

Previously, experimental resources shared the same API group as standard ones - gateway.networking.k8s.io - distinguished only by a v1alpha2-style version. TCPRoute and UDPRoute were the last resources to graduate under that scheme.

Going forward, new experimental resources are defined in a separate group, gateway.networking.x-k8s.io, and the names of their API types get an X prefix - for example XBackend and XMesh. When one of these graduates to Standard, it's renamed into the gateway.networking.k8s.io group and drops the X prefix, the same way XMesh is expected to become Mesh.

This separation makes the experimental/standard boundary explicit at the API group level, rather than relying on version strings alone.

What's next & getting involved

The graduation of TCPRoute and UDPRoute to Standard marks an essential milestone in making Gateway API a complete, universal ingress and mesh networking API for Kubernetes workloads across layer 4 and layer 7 protocols.

Try it out

You can start using Gateway API v1.6.0 today with your favorite Gateway controller implementation.

Get involved

Gateway API is an open, community-driven project built under Kubernetes SIG Network. We welcome contributions, feedback, and participation from everyone!

Acknowledgments

A huge thank you to all the contributors, reviewers, maintainers, and implementation authors whose hard work made Gateway API v1.6.0 possible!

AI is changing how people interact with computers, and voice is becoming an increasingly important part of that shift. Real-time assistants, AI-powered dictation, and other voice interfaces need low-latency communication between clients, models, and supporting services. Many developers use gRPC, a Remote Procedure Call (RPC) framework built on HTTP/2 and TCP, for this infrastructure.

Ever since Workers launched in 2017, we’ve been expanding their capabilities, including adding the ability to open outbound TCP connections and a JavaScript-native RPC system built on Cap’n Proto. And so as part of Agents Week, we’re extending Workers in the other direction, supporting inbound TCP connections and adding new ways to run gRPC applications on Cloudflare.

Today, we’re announcing:

• connect(socket) — a new handler in the Workers runtime that lets your Worker directly accept an inbound TCP socket provided by Spectrum (Cloudflare’s ingress proxy for non-HTTP traffic)
• Full-duplex, bi-directional gRPC from Cloudflare Containers — forward the socket from your Worker to your gRPC server running in a container
• Workers can serve unary and server-streaming gRPC APIs and call gRPC servers — you write your code using gRPC-web, and Cloudflare automatically converts incoming and outgoing requests to gRPC

We’re introducing this in private beta — you can sign up here.

Let’s dig into each of these below.

connect(socket) from your Worker to Durable Objects and Containers

The Workers runtime now provides a connect() handler that accepts a socket that you can read from and write to:

export default {
	async connect(socket): Promise<void> {
		const writer = socket.writable.getWriter();
		await writer.write(new TextEncoder().encode("Hello, world!\n"));
		await writer.close();
	},
} satisfies ExportedHandler;

You can pass this socket from one Worker to another Worker, or from a Worker to a Durable Object. This lets your Worker control where an incoming TCP connection is routed:

import { DurableObject } from "cloudflare:workers";

export class SocketDurableObject extends DurableObject<Env> {
	async connect(socket: Socket): Promise<void> {
		// Echo bytes from inside the Durable Object
		await socket.readable.pipeTo(socket.writable);
	}
}

export default {
	async connect(socket, env): Promise<void> {
		const stub = env.SOCKET_DO.getByName("my-server");
		const durableObjectSocket = stub.connect("host:port");

		await Promise.all([
			socket.readable.pipeTo(durableObjectSocket.writable),
			durableObjectSocket.readable.pipeTo(socket.writable),
		]);
	},
} satisfies ExportedHandler<Env>;

You can pass a socket from a Durable Object to its Container:

import { DurableObject } from "cloudflare:workers";

export class SocketContainer extends DurableObject<Env> {
	constructor(ctx: DurableObjectState, env: Env) {
		super(ctx, env);
		this.ctx.container!.start();
	}

	async connect(socket: Socket): Promise<void> {
		const containerSocket = this.ctx.container!
			.getTcpPort(8080)
			.connect("10.0.0.1:8080");

		await containerSocket.opened;

		await Promise.all([
			socket.readable.pipeTo(containerSocket.writable),
			containerSocket.readable.pipeTo(socket.writable),
		]);
	}
}

And then handle the socket in the container:

# server.py
import socketserver

class Handler(socketserver.BaseRequestHandler):
    def handle(self):
        while data := self.request.recv(64 * 1024):
            self.request.sendall(b"Echo: " + data)

class Server(socketserver.ThreadingTCPServer):
    allow_reuse_address = True
    daemon_threads = True

with Server(("0.0.0.0", 8080), Handler) as server:
    server.serve_forever()

This gives you full control over the entire path from client to your server running in a container on Cloudflare, opening the door to full-duplex communication between client and server running any program, in any language, for any TCP-based protocol.

To expose the raw TCP socket to the client, we’re introducing a new type of Spectrum application, where you specify a Worker that you want incoming TCP connections to be routed to. Spectrum is Cloudflare’s ingress proxy for non-HTTP traffic, and allows Cloudflare to sit in front of any TCP or UDP application.

Bidirectional gRPC from Cloudflare Containers

gRPC is a well-established and popular Remote Procedure Call (RPC) framework that was initially released by Google almost 10 years ago, and is now used across mobile apps, distributed systems, and most recently — voice AI applications.

Real-time voice AI applications demand low-latency, and both client and server to be able to send messages to each other over a single, persistent connection. WebSockets and Durable Objects are excellent fits for this, and the Cloudflare Agents SDK provides @cloudflare/voice to make this easy. But there is a ton of software out there that uses gRPC for real-time client-server communication.

Using the APIs described above, you can now deploy gRPC servers to Cloudflare, written in any language, with full support for bidirectional streaming between client and server. This lets you take advantage of Cloudflare’s network of 330+ locations and handle requests much closer to clients than is possible elsewhere. We’re excited about the doors this opens up for low-latency voice and colocated inference.

For example, here’s a minimal gRPC server that echoes messages it receives back to the client:

package main

import (
	"io"
	"log"
	"net"

	pb "example/proto"
	"google.golang.org/grpc"
)

type server struct {
	pb.UnimplementedByteStreamServer
}

func (server) Chat(stream pb.ByteStream_ChatServer) error {
	if err := stream.Send(&pb.ByteChunk{
		Payload: []byte("connected\n"),
	}); err != nil {
		return err
	}

	for {
		message, err := stream.Recv()

		if err == io.EOF {
			return stream.Send(&pb.ByteChunk{
				Payload: []byte("goodbye\n"),
			})
		}
		if err != nil {
			return err
		}

		if err := stream.Send(&pb.ByteChunk{
			Payload: append([]byte("echo: "), message.Payload...),
		}); err != nil {
			return err
		}
	}
}

func main() {
	listener, err := net.Listen("tcp", ":50051")
	if err != nil {
		log.Fatal(err)
	}

	grpcServer := grpc.NewServer()
	pb.RegisterByteStreamServer(grpcServer, &server{})

	log.Println("gRPC server listening on :50051")
	log.Fatal(grpcServer.Serve(listener))
}

With this, there’s pretty much no gRPC-based application that you can’t deploy to Cloudflare, no matter what language it’s in or dependencies it relies on. But what if you need to do something simpler, and just serve a basic gRPC server or connect from a Worker to a gRPC server running somewhere else?

Workers as gRPC servers and clients with gRPC to gRPC-web conversion — no container needed

gRPC-web is a browser-compatible version of gRPC. Web browsers don’t expose the lower-level HTTP/2 features that gRPC requires, and there is no raw TCP Socket API built into web browsers — this is why the WebSocket API exists, and why Workers have supported WebSockets since 2021.

HTTP/2 splits each request and response into small binary messages called frames. This is core to how a single HTTP/2 or HTTP/3 connection is able to multiplex — many requests can be interleaved over one connection. Each frame has a stream ID, allowing the receiver to reassemble it into the correct request or response. gRPC depends on this stream-level control for efficient streaming, cancellation, flow control, and trailers.

Web platform APIs like fetch() don’t provide this control. So how can we make it simple and easy to use gRPC from Cloudflare Workers — without clients needing to make any changes? We translate incoming gRPC to gRPC-web, and translate outgoing gRPC-web to gRPC.

We’ve actually used gRPC-web within Cloudflare’s reverse proxy since 2020, when we wrote about the Road to gRPC on the Cloudflare blog. We convert requests to HTTP/1.1 so that messages can be inspected and gRPC apps can benefit from Cloudflare’s security features, like WAF rules and Bot Management.

Now, in private beta and then rolling out to everyone, we’re extending this so that given a Protocol Buffer (protobuf) definition file like this:

syntax = "proto3";

package hello;

service Greeter {
  rpc SayHello (HelloRequest) returns (HelloReply);
}

message HelloRequest {
  string name = 1;
}

message HelloReply {
  string message = 1;
}

You can write a unary gRPC server in a Worker in just a few lines of code, using the @connectrpc/connect open-source package:

import { createConnectRouter } from "@connectrpc/connect";
import {
  universalServerRequestFromFetch,
  universalServerResponseToFetch,
} from "@connectrpc/connect/protocol";
import { Greeter } from "./gen/hello_pb";

const router = createConnectRouter();

router.service(Greeter, {
  sayHello: ({ name }) => ({ message: `Hello, ${name}!` }),
});

const handlers = new Map(
  router.handlers.map((handler) => [handler.requestPath, handler]),
);

export default {
  async fetch(request: Request): Promise<Response> {
    const handler = handlers.get(new URL(request.url).pathname);
    return universalServerResponseToFetch(
      await handler(universalServerRequestFromFetch(request, {})),
    );
  },
} satisfies ExportedHandler;

You can make outbound requests to external gRPC servers this way too, by using the client built into @connectrpc/connect:

import { createClient } from "@connectrpc/connect";
import { createGrpcWebTransport } from "@connectrpc/connect-web";
import { Greeter } from "./gen/hello_pb";

const client = createClient(
  Greeter,
  createGrpcWebTransport({
    baseUrl: "https://grpc.example.com",
    fetch: (input, init) =>
      fetch(input, { ...init, redirect: "manual" }),
  }),
);

export default {
  async fetch(): Promise<Response> {
    const reply = await client.sayHello({ name: "Workers" });
    return Response.json(reply);
  },
} satisfies ExportedHandler;

Your code uses gRPC-web, but when it speaks to the outside world, it is automatically translated into gRPC. This means that clients and servers that you already depend on don’t need to change. For example, you can:

• Provide gRPC backends to mobile apps that speak gRPC — Many mobile apps already use gRPC to reduce network payloads, serialize data more efficiently, and generate strongly-typed client libraries. You can now build the backend server for mobile apps on Workers, while still using established gRPC native libraries like grpc-swift-2 and grpc-kotlin.
• Put a Worker in front of an existing gRPC backend — So many developers already put Workers in front of existing REST APIs to move performance critical work closer to the user, or to incrementally move state into Durable Objects. Now you can do this with existing gRPC backends as well, or build new APIs and services that fetch data from your existing gRPC backend.

What’s next for Socket Workers and gRPC on Cloudflare

We’re introducing everything from this post in private beta — you can sign up here.

At Cloudflare, we use Cap’n Proto and Cap’n Web and the JavaScript-native RPC system that is built into Cloudflare Workers instead of gRPC. And when we ship things, we always aim to be using them ourselves. So in this case, we want to first work closely with a smaller set of developers using gRPC, and make sure we’ve nailed it before turning this on for everyone.

More broadly, we’re excited to continue to push the bounds of what types of traffic the Workers platform can serve, going beyond TCP and into UDP-based protocols. Keep telling us what you want to build on Workers, and we’ll keep pushing the bounds of what is possible.

ADR: Agentic AI Detection and Response

ADR (Agentic AI Detection and Response) is an enterprise security system for AI agents. It helps organizations secure employee-facing agents such as Cursor, Claude Code, and Codex, as well as customer-facing agents such as AI support agents.

ADR is deployed in production at Uber, and the accompanying paper was accepted to MLSys 2026.

How ADR secures enterprise AI agents

ADR secures enterprise AI agents through four complementary capabilities: observing agent activity, evaluating defenses, detecting threats, and preventing unsafe actions.

1. ADR Observability: Understand what AI agents are doing and why. In production, ADR captures agent intent, tool use, and execution traces across 7+ AI coding tools on macOS, Linux, and Windows, as well as internal automation and customer-facing support agents.
2. ADR Benchmark: Test agent security under realistic enterprise conditions. ADR-Bench includes 300+ tasks, 133 MCP servers, and coverage of all 17 agent attack techniques.
3. ADR Detection: Detect risky agent behavior efficiently. Its two-tier architecture combines high-recall triage with deeper agentic reasoning for suspicious sessions.
4. ADR Prevention: Stop unsafe actions before they cause harm. This component is not included in the current open-source release. Stay tuned.

Repository layout

This repository contains the open-source ADR Sensor, ADR-Bench, and ADR Detector described in the paper. The offline ADR Explorer engine, which hardens ADR Detection through pre-deployment red teaming, is not included here.

Quick start: ADR Detection

git clone https://github.com/uber/ADR
cd ADR/Detection
uv sync
export ANTHROPIC_API_KEY="..." OPENAI_API_KEY="..."

Default detector is adr (ADR dual-agent). For keyless smoke tests, use --detector llamafirewall.

See docs/REPRODUCIBILITY.md for the full evaluation workflow (inflate packed benchmark → run detectors → plot figures).

Component documentation:

• Sensor/README.md: telemetry collection and unified schema
• Detection/README.md: ADR-Bench, detector baselines, MCP infrastructure

Citation

@inproceedings{li2026adr,
  title={ADR: An Agentic Detection System for Enterprise Agentic AI Security},
  author={Li, Chenning and Hu, Pan and Xu, Justin and Ozbas, Baris and Liu, Olivia and Van, Caroline and Li, Manxue and Zhou, Wei and Alizadeh, Mohammad and Zhang, Pengyu and Sriramadhesikan, KK and Zhang, Ming},
  booktitle={Proceedings of the Ninth Conference on Machine Learning and Systems},
  year={2026}
}

License

Apache License 2.0. See LICENSE. Detection/benchmark/agentdojo/ is vendored third-party code under its own LICENSE (MIT).

Data notice

Detection/ includes synthetic benchmark fixtures (fake credentials, emulated environments, prompt-injection scenarios) for defensive security research only. Details: docs/OPEN_SOURCE_REVIEW.md.

Google pauses AI satellite images, after fears of deepfakes in the sky

A day after Google unveiled a new feature that allowed users to create AI-generated satellite images with the click of a button on its Google Earth platform, the company announced it was removing the tool.

"We've seen geospatial professionals using this feature for a range of useful purposes," Google said in a statement on X. "However we've also seen people sharing screenshots of generated imagery that appear to violate our policies. So we're rolling back this feature in Google Earth while we work on implementing stronger guardrails."

In its initial announcement of the new feature on Thursday, the company said it was designed to work with users' imaginations: "Just zoom in to a place in Google Earth on web (sic), tap 'create image,' and type whatever you want to see," Bryan Horowitz, a product manager wrote.

But for experts and analysts who rely on Google's imagery to verify breaking news and atrocities in hard-to-reach parts of the world, the potential to create deepfake satellite imagery at the click of a button was horrifying.

"I tried refugees at the Mexican border, a nuclear plant in Iran, a crash in Amsterdam, a hospital with a bomb crater in Gaza. Nothing was refused," Henk van Ess, an open-source researcher who first wrote about the potential damage the tool could cause, told NPR via text.

NPR was able to easily generate images of Iran's Kharg Island on fire, and a flooded U.S. Capitol complex. Both events, which have not happened, would constitute major news if they were real.

Online, journalists and open-source investigators wondered aloud about Google's decision. "Very curious how or if this idea was red teamed internally because the opportunities for abuse and disinfo are literally boundless," Evan Hill, an visual forensics investigator at the Washington Post wrote on X.

So it seems Google activated its AI image generation program inside its satellite image app today. Very curious how or if this idea was red teamed internally because the opportunities for abuse and disinfo are literally boundless.

Eyes in the sky

As the online world fills with AI-generated deepfakes and slop, satellite imagery has been a key tool for understanding what's real and what's not. Open-source investigators have used satellite images to verify events on the ground, and as reference for understanding videos and images shared online.

Google Earth imagery is not always the most up-to-date, but its sweeping, high-resolution coverage of the planet can provide important reference imagery for both images from the ground and more current images from other satellites.

"Satellite imagery has been kind of a safe bet when it comes to verifying an event because it's hard to fake," says Jake Godin, a senior researcher with the online group Bellingcat, which does visual forensic investigations. Satellite images are usually controlled by companies or institutions, and their source, a camera hundreds of miles above the earth's surface, has historically been hard to imitate.

Fakes from space

Godin noted fake satellite imagery has already cropped up in limited cases. Early on in the U.S.-Israel war with Iran, for example, fake images circulated of a damaged U.S. base in Bahrain. The images, which popped up in Iranian media, appeared to use Google Earth images and Google AI to generate fake damage at the base. (Real satellite images later showed that the base was, in fact, damaged, just not in the way shown in the fake image.)

But putting the tools together to create AI-generated satellite images with a single click has the potential to vastly accelerate the generation of AI fakes, Godin said. "It's just streamlining the process, which I think is going to make it proliferate more."

Godin worries that the spread of fake images will add to confusion and misinformation. "Misinformation travels further and faster than any sort of correction," he said. Moreover, governments will now be more likely to claim satellite images are fake, even if they are real, undermining public trust.

In an posting on X on Thursday, the company said it "takes misinformation seriously." The company noted that all images are marked with its SynthID watermark, which ensures it will be flagged as AI-generated in other Google tools such as Gemini. "In addition, we prevent image creation on harmful topics and are continually updating our protections," it said.

But few in the open source community seemed reassured by Google's statements. For van Ess, the decision particularly stings because Google Earth has long been regarded as one of the best tools to verify information posted on social media.

If Google continues to develop the AI tool, he said, it would mean that "the fake is made inside the thing people use to check whether pictures are true."

Today, it is difficult for AI agents to try out new APIs. They often have to navigate through a login page designed for humans and not agents, contact a human to add a payment method, generate an API key, and then figure out how to call the API.

This flow is very difficult for agents for two reasons: Agents do not have a stable identifier to sign up for an API, and they do not have a native way to pay for APIs. Because they lack these things, they often struggle to onboard onto software, which limits the growth of agentic commerce. AI agents often give up on these tasks entirely, kicking registration, payment methods, and API key generation back to humans. This makes it very difficult for agents to try out and compare many APIs.

To solve this, we’ve created Cloudflare Wallets. Starting today, you can claim a Cloudflare Wallet handle for your account, which will provide a unique username to help you better connect with merchants. Soon, you will be able to set up and use your Cloudflare Wallet to pay for APIs and content.

Earlier this month, we announced the Monetization Gateway to help Cloudflare customers get paid for their websites and applications. Monetization Gateway will support micropayments using the x402 protocol, which allows for payments to be attached to HTTP requests. These micropayments will be able to pay for uses ranging from AI inference to data to content. If you want to pay or get paid for services behind Monetization Gateway and other x402-compatible endpoints, you’ll need a wallet.

Cloudflare Wallets will allow you to store stablecoins, purchase services, and receive funds across the web. Each account with a wallet will also be able to create Virtual Wallets for its agents to enable them to buy APIs, MCP Tools, content, and more. You will be able to define guardrails for your Virtual Wallets (such as an allowance, an allow list, and a maximum transaction size) to help your agent spend money safely from your account. This will allow your agent to try out many APIs with low friction and managed risk. Wallet users will have the option to share their Cloudflare Wallet handles, which will give them a stable identity when interacting with merchants.

Building the two-sided agentic market

Cloudflare’s Monetization Gateway will allow eligible Cloudflare customers to sell their resources (such as content or APIs) headlessly to agentic buyers. But for that market to truly develop, agents need more tools to buy from merchants in a machine-native way. Wallets will add another tool to Cloudflare’s Agents SDK, enabling AI agents to easily purchase necessary APIs and content using micropayments.

There will be two types of Cloudflare Wallets: Account Wallets and Virtual Wallets.

Account Wallets are designed for humans who are owners and users of Cloudflare accounts. They will be able to add funds, delegate spend to virtual wallets managed by agents, and remove funds as needed.

Virtual Wallets, by contrast, are designed for agents and operate via API keys. Within a Virtual Wallet, an agent will be able to spend funds according to its permissions. Its maximum spend will be capped by the limit set by the owner of the Account Wallet. This framework gives agents freedom to act on behalf of users without constant manual approval while limiting an agent’s ability to overspend.

The freedom to explore

Virtual Wallets are exciting because they will allow agents to do what they’re best at: explore dozens or hundreds of services and find the best one for a particular use case. Stablecoin micropayments via x402 will make it simple to try an API without an account, allowing agents to test new options with little friction. The spending caps on Virtual Wallets are designed so that humans can let agents explore autonomously within safe spending limits. These limits may seem like constraints, but counterintuitively they give agents more freedom. If an agent is responsible for $10, you can worry less about its spending than if it is responsible for $1,000. If an API only costs a few cents to try, then $10 is more than sufficient to pursue and evaluate many options.

Once you or your agent has picked an API to use, policies set by you in your Account Wallet will act as cost controls for Virtual Wallets. Want to give every employee a $100 per week budget for AI inference? Simply provision an Account Wallet with the right balance and create Virtual Wallets for each employee with that rule. Anyone who exceeds the limits on their Virtual Wallet will be able to request a manual override from a human who is authorized to make changes to the Account Wallet.

We want to make it easy for Account Wallets to set flexible yet firm spending policies that do not require daily, active monitoring. When something anomalous happens, such as unexpectedly fast spending, a human will be able to review and confirm whether everything is operating as intended. If the spend was intentional, then the administrator of the Account Wallet will be able to raise the limit or approve a one-time injection of funds. If the spend was unintentional, then the spending policies for adding funds to virtual wallets did their job by imposing caps.

We are working to make it as easy as possible to fund and use these wallets. We will start with simple ways to onramp and offramp funds within supported geographies, with self-funding via stablecoins available as an alternative for eligible users. The Internet will not shift completely overnight, but with a majority of traffic on the web now being driven by bots, we are excited to give agents and merchants first-class tools for agentic commerce.

Beyond payments alone

Allowing humans to delegate authority to agents to easily buy and sell services is a helpful starting point. But this delegation is not always obvious to the merchants as they interact with agents. Today, if an agent comes to your website, you may know little about them as a user, despite the fact that the agent is acting on behalf of an individual or an organization. This lack of attribution challenges many traditional web business models. It’s easy to give a one-week free trial or sign-up credits to a human or an organization. It’s hard to give these same perks to an agent that lacks a stable identity and when one human can spin up dozens of agents under their control.

We solve this problem by linking wallets to a Cloudflare account via cloudflare.pay. cloudflare.pay will allow agents to optionally identify themselves, since their identity is a delegate of the account. A research agent could live at research.example.cloudflare.pay, allowing merchants to know that it is an agent from a particular organization. This approach will permit agents to maintain consistent and persistent identities, making the experience better for all parties. It will be completely optional for agents to choose to declare their identity or not, and it will be up to businesses to decide whether they want to prioritize transacting with known agents.

Agent identifiers should be human-readable

We believe that the approach to dealing with agents will look like the approach to dealing with VPNs: If someone is unidentified, they are not inherently untrustworthy, but they need to prove themselves more. This is why we have Turnstile and other initiatives to detect bots within Bot Management. Our identity primitive will build on top of this prior work. For example, Web Bot Auth already allows agents to register their identity via a keypair. IDs attached to Cloudflare Wallets allow this keypair to become human-readable.

We know that agentic identity standards are changing quickly, which is why we wanted to keep our approach simple. We are proposing a human-readable identifier for a not-very-readable keypair, similar to the URL and IP-address pairings used in DNS. We are not trying to define a particular schema or other verification system. We only want to make identity simple to remember and easy to declare. As schemas to enrich agentic identity develop through the x402 Foundation’s initiatives, we will seek to adopt them and intend to encourage others to do the same.

The future of agentic commerce

At Cloudflare, we want to offer all the building blocks for agentic commerce to succeed. Monetization Gateway will offer a way for sellers to get paid without setting up traditional payment infrastructure. Wallets will offer a way for buyers to pay headlessly via agents. Identity will allow merchants to communicate with buyers who identify themselves or enforce identification requirements.

All of these building blocks will create a headless marketplace for the Internet. If you are excited about this and want to participate, you can claim your handle now. We’re excited to see what you build and monetize.

A unified API for AI model routing

When building AI applications, developers need the freedom to route traffic to the best model for the job without hardcoding endpoints or managing open-source proxies. Google Cloud API Gateway now offers model routing in Public Preview to solve this. It provides a lightweight, serverless ingress layer that accepts OpenAI-compatible requests and dynamically routes them to Gemini, Claude, or OpenAI OSS-GPT.

API Gateway can be used standalone for simple rate limiting and token tracking, or paired seamlessly with the Gemini Enterprise Agent Platform. For example, you can route your agent's egress through Agent Gateway for strict security governance, and then pass the request to API Gateway to handle dynamic routing to Google-hosted LLMs. Here is a step-by-step guide on how to configure your routing logic.

Routing your traffic

Setting up your model routing logic takes just a few steps:

1. Configure your routing rules: You can map virtual model names to specific backend targets directly in your OpenAPI 3.x specification using the new x-google-api-management extension block.

openapi: 3.0.4

info:
  title: OpenAPI 3.x spec using Model Routing
  description: Using Model Routing in an OAS 3.x spec
  version: 1.0.0

x-google-api-management:
  backends:
    gemini-35-flashlite:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/google/models/gemini-3.5-flash-lite:generateContent
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

    anthropic-claude-opus-47:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/publishers/anthropic/models/claude-opus-4-7:rawPredict
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

    openai-gpt-oss-120b:
      address: >-
        https://aiplatform.googleapis.com/v1/projects/YOUR_PROJECT_ID/locations/global/endpoints/openapi/chat/completions
      deadline: 60.0
      pathTranslation: CONSTANT_ADDRESS

  ai:
    models:
      routing:
        routers:
          # Router 1: route between Gemini (default) and Claude.
          gemini-claude-router:
            defaultModel:
              backend: gemini-35-flashlite
              targetModel: google/gemini-3.5-flash-lite
            rules:
              - model: "claude-opus-4-7"
                backend: anthropic-claude-opus-47
                targetModel: anthropic/claude-opus-4-7

          # Router 2: route between OpenAI GPT (default) and Gemini.
          openai-gemini-router:
            defaultModel:
              backend: openai-gpt-oss-120b
              targetModel: openai/gpt-oss-120b-maas
            rules:
              - model: "gemini-3.5-flash-lite"
                backend: gemini-35-flashlite
                targetModel: google/gemini-3.5-flash-lite

servers:
  - url: "https://my-gateway-url.com"

paths:
  /v1/chat/gemini-claude:
    post:
      summary: "Endpoint:defaults to Gemini & Claude as an option."
      operationId: "chatGeminiClaude"
      x-google-model-router: gemini-claude-router
      responses:
        '200':
          description: "OK"

  /v1/chat/openai-gemini:
    post:
      summary: "Endpoint:defaults to OpenAI & Gemini as an option."
      operationId: "chatOpenAIGemini"
      x-google-model-router: openai-gemini-router
      responses:
        '200':
          description: "OK"

Note: All backends referenced by a single router must share the same host (for example, aiplatform.googleapis.com). Routing selects a different model and path on that shared Vertex host — it does not route across different hosts.

2. Deploy the Gateway: Deploy your updated API config so the Gateway is active and ready to process traffic.

3. Send standard requests: Your application simply sends a standard OpenAI POST /v1/chat/gemini-claude or POST /v1/chat/openai-gemini request. The Gateway intercepts it, transcodes the payload to the native schema of the backend, and routes it on the fly. As an example (use appropriate values for $API_KEY and my-gateway-url.com) :

curl -X POST "https://my-gateway-url.com/v1/chat/gemini-claude" \
  -H "content-type: application/json" \
  -H "x-api-key: $API_KEY" \
  -d '{
        "model": "claude-opus-4-7",
        "messages": [
          {"role": "user", "content": "Introduce yourself in 5 words"}
        ]
      }'

Get started

Model routing is now available in Public Preview for API Gateway. To stop managing proxies and start unifying your AI traffic, check out our documentation to deploy your first model router today.

What Codex Actually Sends to the Model

I recorded the requests Codex generated for a 16-character prompt, then measured what changed as it loaded instructions, exposed tools, read files, ran commands, received images, and compacted its history.

When I typed Reply with pong., the prompt was 16 characters long.

The request Codex sent was 42,980 bytes.

Encoded locally as JSON with o200k_base, it came to roughly 9,435 tokens. The wrapped prompt accounted for about 25 of them, or 0.3%. The rest came from Codex itself: instructions, tool definitions, permissions, skill metadata, environment context, and request framing.

Those token counts are local estimates, not API usage or billing. The captured request body itself is exact.

File reads and command output are added later. When the accumulated history gets too large, Codex can send it through another model request, replace it with a summary, and continue.

How I recorded the requests

Codex supports custom model providers. I pointed it at a local HTTP server that saved each request, redacted sensitive headers, and returned a fixed fake response. The experiment did not call an external model.

Codex client → local recorder → deterministic fake response
                       ↑
                 request saved here

The recorder shows what the client sent. It cannot show what a real provider might change after receiving the request, whether any input would be cached, or how it would be billed.

I measured two things:

• Raw request bytes: the size of the HTTP JSON body before sanitization.
• Approximate text tokens: the sanitized JSON encoded locally with o200k_base.

The tests used Codex CLI 0.145.0 with the gpt-5.6-sol model.

The first request

I started Codex in an empty temporary Git repository, disabled project instructions, and pointed CODEX_HOME at an empty directory.

The request still described five bundled system skills, so this was an isolated-home baseline rather than a minimum possible request.

Three items accounted for 7,696 of the 9,435 tokens:

The four tool entries were exec, wait, request_user_input, and a collaboration namespace. They represented more than four actions. collaboration contained six subtools, while exec described command execution, patching, image inspection, plan updates, and other nested tools.

In this run, Codex placed the tool entries and base instructions inside the input array instead of using top-level instructions and tools fields.

Project instructions

Codex builds its project instruction chain from the repository root to the directory where it starts. It looks for AGENTS.md at each level, placing the closer instructions later.

I created one root and one child AGENTS.md, each with 100 unique markers.

• Starting at the repository root sent all 100 root markers and no child markers.
• Starting in the child directory sent all 200 markers.
• Starting at the root and later running ls child did not add the child instructions.

The launch directory determined the automatic instruction chain. Reading the child file explicitly could still add its contents as ordinary tool history.

For the size test I used synthetic high-entropy markers rather than natural prose. Each marker is a string like PAIRED_AGENTS_1000_0001, which o200k_base splits into 11 tokens on its own. Ordinary prose words do not. The table below shows that instructions are transmitted in full — it is not what your own AGENTS.md would cost.

Larger files changed the first request directly:

In a two-request trace with 250 markers, all 250 appeared in both requests.

Skills loaded in two stages

Repository skills under .agents/skills/ initially contributed their name, description, and path. Their SKILL.md bodies were absent until read.

Each synthetic skill had a 12-word description and a 200-word body with unique markers.

• One skill added 481 bytes and approximately 125 tokens to the first request.
• Ten skills added 4,810 bytes and approximately 1,250 tokens.
• None of the body markers appeared in either first request.

MCP tool descriptions were deferred

I tested one local MCP server with three tools and two local servers with seven tools in total.

In the initial-only runs, both requests were 46,582 bytes and approximately 10,410 local tokens. Neither contained the custom tool names or descriptions. Instead, the exec interface gained generic MCP discovery guidance. Disabling the configured server returned the request to the isolated-home baseline.

The descriptions appeared after I made exec print the matching deferred tool entries:

These deltas compare the request after discovery with the first request in the same trace, which was 46,589 bytes and 10,410 local tokens in a separate run.

I also created one tool description containing 5,000 markers. After truncation, its retained head-and-tail sample still contained 1,046 markers. The next request grew by 40,607 bytes and approximately 9,631 local tokens.

A coding task, request by request

I created a small Python fixture with a configuration bug: an explicit false value was being replaced by a user default. The task was:

Fix the configuration precedence bug causing explicit false values to be replaced by user defaults. Add a regression test and run the relevant test suite.

This trace measures request growth, not model reasoning. The actions were fixed in advance.

The final request was 8,200 bytes and approximately 2,074 tokens larger than the first. Search results, file contents, tests, the failure, the patch, and the final diff all remained available to later turns.

Files entered after they were read

I created five harmless files with unique markers: a normal source file, an ignored file, a fake .env, an ignored 20,000-line log, and a file named inside AGENTS.md.

None of their contents appeared in the first request.

Running rg –files -uu added their filenames, not their contents. After explicit reads, the normal file, ignored file, fake .env, and ignored log all appeared in later requests.

The large log was truncated to a head-and-tail sample before the next request.

Codex did not upload the repository automatically. But .gitignore did not block explicit reads or stop the resulting tool output from entering later requests.

Terminal output stayed in the history

Ten- and one-hundred-line command results survived verbatim into the next requests. A 10,000-line result was truncated to a head-and-tail sample, but the request still grew from 43,337 bytes and approximately 9,584 tokens to 88,480 bytes and 25,835 tokens.

Repeated output was not deduplicated. ANSI-formatted text and a failing Python stack trace also stayed in the history.

Images crossed as data URLs

A synthetic 32×32 PNG appeared in the request as a 442-character data:image/png;base64,… URL.

I then attached a larger synthetic gradient PNG. Codex resized and re-encoded it before transmission. The captured 71,666-character data URL decoded to a 1600×1600 PNG. A two-image request contained both data URLs.

The raw request bodies were 43,955 bytes for the small image, 115,265 bytes for the transformed large image, and 115,886 bytes for both. Local text tokenization of base64 is not image-token accounting, so I did not use it to estimate cost.

Compaction sent the history through another request

Against OpenAI or Azure, Codex compacts through a dedicated endpoint. Against a custom provider like my recorder, it builds the summary request itself. That is the path I captured, and it had two stages. First, Codex sent the accumulated history with a summary prompt. It then rebuilt the conversation around retained user messages and the returned summary.

I forced the trigger with synthetic usage: 13,000 reported input tokens, a 20,000-token context window, and a 12,000-token compaction threshold.

That produced three requests:

• Initial request: 42,030 bytes and approximately 9,378 tokens. It contained the normal tools and user request.
• Compaction request: 68,375 bytes and approximately 21,408 tokens. It contained the accumulated history, a large retained tool result, and a summary prompt. The normal tool list was empty.
• Resumed request: 42,646 bytes and approximately 9,500 tokens. The normal tools and original user message returned. The raw tool call and output were replaced by the synthetic summary.

The resumed request was 25,729 bytes and approximately 11,908 tokens smaller than the compaction request. The summary was intentionally short.

This shows how the history was replaced, not how well a real model would summarize it. After compaction, a detail may survive only through the generated summary rather than the original message or tool output.

What crossed the machine boundary

Some information was present before any tool use: Codex instructions, visible tool interfaces, the discovered AGENTS.md chain, skill metadata, environment context, and the user prompt.

Other information appeared only after an action: file contents after a read, terminal output after a command, MCP descriptions after discovery, and images after attachment.

Unread repository files, ignored files, and the fake .env did not appear automatically. The prompt was the seed. The request was the working state.

What this experiment did not measure

• A universal minimum request across every Codex version, model, operating system, or product surface.
• Autonomous model reasoning. The multi-turn workflows used fixed fake responses, so real sessions carry more per turn than these traces show.
• The quality of model-generated compaction summaries.
• Provider-side transformations, cache hits, billing, or model internals.

The companion artifact pack contains the recorder, sanitized request bodies, analysis files, tests, and figure sources.

Unpacking ChatGPT Work: the Agent for a Billion Users

An external reconstruction of how Memory, Proactivity, Scheduling, Browser Use, Plugins, Skills and Tools work in the new ChatGPT Work.

On July 9th, OpenAI released ChatGPT Work, their agent product for knowledge work. It was, by any measure, a busy launch: three new models across fourteen configurations, a consolidation of the ChatGPT and Codex desktop apps, and cloud agents brought to the mainstream in their most accessible form yet.

Three weeks in, Work (along with Codex) has reportedly crossed 10 million users.

Chat and Work currently sit side by side as separate modes inside ChatGPT, but Greg Brockman has confirmed that they will merge by the end of the year. Work, then, is not just a niche product for power users, but a preview of how ChatGPT’s billion weekly users will soon use the app.

Work in its current form takes some decoding. It’s an amalgamation of ChatGPT (in chat form), Codex the app, Codex the harness, Codex the original cloud agent, ChatGPT agent, Atlas, OpenClaw, and more. The product lineup around it is confusing. And the web and mobile versions diverge from the desktop one (unless you run it in cloud mode?!).

What is Work?

At its core:

• An agent for knowledge work. You connect it to the places you already work—Slack, email, Drive, calendars, CRMs, project trackers, and hundreds of other plugins—and it gathers context across all of them to produce finished work.
• Runs on the Codex harness. So it inherits the same models, sub-agents, browser use, and the ability to grind on a task for hours. Its UI is stripped of the evidence (git controls, diff-traces) that would give away you’re talking to a coding agent.
• Lives in a cloud computer. Specifically, a beefy, isolated microVM: Pro accounts get 8 CPUs, 20GB of RAM, and a 64GB disk; Plus gets 14GB of RAM. Alongside the VM, Work gets a managed Chrome service that the agent operates through tool calls.
• Produces artifacts. Sheets, docs, and slides rendered in interactive viewers, plus Sites: hosted web apps and dashboards it can build, share via URL, and keep updated.

Every new conversation in Work is called a task. On web and mobile, Work runs in the cloud. You can kick off a task on web, track progress and give directions in the ChatGPT app on your phone, then view the result (maybe a report or a spreadsheet) back on your laptop.

Work on the desktop app is slightly different and comes in two modes: cloud and local. In cloud mode, tasks run on the same cloud computer as web and mobile and sync across all three.

In local mode, the agent works directly on your machine, across your files and apps, with full computer use. These tasks don’t appear on web or mobile, and there’s no way yet to move a local task to the cloud. This makes local mode essentially Codex, minus the code-related UI traces that would scare off a non-developer.

Persistence & Memory

Work’s cloud computer is persistent too. But rather than running in one VM that stays on forever, its workspace is synchronised to persistent storage and restored onto isolated microVMs as needed. So the underlying machine can change, but the working state carries over.

Every Work task (thread) gets a working directory under /workspace/scratch, where the agent has the freedom of a normal computer: it can make folders, install dependencies, write scripts, keep databases, and search everything with ordinary Linux commands.

When I ask it to make a presentation for Acme, it can create clients/acme, copy in the source material, perform some analysis through code, and create charts and slides, all as files in the directory. When I follow up in the same thread, it returns to that working state and can continue editing it.

By default, each new thread receives a compressed summary of recent tasks and files worked on. Raw conversation transcripts are not stored on the computer for the agent to browse. When a task needs context from previous threads, the agent calls Personal Context, a dedicated tool that queries Chat and Work history through a separately managed service and returns the relevant excerpts.

Files follow the same pattern. ChatGPT’s Library is the central user-facing repository for all files and artifacts. User uploads land there automatically; agent-created files are saved when the user asks, or when the agent judges them worth retaining. Like conversations, the Library doesn’t live on the computer, and can only be reached through dedicated tools.

Hints of useful proactivity

Today’s AI products are still reactive. Before the model can help, you have to notice that something needs doing, gather the relevant context, and translate it all into a prompt. Proactivity, where agents figure out how to be useful on their own, is one of the holy grails of personal AI.

Work offers an early glimpse of that. When you open a new Work conversation, alongside the composer, you get personalized tasks generated from your own context. It had reasoned asynchronously across my context: noticed the calendar event, inferred that preparation would help, pulled data from Calendar and Gmail, and framed a task around the interests and preferences in my memory.

Scheduled Tasks

Automations let Work run tasks at a future time or on a recurring schedule, without the user manually prompting it. They are ChatGPT’s abstraction for reminders and cron jobs. Work builds on the same scheduler but makes it agentic: each run can use the agent’s context and tools to complete the task.

A standalone scheduled task begins each run from a saved prompt and opens a fresh task for the result. A scheduled task inside an existing conversation, triggered by a “heartbeat”, reawakens that task with its context intact.

Browser Use

The Work browser doesn’t live on the same computer as the agent. Instead, the agent controls a separately hosted Chrome service through tool calls. It can inspect the page, click, type, scroll, take screenshots, manage tabs and dialogs, and move files between the browser and its computer.

The browser service also keeps its own persistent profile. New browser instances inherit preferences and logged-in sessions. The Work agent never sees this profile or its credentials. Instead, a small permission ledger is synchronised into its computer alongside the workspace, recording, globally and per conversation, which sites it may act on and whether it may move files to or from them.

Plugins, skills, and tools

In March 2026, plugins returned to Codex as packages of apps and skills. With the July 9 launch, the App Directory became the Plugin Directory, existing apps were packaged into plugins, and the directory expanded across Work and Codex.

A plugin today can contain:

• Apps, which connect the agent to services such as Gmail, Slack, or Salesforce.
• Skills, which combine instructions with supporting material—references, templates, and sometimes scripts—to teach the agent a workflow.
• App templates, which let an organisation configure the private or organisation-specific app a workflow depends on.

What’s Next

When Work folds into Chat later this year, its design choices will become the default for a billion people. Before then, OpenAI has to resolve a few tensions that kept surfacing as I used it:

1. Does the cloud computer become the user’s primary AI computer? And how can syncing between it and the local machine feel seamless?
2. Do Work agents get more OpenClaw-like sovereignty over that computer?
3. How does Work come to feel as familiar to users as Chat?

None of this should detract from the fact that Work is an impressive, ambitious, yet underrated launch. It consolidates years of scattered products and experiments into one increasingly cohesive whole.

For robotaxis and other autonomous vehicles (AVs), the hardest problems aren’t the everyday scenarios. They’re the rare, complex situations that are difficult to anticipate and train for.

Handling these long‑tail events takes more than just object detection and motion prediction. AVs must understand the situation, reason about cause and effect, choose the right action and turn that decision into a safe, comfortable path — all in real time and in a way developers can inspect, validate and trust.

NVIDIA Alpamayo 2 Super, available now for commercial use, is part of the Alpamayo family, the most-adopted open reasoning models for autonomous driving on Hugging Face, supporting a wide range of AV-relevant capabilities within a single foundation model.

Built on NVIDIA Cosmos 3 Super Reasoner and post‑trained with reinforcement learning, the model advances the AV ecosystem on two fronts: open commercial licensing and leading multitask capabilities for autonomous driving.

Alpamayo 2 Super is part of NVIDIA’s growing collection of open models, datasets and tools for autonomous driving, expanding access, strengthening competition, giving developers greater control and supporting safer, more transparent AV deployment.

Open Licensing for Production AVs

Alpamayo 2 Super is available on Hugging Face under OpenMDW‑1.1, the Linux Foundation’s permissive license for open AI model distributions. The license covers fine‑tuning, derivative models and commercial redistribution, allowing AV developers, automakers, truckmakers and suppliers to adapt Alpamayo to their own data, driving policies and deployment strategies.

This openness lets AV researchers and companies keep control of their own data and infrastructure, as well as own the value they create through specialized models and accumulated know‑how. Such control is essential for workflows involving proprietary fleets and safety.

Earlier Alpamayo releases were initially introduced for R&D. The OpenMDW license is now being applied across the entire Alpamayo model family so developers can deploy any of the models commercially without requiring additional permissions. This creates a direct path from adaptation to deployment.

Open weights make that path economically viable. Teams can build on advanced reasoning without re‑training every foundation capability from scratch or paying frontier‑model costs for every task, matching the right model to the right job at the right cost.

Alpamayo 2 Super enables frontier-scale reasoning in cloud-based development workflows, where developers can generate high-quality reasoning traces, synthetic training data and teacher outputs for model distillation. Within the Alpamayo model family, Alpamayo 2 Super delivers the highest reasoning and driving performance for multimodal autonomous driving development, while Alpamayo 1.5 and Alpamayo 1 provide more cost-efficient options for cloud-based development and model distillation.

The resulting distilled models can then be optimized for efficient, real-time inference in production vehicles. Together, the Alpamayo model family provides a cloud-to-car workflow that combines frontier-scale reasoning with scalable deployment across commercial AV fleets.

For AV programs, that means frontier‑scale reasoning in the cloud and efficient, specialized models in the vehicle — a more sustainable way to scale safe autonomy into commercial fleets.

Benchmark-Leading Reasoning at Frontier Scale

Alpamayo 2 Super ranks first on LingoQA, an autonomous driving reasoning benchmark, among nearly 40 models evaluated. In NVIDIA testing using the Lingo‑Judge metric, it outperformed Qwen2.5‑VL 72B by 17.0 points, Gemini 2.5 Pro by 15.1 points and GPT‑4o by 23.2 points, demonstrating state‑of‑the‑art reasoning for driving‑centric scenarios. Alpamayo 2 Super also ranks first across all autonomous driving benchmarks evaluated by NVIDIA, underscoring its leading performance across a broad range of AV capabilities.

Alpamayo 2 Super offers 3x the scale of the 10‑billion‑parameter NVIDIA Alpamayo 1.5 and Alpamayo 1 models. The added capacity helps the model better generalize reasoning from sparse examples — a critical capability for the rare, multi‑agent interactions where conventional systems often struggle.

The model reasons over full‑surround camera coverage, fusing views from the vehicle’s front, sides and rear. This 360‑degree context enables richer understanding of lane changes, merges, unprotected turns and complex intersections, where risks commonly arise.

A Multitask Foundation Model for Robotaxis and Autonomous Driving

For each driving situation, Alpamayo 2 Super can produce five tightly coupled outputs:

• A trajectory describing the vehicle’s planned path.
• A chain‑of‑causation (CoC) trace that explains the reasoning behind the decision.
• A meta‑action (e.g., yield, lane changes, stops) that captures the model’s intent.
• Reasoning auto-labels that generate CoC annotations for training and validation data.
• Visual question answering responses with 2D visual grounding that link the model’s answers to specific regions in camera images.

Together, these outputs offer insight into the model’s decision-making process. Developers can tie what the model observed to the action it selected, making decisions easier to understand, critique and validate.

CoC traces integrate with NVIDIA Halos safety‑validation workflows and support AI safety aligned with ISO/PAS 8800 requirements, providing a stronger foundation for AV safety engineering.

Alpamayo 2 Super can also be deployed as an autolabeler to generate CoC labels and perform visual question answering with 2D grounding on proprietary fleet data. By linking its reasoning to specific regions in camera images, the model can transform raw driving clips into richer training data, compressing annotation cycles from months to days.

Beyond planning and auto-labeling, Alpamayo 2 Super supports scene understanding, model critiquing and knowledge distillation. These multitask capabilities enable developers to use a single foundation model across more of the development stack, simplifying tooling and accelerating iteration.

An Open Ecosystem for Reasoning‑Based AVs

Alpamayo 2 Super is part of a broader family of open models, frameworks and datasets for AV development.

Other tools in the family include:

• NVIDIA AlpaSim, which provides closed‑loop simulation.
• NVIDIA AlpaGym, which enables high‑throughput reinforcement learning.
• NVIDIA Physical AI Open Datasets, which supply data for training and testing.
• Open training recipes and an autolabeling pipeline to accelerate model development, training and validation.

Alpamayo has already surpassed 500,000 downloads on Hugging Face, reinforcing its position as the most-adopted open reasoning model family for autonomous driving on the platform.

DiffusionGemma Technical Report

We introduce DiffusionGemma, an experimental open-weight language model that uses discrete diffusion to generate text at exceptionally high speed. Rather than decoding one token at a time, DiffusionGemma iteratively refines blocks of 256 tokens in parallel, avoiding the sequential decoding bottleneck of conventional autoregressive (AR) large language models. Instead of training from scratch, we obtain DiffusionGemma by fine-tuning the mixture-of-experts Gemma 4 model with 3.8B activated and 25.2B total parameters. Our compute-efficient two-stage training pipeline uses fewer than 10% of the starting AR model's total training token budget. The first stage uses supervised fine-tuning to teach bidirectional denoising, while the second stage combines reinforcement learning with sampler distillation to jointly improve generation quality and inference efficiency. DiffusionGemma establishes a new Pareto frontier for the trade-off between generation speed and model capability. Averaged across our full evaluation suite, it generates around 20 tokens per forward pass and achieves roughly 1,500 output tokens per second on a single NVIDIA H100 GPU, which is substantially faster than AR models even with state-of-the-art speculative decoding. DiffusionGemma also retains the starting model's support for thinking mode, multimodal inputs, and long contexts. Despite diffusion fine-tuning, it remains capable of AR generation with only minor performance degradation, suggesting a path toward hybrid diffusion-AR decoding.

It’s late on a beautiful Friday afternoon, and you’re getting ready to sign off and enjoy the weather. Just as you’re wrapping up, a teammate pings about an urgent latency spike and needs your help. You remember a similar incident, which metrics to investigate, diagnostic tests to run, and where the logs pointed last time. Isolating the issue won’t be especially difficult. It’s just that you need to be across several tools, and you can only be in one place at one time.

That’s the shape of real engineering work. It was never one task in one session. It spans repos, tools, reviews, and days. Even when a single task runs on its own, you are still the one holding it together, reconnecting context, coordinating the handoffs, and stitching your tools into something that keeps moving. You end up being the integration layer between your own tools, and the moment you step away, everything stalls and waits for you to come back.

Kiro Crew takes on that work instead. Now you can shoot off a message to your crew to find what you did last time, write it up, and send it to your colleague, without needing to step in again to make it happen, and you wrap up your day and head out, seeing a note from your team that the issue is resolved.

Hand Kiro Crew a ticket queue and it triages and dispatches, identifies owners, and flags what needs your attention. Point it at an incident spread across repos and it investigates while you stay on the fix. Kick off a migration and it keeps moving through checkpoints and retries while you are in a meeting or asleep. It connects the tools you already use and coordinates the work across sessions, so you come back to progress, not a workflow to restart.

How Kiro Crew started

Kiro Crew began as a side project called MeshClaw inside Amazon. Three of us wanted something simple that wasn’t available internally, a way to kick off a task, walk away, come back to something worth reviewing, and to run several tasks at once instead of babysitting one prompt at a time. We were inspired by the momentum of OpenClaw and various tools with self-learning agents taking over AI work, but we needed something that met our security requirements for internal development work. As our go-to coding tool, building something on top of the Kiro harness via the CLI felt right.

We built it for ourselves first. Then other builders inside Amazon picked it up, and the shape of what happened next is the whole reason we are releasing it openly. Builders of diverse backgrounds weren’t just using it, they were extending it for what they needed. When someone hit a gap in their own workflow, they added the piece they needed and it stayed, for them and for everyone after them. A lot of what got built was work that would otherwise have sat in a backlog, the narrow edge cases and the quality-of-life fixes that only the person living in that workflow would ever think to add. In less than 6 months, Kiro Crew has been adopted internally by over 39,000 Amazon builders, with nearly 500 contributors shipping 597 updates at an average pace of 143 weekly commits. Those small, specific contributions compounded, and a personal side project became something maintained by a community across many roles, not just engineers.

Those compounding contributions are what convinced us to open source it. A workspace with access to your code and tools should be something you can read, run where you want, inspect, and change, even if you are the only person who wants a particular tweak. This space is moving fast, and open source is how we put something we already know is useful into developers’ hands and let it keep evolving with the people who use it.

Security for real work

Handing that work over means giving Kiro Crew real access to your code and CI, so it is built to be safe from the first commit. Kiro Crew ships with defense in depth from day one, an OS-level sandbox, denied-by-default commands, suspicious-pattern blocking, input validation, sensitive-path blocking, credential redaction, and a signed audit log of every action. Plenty of agents are open source. What makes Kiro Crew safe to hand real work is that it is built for developers from the ground up, with the security posture production code demands. Because it is open, you can verify every layer against the source and watch what it does with the access you give it.

A workspace acting on your code should also never be a black box. Kiro Crew orchestrates agents behind Agent Client Protocol (ACP), and every step is observable live. You can watch how it plans a task, spawns parallel sub-agents, decides which tools to call, gates each action for approval, and synthesizes the results back together. The Activity view shows each agent’s reasoning, every tool call, and the results as they happen, as one card per agent on the dashboard.

You also decide where it runs. Work with Kiro Crew directly through the desktop app, web dashboard, or TUI, across conversations, files, tasks, approvals, memory, schedules, and Apps, and run it locally or on a remote machine you control. Connect tools like Slack, Telegram, and Discord and continue the same work from another surface without moving the workspace or its state. The dashboard binds locally by default, sensitive paths and credentials are guarded at runtime, tool requests can require approval, and activity is recorded for review.

Built for how developers work end-to-end

Kiro Crew is built to run across sessions, like investigating an incident across several repos at once, running a multi-hour migration while you are away, or a morning update that checks open PRs and fixes the flaky tests before you log on. A few things make that possible.

• Agents are self-learning and self-evolving: Memory carries preferences, active-project context, and relevant history into new sessions, so it does not start cold. Corrections become durable lessons that change later behavior, including workspace-scoped lessons for project-specific guidance. Repeated patterns become reusable skills you can inspect, edit, or remove as your work changes. Memory, lessons, and skills stay visible, so you decide what your crew carries forward.
• Your agent crew keeps working when you are not: Recurring jobs run on schedules you define. A morning digest can collect what needs your attention, a heartbeat can watch a PR or deployment until its state changes, and an authenticated webhook can start work when an external event arrives. Jobs that do not need reasoning run as plain scripts or commands without a model call. Longer tasks keep moving through checkpoints, validation, and retries while you work on something else.
• It coordinates more than one agent: For work that benefits from more than one, run several conversations concurrently, each with isolated context, or delegate independent research and implementation to subagents that return their results to the parent conversation. The main conversation stays focused on the goal while specialized agents handle work in parallel.
• It brings the work into purpose-built interfaces: Some work does not belong in a chat window. Kiro Crew brings it into Apps, sharable, purpose-built interfaces to automate your workday without chatting every instruction. Apps combine custom UI with agents, skills, schedules, integrations, and backend services. MCP Apps and plugins bring data and actions into that experience, while Kiro Crew organizes how work moves from intake through review to completion. An issue-triage App, for example, brings repository data into a queue with a reading pane, triage controls, specialized agents, and scheduled scans. The available Apps in the app store will continue to expand, but at launch will include Apps like DevFleets for work tree management, Task Runner for executing long-running tasks, and Issue Radar for triaging issues and pull requests. You can also create your own Apps with the App SDK for any tools or use cases not yet captured or quite how you want it.

You make it your own

Kiro Crew did not grow because of its architecture. It grew because people could bend it to their own work and preferences. That same potential is now yours, to build your own customized crew of agents at your disposal, coordinating across your unique tools and workflows to keep your work moving.

The features launching today were built by people using Kiro Crew for their own real work. The ones you need next, you can build. Bring the tools you already use over MCP, build an App, shape the orchestration, and keep iterating on what you make. Skills you already have work here too. Anything built for other open standards-based agent platforms runs with Kiro Crew without modification, so you can bring what you have rather than start over.

How we run the project

We want our developer community to experience the joy of building with Kiro Crew the way we have internally as MeshClaw was developed. So, Kiro Crew is built in the open, and that includes how it is governed. The project is run by a steering committee of maintainers listed publicly in MAINTAINERS.md, working under a deliberately minimal governance model. Proposals are filed as pull requests and debated in the repository, and decisions are documented there for anyone to read. Any developer can take part in those discussions. Contribution, discussion, governance, and roadmap planning all happen in the open, so the community can directly shape what ships next.

We also mean open in a way that matters for trust. We support community contributions of every kind, including integrations with other AI coding tools and providers. If it helps developers do their work, it belongs here, whether or not it maps to Kiro’s own product strategy. Kiro dedicates engineers to keep the core project healthy and respond to every issue and pull request. It starts with Kiro and AWS engineers maintaining the project, and as trusted contributors emerge, the model can grow to include maintainers from outside our teams. The roadmap is meant to be a conversation, and not a decree.

Built on Kiro

If you already use Kiro, your configuration comes along. Kiro Crew runs on the Kiro CLI at launch, reading your existing .kiro configuration out of the box, so your steering files, skills, and custom agents carry over with no extra setup.

Get started

Download from the Kiro Crew page or clone the GitHub repo today. The repository includes setup instructions for macOS, Linux, and Windows, along with guides for connecting Slack, Telegram, and WeCom.

Start with work that already extends beyond one session, such as a migration, a recurring review, or a pull request that needs monitoring. Then install an App, build a skill from a repeated workflow, or contribute the integration your work needs next. Kiro Crew grew by developers sharing what worked for them, and the open source release gives everyone a way to shape what it becomes. We can’t wait to see what kinds of use cases and functionality you build out, and we hope you have as much fun playing and experimenting as we have.

The computer use verification skill that every agent needs

In this post I’ll describe how to add computer and browser use to your agents to reproduce issues and verify fixes and new features.

For folks unfamiliar with computer and browser use, it’s a tool that allows agents to control a running application directly with mouse clicks and keyboard presses. Most of the major model providers have models that support this, and they are increasingly available in different harnesses, including Warp.

The value of computer use in your cloud software factory is less as a standalone agent, and more as a capability to provide to other agents in the factory flow. Specifically, computer use is valuable:

• During the triage phase to reproduce bugs before trying to fix them
• During implementation to verify fixes and verify that new features match specs
• During review to prove to a human reviewer that code actually matches expected behavior

The verification is particularly valuable as a way of lessening code review burden. If you can see a video of a feature working, you are more likely to trust the underlying code. Especially for pure UI changes that are low risk, having “proof” that a feature works from the user perspective is valuable and saves time.

Another less obvious benefit of computer use is that it lets an agent create a loop where it can debug changes on its own. This works especially well with spec-driven development when you have a detailed PRODUCT.md that the agent is trying to implement. At every implementation pass, it can run computer use to see how close the implementation is to spec, and continue until it’s good.

As with prior posts, you can use the implementation on your own repos by following the open-source demo. There’s a skill you can install and then invoke from your favorite coding agent to directly set up everything on your own repo:

npx skills add warpdotdev-demos/cloud-factory-demo --skill oz-cloud-factory-demo

Add computer use verification to your agents

Diving into computer-use, we create a new skill called verify-behavior that defines how to use computer and browser use.

The key aspects of the skill are:

• When to use computer use (desktop and mobile-native) vs. browser use (webapps)
• What to capture: video preferably, but screenshots are fine
• The two modes to use it in:
  • reproduce: try to confirm that a reported bug occurs
  • verify: verify a new behavior

In order for this skill to work, it needs to be run through a harness that supports computer and browser use. Since we are building a cloud software factory, this should be a harness that supports cloud agents. At this point, you can run the verify-behavior skill directly, but it’s actually more useful to hook it into the other agents in your factory as a capability they can take advantage of. To do this, we will update the existing Triage, Review and Implementation skills to encourage them to use the verify-behavior skill when it will help them do their jobs.

Note that the verify-behavior skill uses cloud subagents. You can also do computer use locally, but it tends to be a worse experience unless the platform you’re using can test in the background. Warp and Codex do support this, but it still tends to be best in my experience to do computer use on a cloud machine where there’s no chance of the agent doing anything weird with the apps running on your machine.

For complex or new behaviors, we ask our orchestrator to fan-out to verify all of the user stories independently and in-parallel. Computer use is typically single-threaded, so if you want better throughput, it’s best to fanout cloud agents across machines.

Computer use in action

I have a demo repo that I’ve used in a few of these posts that implements a simple agentic image editor. As a first user story, I’m going to show how you can use computer use to verify an issue. In this case, there’s a bug in the demo app: when an image is uploaded, its preview renders at thumbnail size rather than gallery size.

This is a trivial example, but for folks dealing with bug reports, having images automatically generated to verify the reproduction is a big unlock.

Moving on to a second use case, I asked an agent to implement a new feature in this repo end-to-end and verify it using computer use. The feature is a relatively straightforward UI change, adding “clear” and “replace” controls to the image editor.

It really is that simple – once you have the scaffolding set up you can use computer use to help lift the burden on PR review. In fact, for low-risk UI changes, you might decide that watching these videos is enough and you don’t need to look at the code at all.

To recap, we have created agents that:

• Triage new issues, optionally sending them to be implemented or spec’d
• Spec issues from a product and technical perspective
• Implement the actual code
• Review the code and improve review over time with an observer loop
• Added a verification capability that all of the other agents can use

These posts show how, with a simple set of primitives, you can start to build your own factory and truly automate more of your mundane work. The primitives are just:

• A cloud agent platform like Warp that supports computer-use
• A workflow tool like GitHub Actions
• A set of agent skills that you and an agent can tune

NemotronLabs VoiceChat is an 11B end-to-end speech model that handles streaming understanding, speech generation, and tool calling within one architecture.

The Reverse Replicator

The dream of the digital twin is now reality. Your whole factory will be digital.

Star Trek had the replicator: a machine that creates anything. We built the reverse. It takes anything real and creates a digital version you can make, modify, or improve.

Since the first industrial revolution, manufacturers have dreamed of having complete control over their manufacturing process. But today, most factories can't quickly create replacement parts. When something breaks, they have to start by reverse engineering it — making it digital. It's an hours-to-days-long process that costs about $1,500 per part. Our new AI model does it for about $10, in one to five minutes.

We're currently deployed at a top automotive manufacturer. They have a little black box that can automatically digitize half the parts they put inside it. By the end of the year, it will be nearly all the parts. They are living in the future.

This means when a part breaks and takes the assembly line down, they'll already have the digital file to quickly create the replacement. What does this mean? They'll make the exact same truck you know and love, for less money. And higher quality. Then they can reinvest those savings into designing the next truck. When we put more resources into designing the future, humanity moves forward.

Nobody has their CAD

Here's the thing almost nobody outside manufacturing knows: factories don't have digital models of their own parts.

Walk into a modern plant and ask to see the CAD model for a random part on the line. There isn't one. Production lines are built by third-party integrators who don't hand over models. Components go out of production. Some machinery predates digital design entirely. A typical factory has digital models for a fraction of one percent of its parts. Even Airbus had to spend hundreds of millions of dollars recreating the CAD for the A320 — a plane they make.

Why? Because until now, digitizing a part meant putting it in front of one of the few people in the building who can drive CAD — and those engineers are buried. Most of their reverse-engineering queue isn't new design work. It's measuring a part that already exists, rebuilding it feature by feature, and arriving back exactly where the physical world already was. At $1,500 a part and a million parts in the building, nobody digitizes their factory. It's not that they don't want to. The math has never worked.

We changed the math.

Why this is possible now

3D scanning solved half the problem years ago. You can teach someone to scan a part in a day, and the scan captures the surface with incredible precision. But a scan is a mesh — millions of triangles. You can look at it. You can't engineer with it. You can't modify it, dimension it, or send it through a real manufacturing workflow. That last mile — mesh to real CAD — is the part that took years of experience. That's the part we built a foundation model for.

Our second-generation model was built from the ground up for 3D geometry. We trained it to construct parts the way an engineer does: by chaining CAD operations — extrude, revolve, pattern — into a full feature tree. The output isn't a frozen blob that merely looks right. It's native, parametric CAD that looks like a really good engineer modeled it, because the model learned to design the way really good engineers design. Open the feature tree, change a dimension, and keep working.

Then we layered agents on top. The model reconstructs a part, checks its own work, and iterates. Give it more time in Thinking Mode and it works through complex geometry the way an engineer would grind through a hard part. This is the first time anyone in manufacturing has had an AI model that actually works for them.

From fire drill to known process

Today, a broken part is a fire drill. Downtime on an automotive line can cost tens of thousands of dollars a minute, and the clock starts the moment something snaps. Everything waits on one question: can anyone find or recreate the model?

Now flip it. At $10 a part, you don't digitize reactively — you get ahead of it. Scan the spares shelf. Scan the grippers. Scan the fixtures. Run campaigns through the plant until everything is in CAD. Then a broken part isn't a fire drill anymore; it's a known process. Pull the file, hit print or send it to the CNC, and the line is back up.

And that's just defense. The offense is better: when your engineers aren't burning skilled hours recreating things that already exist, they're improving them. You stop treading water on maintenance and start compounding on upgrades. That's what a digital factory actually means — not a buzzword, not a mesh file you can't use, but every part at your fingertips, editable, manufacturable, yours.

This isn't taking jobs, either. It's a force multiplier. The engineer who could digitize seven parts a day can now direct seventy. And the technician who found the broken part — the person who was never going to spend three years learning CAD — can now produce a real model with a scanner and a click. We just made millions of people capable of building what they can imagine.

Try it today

This is live right now. Not a waitlist, not a demo video — live.

If you use Autodesk Fusion, install our add-in and the copilot works inside your existing environment, including AI photo search across your CAD library. If you don't, use the web app from any browser and export .STEP files that open in any mechanical CAD package. A free account gets you four conversions. Plans start at $20/month.

You have parts. You don't have their CAD. For the first time in history, that's a solvable problem — for less than the cost of lunch, in less time than it takes to eat it.

Throw a part in the box. See what comes out.

Samsung's new memory system vertically stacks high-bandwidth memory on top of AI accelerators. It delivers about eight times the performance and more than 10 times the memory density of next-generation HBM5. Samsung plans to ramp up production of HBM4 in the second half of this year. It has yet to offer a definitive timeline for HBM5 or this future technology.

GitHub stacked pull requests give developers and their agents a native way to decompose work that otherwise lands in a giant pull request. It turns pull requests into a chain of small, focused, and independently reviewable layers, each scoped to a single concern. This post explains how to use stacked pull requests to simplify reviews.

The end of the age of heroes

AI will soon be better at math than any human. What does that mean?

I had a great-uncle who was a “human calculator”. It’s an odd, rare ability that allows people to multiply large numbers quickly in their heads. I remember using a hand calculator and seeing if my uncle could get it right without a tool faster than I could; more often than not, he could.

Human calculators used to be very valuable as employees, back when calculation was done by hand. Today they’re just a curiosity. Technology came along and superseded that particular human ability, as it has so many others. The story of John Henry being superseded by the steam drill, or Paul Bunyan by the chainsaw, is a metaphor for the march of progress. In some cases, like Garry Kasparov or Lee Sedol losing to computers at chess and Go, the moment really happened.

This week marked another important such moment in the history of man versus machine. OpenAI announced that its new model, Astra, managed to solve ten major outstanding problems in math and theoretical computer science. Here’s a simple explanation of the problems. The general consensus seems to be that these are extremely important, stunning breakthroughs.

This does not mean that computers are now capable of doing every kind of math better than humans can. Some people have argued that AI is good at results where the solution can be found by reading the entire literature and combining existing insights — exactly the kind of thing you might expect a computer to be superhuman at — but still not as good as humans at making truly novel leaps of insight. This may represent a real, general limitation of LLMs’ capabilities — as Tom Zahavy of Google DeepMind put it, it may still be the case that “LLMs can’t jump.”

But the trend line is becoming clearer. The University of Toronto’s Daniel Litt, one of the most prominent skeptics of AI’s potential for frontier math research, recently conceded a major bet about what AI could do.

Litt appears to no longer believe that there is any important type of math that AI won’t soon be able to do, writing: “The models don’t yet seem able to do certain kinds of high quality research, but I also expect this is a matter of (not too much) time.”

Some mathematicians have reacted to this development with despair. Kirwin Hampshire’s post is probably the most evocative and the most well-read.

He writes:

I am suffering a profound spiritual crisis due to these developments. I have been screaming internally for days. It feels as though I am living inside of a nightmare…For me, the affective quality of learning mathematics is empathetically tethered to an act of discovery and creation…If The Library of Babel existed, would authors continue to write books?…

Perhaps I shouldn’t tell you this, but my aim is to be open: These developments have triggered some deranged thoughts in me. I have wondered if it is the express goal of these companies to make me kill myself…The story of human discovery and the triumph of the human spirit will soon be excised from this discipline…[T]he process of prompting novel proofs will be as auraless as ordering doordash. Watch as magic and mystery evaporate. Watch as the sun sets on our heroic age…

There is nothing I can do. There may be nothing you can do. I have no prescriptions, policy recommendations, or coherent call to action. I just want to be honest and open about my emotional and spiritual response. I want to feel seen….I need the architects of our new mathematical paradigm to look me in the eye and acknowledge our shared humanity and soul before they deliver the coup de grâce.

Math PhD student Tasmin Chu, meanwhile, urges a more confrontational path, calling on mathematicians to avoid working with AI companies and to aggressively preserve the way that math research is currently done. This seems extremely unlikely (and would fail if it were attempted), but it demonstrates the depth of emotion out there.

Even the mathematicians who don’t share Hampshire’s despair have expressed alarm at the sudden disruption of their profession. The entire way that mathematical research works — training grad students, working on problems, collaborating with colleagues, building theories — is going to have to be overhauled.

I’m not a mathematician; I never have been. I can’t fully understand what mathematicians are going through right now. But I do have a few thoughts on what AI’s supersession of human mathematics research means for our species, so I thought I might as well share those. Some of these ideas are a little vague and half-formed, and for that I apologize in advance.

Heroism has to change

Humans have always valued standout individual achievement — heroism. We pride ourselves on being able to do what no one else could have done, and we heap status and respect on people who make standout achievements. But this was always a little bit of an illusion; most of what we did was always a collective enterprise. Workers work in teams, and those teams rely not just on the resources of their organizations, but on the smooth operation of a whole network of other teams and organizations all over the world.

We always bridled at being reminded of this; when Obama told entrepreneurs “You didn’t build that”, he was making the anodyne point that organizations and institutions matter, but people still got very mad. We motivate ourselves with our own sense of heroism, and to be reminded that we’re cogs in a machine greater than ourselves makes life seem a little less meaningful.

The scientific enterprise was also always mostly a collective one. If you look at what almost any scientist does, they’re simply adding a little bit of data to our pool of collective knowledge. Almost all research is incremental stuff — a slightly novel experiment, a little wrinkle in an existing theory — and many published research findings are false, and yet the scientific enterprise collectively gropes its way toward the truth. Even Nobel prize winners are often just managers of huge teams of researchers who never get gold medals or get to give speeches in Stockholm.

In essence, humans were always what we now call edge compute — little devices that reported data back to a central world-mind. Except the world-mind we reported to wasn’t a computer; it was society itself — the network of corporations, governments, universities, and human networks that disseminated human knowledge and coordinated our actions.

But there were a few of us who really did get to be heroes — or at least, a bit more heroic than the rest. Whether because of greater raw ability, or a luckily unique perspective, there were some people who could do things that the entire rest of the world couldn’t do. Isaac Newton invented calculus and classical mechanics all by himself. Grigori Perelman, sitting in his little room in Russia, solved a famous math problem that had bedeviled the entire profession for decades. Andrew Wiles did something similar a generation earlier.

These advances weren’t done ex nihilo, of course — every great discoverer and inventor stood on the shoulders of proverbial giants. But in mathematical theory there was almost always some nub of hard work, some brilliant leap of genius, that belonged to one person alone. Some part of the excitement of becoming a mathematician surely had to do with the dream of becoming one of those heroes, without whom a great discovery simply couldn’t have been made.

We normally think of AI as something that replaces a single human worker, but I think that’s the wrong way to think of it. AI is really a new world-mind — a technology that takes the accumulated findings of individual humans and integrates them into a general picture of the world. AI uses all of human knowledge as its training data.

But unlike human society, AI doesn’t need heroic human geniuses. Its ability to understand complex ideas is not limited by the ability of a single human brain to apprehend, intuit, or communicate those ideas. The information bottlenecks that our greatest mathematicians were able to slightly widen have now been done away with completely — or will be soon.

That doesn’t mean human scientists and thinkers have become irrelevant. At least for now, AI still requires us to provide the role of edge compute. We go out into the world, discover new facts, mix them with our unique individual experiences to form new perspectives, and communicate all this back to the AI world-mind. For most people — even most scientists — this is basically the same thing they were doing before, except instead of a group of their colleagues at a seminar, they’ll be reporting their findings to AI.

And for lots of scientists, AI’s mathematical prowess is going to open up a new golden age. Math was always one of the hardest parts of science; it’s something our brains aren’t naturally adapted to. Now that constraint is alleviated. Economists don’t have to worry about wracking their brains writing theory sections; they can focus on getting data and understanding empirical results. Przemek Chojecki writes:

From a perspective of science or mathematics (not mathematicians), this is the best time ever. AI will lead us to the new age of mathematical discoveries and boost science progress 100x.

But mathematicians, and anyone else whose sense of accomplishment came from being the indispensable solvers of hard theoretical problems, will have to learn to get their sense of self-worth and accomplishment from other sources. Jacob Tsimerman, who just won the Fields Medal and promptly took a job at OpenAI, sums it up:

I do not do mathematics only to find truth. I do it largely because I enjoy it and I am good at it. I also find it beautiful and am grateful I get to spend my days understanding beautiful things. But I enjoy the challenge, the process, resolving confusions, finding strategies, grappling with problems…There are many people whose primary enjoyment of math comes through problem solving in one of its incarnations. If that disappears, that is not a trivial issue and many of them might not want to do it anymore.

Mathematicians after the age of heroes

First of all, let me say that I do not think AI will take mathematicians’ jobs. The reason is that mathematicians, as a class of people, are actually incredibly cheap. In other words, we already employ most mathematicians because we think human understanding of math, even without industrial applications, is inherently worthwhile. That isn’t likely to change in the age of AI. Even if AI “discovers” a vast number of new mathematical results, most people won’t care; what will be important is that some human understands what AI has discovered.

Just because you press a button and make AI solve a problem doesn’t mean you understand the solution, and it doesn’t mean you immediately have an idea of what other problems you’d like solved. Mathematicians have been given an incredible new tool to understand the world — like miners getting hydraulic excavators or powered drills — and since the amount of math out there to be discovered is probably infinite, using that tool will take a lot of work.

For those mathematicians whose sense of wonder and meaning comes primarily from learning new things — who do math to “find truth”, in Jacob Tsimerman’s words — life will only improve. And while that won’t be as heroic of a job as what math research used to be, it’ll still be a prestigious one, because most humans will still be unable to do it.

And mathematicians who enjoy the extreme mental difficulty of math will still get to enjoy it. AI will make any given math problem a lot easier to solve, and it’s generally a lot easier to understand a solution than to find one. But AI will also come up with — and will allow humans to come up with — much harder problems than have been created so far.

So mathematicians will still be able to get paid to do math. They’ll still be able to learn new things, have fun, and get respect from society. The only thing they’ll really lack is heroism — the knowledge that their own special, rare natural abilities alleviate a key bottleneck to human flourishing.

But that’s not so bad, really. Most people never get the chance to be heroes. They have to find meaning just from being regular people — from taking care of their kids, having friends, having hobbies, joining civic organizations, getting involved in politics, and so on. It’s not such a terrible fate.

Well, maybe not. Society can handle ideas more complex than a single human can understand, but those ideas have to be able to be broken down into pieces that a single human brain can comprehend.

Starlink added 1.7 million new subscriptions in Q2, despite recent price increases that angered some customers. For the first time, the company also plans to launch gigabit V3 satellites into operational orbit during the next Starship test flight.

On Tuesday, SpaceX published Q2 earnings for the April to June period, showing Starlink has grown to 12 million paid subscriptions. The growth is high, and double its paid subscribers from a year ago. But questions have been circulating about whether the satellite internet service can maintain that level of user adoption after the company ended several promotions and began raising prices for the Starlink Residential plans in May.

The earnings report suggests the price hikes haven't deterred interested customers. "Connectivity revenues were up 32% sequentially and 66% year-over-year to $4.3 billion, driven by strong Starlink subscriber growth," SpaceX says.

Surprisingly, even with price hikes, the company’s average revenue per user remained at $66 per month, unchanged from Q1. The company attributed this to expanding its satellite internet service globally and ensuring it "fits local needs."

In an earnings call, CEO Elon Musk also said the gigabit V3 Starlink satellites will launch on Starship flight 14, but this time they'll enter an "operational orbit." Last month's Starship flight also sent up a batch of V3 satellites, but they remained in space for only about 20 minutes as part of a test before disintegrating on re-entry. "SpaceX engineers were able to successfully communicate with every satellite using radio frequency and laser links and downloaded key telemetry from the satellites," the company says.

Musk added that SpaceX will need a "critical mass" of V3 satellites, probably at a 1,000, before the company can start offering speed increases to Starlink. "Approximately, second quarter of next year, would be where we'd get to that point," he said.

The earnings report adds that Starlink saw even higher revenue growth from its enterprise and government customers, up 63% sequentially and 108% year-over-year to $1.8 billion.

“I would expect enterprise revenue to substantially exceed consumer revenue,” Musk added, pointing to the potential business demand.

Overall, SpaceX’s revenue reached $7.8 billion in Q2, up 92% year-over-year. But the company still posted a net loss of $541 million. "We ended the second quarter with $100 billion of cash, cash equivalents, and marketable securities, and $47.5 billion in backlog," it adds.

Starting today, wrangler dev and vite dev automatically capture OpenTelemetry traces for local Worker invocations. When Cloudflare's tooling detects an agent session, it points the agent to the Local Explorer API, a local debugging API where it can query those traces. You do not need to install an SDK, enable tracing, configure your agent, or even mention observability in the prompt.

A prompt can be as simple as:

POST /api/orders is returning 500. Find the cause, fix it, and verify the fix locally.

This builds on years of investment in local development, from introducing Miniflare to making local mode the default in Wrangler 3. Local traces give coding agents structured feedback from that development environment before code is deployed.

Agents discover the Local Explorer API automatically

As part of its normal workflow, an agent starts wrangler dev or vite dev to run and test the Worker. When the development server recognizes a supported coding-agent session, it automatically prints a hint that looks like this:

This dev session is running in an AI agent.

The Local Explorer API is available at
http://localhost:8787/cdn-cgi/explorer/api


... 

Debug with traces:
POST /cdn-cgi/explorer/api/local/observability/query -- query traces and logs with SQL

The Local Explorer is a browser-based interface and REST API for viewing and editing local resource data and querying observability data during development. The API root serves an OpenAPI schema, so agents can discover available endpoints at runtime without hardcoded instructions.

The automatically captured traces are available through a read-only observability endpoint in that API, together with their correlated console logs. The agent can query this telemetry, then use the API's other operations to inspect local Workers and bindings or examine state in D1, KV, R2, Durable Objects, and Workflows.

Find the failure and verify the fix

Consider POST /api/orders, which retrieves an active cart from KV, saves the checkout details into D1, and sends a message to a Queue for order processing. After a schema change, the endpoint suddenly starts returning a 500 status.

Without local traces

The 500 does not identify which operation failed. The agent adds logs around KV, D1, and the Queue, reruns the request, inspects the output, and repeats. Each cycle takes time and burns tokens while the agent reconstructs the request from text.

With local traces

The agent reproduces the error and queries the read-only observability endpoint. The trace shows that the KV read succeeded, the D1 insert failed with no such column: delivery_window, and the Queue was never called. Your agent uses the Local Explorer API to access the same trace data you would see here:

The agent uses the API to inspect the D1 schema. It finds that the migration adding delivery_window exists in the repository but has not been applied locally, applies it, sends the request again, and queries the new trace. Issue resolved.

In one local loop, the agent identifies the failed operation, fixes the local environment, and verifies the result without deploying or adding temporary logs.

Explore traces and logs in Local Explorer

Agents query local telemetry through the API, but you as a human can visualize the same data in the Local Explorer, the browser-based interface built into the local development server. Alongside browsing local binding state, you can select a request to inspect its spans, timing, attributes, errors, and correlated console logs.

Local Explorer runs on the same localhost origin as your Worker, not in the Cloudflare dashboard. Press e in Wrangler or visit /cdn-cgi/explorer on the local server to open it.

How it works

When we launched Workers Tracing, we built instrumentation directly into workerd, the open-source runtime that powers Workers. Without requiring an SDK or any code changes, the runtime captures spans for:

• Fetch calls: All outbound HTTP requests, including timing, status codes, and request metadata.
• Binding calls: Every interaction with KV, R2, D1, Durable Objects, Queues, and other bindings.
• Handler calls: The full lifecycle of each invocation, from fetch to scheduled to queue handlers.

Any custom spans emitted by your application will also appear alongside these automatic spans.

Wrangler and the Cloudflare Vite plugin use Miniflare to run your Worker locally in the same runtime, making this instrumentation available during local development.

Miniflare collects runtime events and console output, assembles them into OpenTelemetry traces and correlated logs, then writes the telemetry to an internal SQLite-backed Durable Object that serves as the local trace store. The Local Explorer API exposes that data through the local development server where agents can easily query traces and logs and inspect local state.

Get started

Update Wrangler or the Cloudflare Vite plugin, whichever your project uses:

# Wrangler
npm install --save-dev wrangler@latest

# Cloudflare Vite plugin
npm install --save-dev @cloudflare/vite-plugin@latest

Then ask your agent to debug locally as you normally would. Your agent can already write and run your Worker locally — now it can see what happened, fix what failed, and verify the result before you deploy. Check out the docs to learn more!

In vanilla Argo CD, “promoting to production” is really just editing a YAML file in a different folder and hoping you got it right. You bump an image tag in a production overlay, commit, and trust that what you just wrote matches what you verified in Development.

This is great until an auditor asks, “Who promoted this, and when?” or an incident traces back to a tag nobody meant to change.

Argo CD is excellent at keeping a cluster in sync with Git, but it has no concept of a release, i.e, no single, frozen artifact that moves from one environment to the next under policy.

In this guide, you will connect Argo CD to Octopus Deploy and turn promotion into a governed release, using the same immutable snapshot to move from Development to Production, gated by approval.

Why “promotion” is hard in vanilla Argo CD

Argo CD treats each Application as an independent unit. The dev install of your app and the production install are two separate Applications with no codified relationship between them. Nothing in Argo CD knows that “web in production” should receive exactly what “web in dev” was verified with.

Similarly, depending on your organization or team, promoting to an environment could mean a separate namespace or an entirely new cluster, both of which Octopus Deploy can handle.

That fragmented trail is slow and painful to reassemble at exactly the moments you need it most. Like when an auditor asks who promoted what and when, or when you are mid-incident trying to work out what changed.

Whereas, what you want is a single, frozen release that moves through environments under governance: verified once in Development, promoted unchanged to Production, with the who and when captured automatically.

That leaves two do-it-yourself options for promotion, and both are ad-hoc:

• Hand-edit the image tag in each environment’s overlay folder, commit, and let Argo sync. This is fast, but there is no record of intent, no gate, and nothing stopping a typo from shipping a different tag to Production than the one you tested.
• Script a pull request per environment. This is more controlled, but now your promotion logic lives in CI YAML and shell, reinvented per team, drifting as the estate grows.

Prerequisites

This walkthrough builds on the cluster and Octopus connection from the EKS connection post. You do not need EKS specifically, but you do need these pieces in place before the promotion steps make sense:

• An Octopus Deploy instance with the Argo CD integration (Octopus Cloud or self-hosted). This is where the project, lifecycle, and release live.
• A Kubernetes cluster you can install into. A local kind cluster is enough. Because the Octopus gateway dials outbound, no ingress or public address is required.
• Argo CD running in that cluster, connected to Octopus through the gateway. If you followed the EKS connection post, reuse that same cluster and its gateway connection. If you are starting fresh, the next section installs Argo CD and registers the gateway from scratch.
• kubectl, helm, and the argocd CLI installed locally.
• A Git repository for your manifests with Kustomize overlays per environment (the demo uses a public GitHub repo), plus a Git credential in Octopus that can push to it.

The architecture setup

For this demo, we’re aiming for a single Kubernetes cluster with two namespaces that serve as environments, dev and production, each with its own Argo CD Application.

Octopus owns the release and promotion process, and Git remains the source of truth, while Argo CD applies manifests to the cluster.

The Octopus gateway is a small component you install in the cluster with Helm; it dials outbound to Octopus over gRPC, so nothing in your cluster needs a public address. That means this entire demo can run on a local kind cluster with no ingress.

Install Argo CD with a dedicated octopus account so the gateway has its own scoped identity rather than piggybacking on admin:

helm install argocd argo-cd \
 --repo https://argoproj.github.io/argo-helm \
  --create-namespace --namespace argocd --wait --timeout 10m \
 --values - << 'EOF'
configs:
  cm:
    accounts.octopus: apiKey
  rbac:
    policy.default: "role:readonly"
    policy.csv: |
      g, admin, role:admin
      p, octopus, applications, get, *, allow
      p, octopus, applications, sync, *, allow
      p, octopus, clusters, get, *, allow
      p, octopus, logs, get, */*, allow
EOF

With Argo CD running, register the instance in Octopus, paste an auth token for the octopus account, and Octopus generates a Helm command for the gateway.

Run the generated Helm command against your cluster, and Octopus confirms the connection: the gateway registers, connects to Octopus, and connects to Argo CD.

Map the Applications with annotations

Octopus needs to know which Argo CD Applications belong to which project and environment. You declare that with two annotations on each Application manifest. No per-application configuration is needed in Octopus; the annotations handle the mapping.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: web-dev
  namespace: argocd
  annotations:
    argo.octopus.com/project: argo-web-promotion
    argo.octopus.com/environment: development
spec:
  project: default
  source:
    repoURL: https://github.com/your-org/gitops-web-promotion
    targetRevision: main
    path: overlays/dev
  destination:
    server: https://kubernetes.default.svc
    namespace: dev
  syncPolicy:
    automated: { prune: true, selfHeal: true }
    syncOptions: [ CreateNamespace=true ]

The argo.octopus.com/project annotation ties the Application to the Octopus project, and argo.octopus.com/environment ties it to an Octopus environment. The production Application is identical except name: web-production, argo.octopus.com/environment: production, path: overlays/production, and namespace: production.

Building the Octopus project with a Dev to Production lifecycle

Create an Octopus project and give it a lifecycle with two phases, Development and Production. The lifecycle is what makes promotion ordered, which simply means a release must pass through Development before it can reach Production.

Then add the built-in Update Argo CD Application Image Tags step to the deployment process. For each Application matched by annotation, this step retrieves the Git location from the Application, updates the image tag in the manifests, commits the change, and triggers Argo CD to sync. Add a container image reference (the nginx image, from a Docker Hub feed) so the release knows which image to update and what version to pin.

To make the governance visible, add one more step before it: a Manual intervention step scoped to the Production environment only. That is your approval gate. It runs when promoting to Production and is skipped for Development, so it stays fast while Production stays governed.

Create a release and deploy to Development

Create a release in Octopus and select the image version to promote, for example nginx:1.27.2. This release is a frozen snapshot of the process, variables, and package versions. Once created, it is immutable: the version that goes to Production later is the exact version you are about to verify in Development, not whatever happens to sit at Git HEAD.

Deploy the release to Development. Octopus commits the new tag to the dev overlay, and Argo CD syncs the dev namespace.

Promote the same release to Production

Now promote the same release to Production. Because the process has a Production-scoped approval step, the deployment pauses and waits for a human before it touches anything.

Approve it, and the same flow runs against the production overlay: Octopus commits the tag to overlays/production, and Argo CD syncs the production namespace. Production now gets exactly what was verified in dev, not a freshly hand-edited value.

The governance you got for free

• An immutable release snapshot. Release 1.27.2 pinned the exact image version. Production could only ever receive what dev verified.
• A Git commit per environment. Each promotion is a commit in your history, attributable and reversible.
• An approval record. Production promotion required a named human to take responsibility and proceed, captured in the deployment history.
• One view of what is running where. The project dashboard shows every environment and the release it holds, with live health from Argo CD.

Going from overlay edits to audited releases

Promotion should not be a YAML edit you hope you got right. With Argo CD connected to Octopus, it becomes a release you can govern.

Argo CD keeps doing what it does best: reconciling Git with your cluster, while Octopus adds a release model and an audit trail to that flow.

Add security context to operational investigations with AWS DevOps Agent and Wiz

When an on-call engineer receives an alert at 2 AM, a CPU spike, a latency anomaly, or an unexpected API error, the first question is whether this is an operational issue or a security incident. A CPU spike could be a scaling problem or a cryptominer. A latency anomaly could be a bad deployment or data exfiltration. Without security context in the investigation loop, engineers lack the information to distinguish between the two, delaying resolution and increasing risk.

AWS DevOps Agent is a frontier agent that autonomously investigates incidents and identifies operational improvements across AWS, multicloud, and on-premises environments. It reduces mean time to resolution (MTTR) by performing the triage and investigation work that would otherwise take an on-call engineer hours of manual effort. With the Wiz integration, AWS DevOps Agent queries Wiz’s security graph during investigations through the Model Context Protocol (MCP), surfacing vulnerability data, security findings, and exposure analysis alongside operational telemetry so engineers can quickly determine whether an alert is a performance issue or a security incident.

In this post, we walk through how the integration works, demonstrate a real-world incident investigation where AWS DevOps Agent uses Wiz MCP to surface a critical vulnerability behind an API latency spike, and show how to configure the integration in your environment. If you already use Wiz to secure your AWS environment, this integration puts your existing security data to work during incident investigations.

AWS DevOps Agent

AWS DevOps Agent investigates incidents and identifies operational improvements as an experienced DevOps engineer would: by learning your resources and their relationships, working with your observability tools, runbooks, code repositories, and CI/CD pipelines, and correlating telemetry, code, and deployment data across all of them.

AWS DevOps Agent is extensible through MCP, which allows the agent to call external tools during its investigation without requiring custom development. This is the mechanism that makes the Wiz integration possible. When the agent identifies a resource under investigation, it queries Wiz MCP for security findings associated with that resource and incorporates the results into its analysis and recommendations.

Wiz MCP

Wiz is designed to secure cloud and AI applications through a unified, graph-powered platform. The Wiz Security Graph connects infrastructure, identities, data, AI components, and runtime activity into a single contextual view. This approach identifies toxic combinations across layers – where exposures, permissions, data access, AI vulnerabilities, and runtime behaviors intersect in ways attackers can realistically exploit.

The Wiz MCP Server acts as a standardized gateway that allows AWS DevOps Agent to query this security graph during investigations. Wiz knows whether your Amazon Elastic Compute Cloud (Amazon EC2) instance has an exploitable Common Vulnerabilities and Exposures (CVE), whether it is publicly exposed, and whether endpoint protection is in place. AWS DevOps Agent, looking at the same instance, knows that CPU spiked, and a deployment happened 20 minutes ago. Separately, each tool tells a partial story. Together, they give the engineer the complete picture needed to act.

Better together: how combined context changes triage

The value of this integration is easiest to understand through three scenarios. Each starts with the same operational signal: a CPU spike on an EC2 instance.

Scenario A: No security findings. A CPU spike fires on an instance. AWS DevOps Agent queries Wiz and confirms the instance is fully monitored, has no known vulnerabilities, and shows zero active threat detections. This is an operational issue. The engineer scales, investigates the deployment, tests, and moves on.

Scenario B: Security issue detected. The same CPU spike fires, the same Amazon CloudWatch alarm triggers, and the same engineer wakes up. But when AWS DevOps Agent queries Wiz, it finds a validated remote code execution vulnerability on that instance, confirmed exploitable, with the resource exposed to the internet. The operational symptoms are identical to Scenario A. The correct response is the opposite: isolate immediately, engage your security team, treat this as a potential compromise.

Scenario C: Wiz coverage gap. The resource isn’t in Wiz at all. AWS DevOps Agent includes this as a finding in the investigation report, noting that no security context was available for the resource. Your team can then address the coverage gap by onboarding the resource into Wiz.

How the integration works: the MCP bridge

The integration uses MCP, the same protocol AWS DevOps Agent uses for many of its external tool connections. When the agent identifies affected resources during an investigation, it calls Wiz’s remote MCP server as part of its evidence collection – no separate step, no manual trigger. The security query happens alongside the operational investigation, not after it. During the MCP call, AWS DevOps Agent sends resource identifiers to Wiz’s MCP endpoint and receives security findings in response. No operational telemetry or broader investigation context is shared with Wiz.

The agent runs these queries together through a single security-auditing skill that loads automatically when it connects to Wiz’s MCP server with the DevOps toolset, so the full security picture comes back in seconds. If the Wiz MCP server is unreachable, times out mid-query, or returns an authentication error, the agent continues its investigation with the operational data it has and flags the missing security context in the investigation findings (Scenario C).

Getting started

Prerequisites

1. An active AWS DevOps Agent configuration with at least one Agent Space.
2. A Wiz tenant with a remote MCP server endpoint (Streamable HTTP transport).
3. Authentication credentials for the Wiz MCP server.

Enabling the integration

Step 1: Register the Wiz MCP server at account level

1. Sign in to the AWS Management Console and navigate to the AWS DevOps Agent console.
2. Go to the Capability Providers page from the side navigation.
3. Find MCP Server in the Available providers section and choose Register.
4. Enter the Wiz MCP server details.
5. Select the authentication method that matches your Wiz MCP server configuration.
6. Review your configuration and choose Submit.

Step 2: Allowlist Wiz tools in your Agent Space

1. In the AWS DevOps Agent console, select your Agent Space.
2. Go to the Capabilities tab.
3. In the MCP Servers section, choose Add.
4. Select the registered Wiz MCP server.
5. Select all the Wiz MCP tools.
6. Choose Add.

Step 3: Choose how the Wiz security audit runs

1. Use the Wiz skill tool (recommended). With the Wiz MCP tools allowlisted, AWS DevOps Agent automatically runs the latest devops_resource_auditing_skill workflow from Wiz during investigations.
2. Import the ready-made skill. Import the wiz-security-context skill from the AWS DevOps Agent skills repo directly into your Agent Space.
3. Create your own custom skill. Use AWS DevOps Agent’s Create skill with Chat to build a custom skill based on the devops_resource_auditing_skill workflow.

The power of co-build: extending context through MCP

This integration started from a recurring customer question: how do I know if what I’m seeing is an operational problem or an active attack? We worked with Wiz to close this gap. AWS DevOps Agent provides operational investigation and reasoning; Wiz provides cloud security intelligence. MCP provided the integration path without either side needing to reimplement what the other already does well.

Conclusion

Operational incidents and security incidents often start with the same symptoms. The difference between the right response to each is context that lives in a different tool than the one that fired the alert. The AWS DevOps Agent and Wiz integration brings that context into the investigation loop automatically through MCP.

GitHub accelerated case-folding in its code search engine from roughly 3 GiB/s to more than 45 GiB/s by removing an early-exit branch and using branch-free byte arithmetic that LLVM could fully vectorize. A compact Unicode lookup structure and allocation-free ASCII path keep the common case near memory-bandwidth limits, showing that two clean passes can outperform a seemingly efficient branchy single pass.

Agents remember. Humans innovate.

Latest: Team Memory Beta is evolving quickly — install it and start exploring in minutes.

Installation

Start all three services in one go (memory-core + memory-hub + proxy):

git clone https://github.com/Tencent/TencentDB-Agent-Memory.git
cd TencentDB-Agent-Memory/deploy/global-images
cp .env.example .env
$EDITOR .env       # Fill in two sets of LLM parameters (memory group + proxy group)
./start-all.sh     # Launch everything with one command; when finished, it prints a one-liner you can paste directly into Claude

Open the panel: http://localhost:8125.

Complete installation documentation (standalone Memory Hub deployment, Proxy + Claude Code / CodeBuddy usage, stop and cleanup, port reference, etc.) is available in INSTALL.md (中文: INSTALL_CN.md).

Migrating data from an older version

If you're already on an older release (v1.x / v0.x) and want to bring your existing data over to v2.0.0+, we provide a migration tool:

See Data Migration Tool (v2 → v3) for full usage and flags. New installations can skip this.

What is TencentDB Agent Memory?

We started from a practical question: How do you reduce repetitive work when using Agents?

If project context has already been explained, it shouldn't need to be repeated in a new session. If documents have already been read, every Agent shouldn't have to start again from page one. A workflow that already works shouldn't have to be rediscovered next time.

Memory here means more than just "remembering conversations." Any information that helps the next Agent avoid reinventing the wheel should be saved, organized, and reused.

Existing information → Reusable memory assets → Fewer turns → Less rework → More stable results and higher efficiency

Let experience accumulate, flow, and pass on to the next Agent

Memory Hub for Agent teams closes the loop across the entire experience lifecycle: work produces assets, assets circulate through the team, and new members can load the team's save file on day one.

1. Automatic asset extraction: Extract Chat Memory and Skills from conversations and tasks; convert documents and code into Wiki and CodeGraph; then manage, review, and route them consistently.
2. Portable & multi-Agent compatible: Memory assets are decoupled from Agent frameworks — they can move across frameworks and be shared and maintained by multiple Agents and team members.
3. Cold-start friendly: Import existing documents, codebases, and Agent conversation sessions. New Agent teams can start from existing experience instead of learning from scratch.

🧠 A brain that remembers people and context

• Chat Memory retains preferences, facts, decisions, and interaction history.
• Each Agent automatically gets its own memory when created — no need to re-introduce yourself next time.
• L0 Conversation → L1 Atom → L2 Scenario → L3 Persona — raw conversations are distilled layer by layer.

"Don't refactor the old auth module — mobile is still using it." — Context this costly shouldn't depend on humans repeating it every time.

⚡ A Skill library that accumulates expertise

• After completing complex work, Agents can extract and manage reusable Skills from conversations and tool calls, and import them into the context of a designated Agent when needed.
• A Skill isn't just a prompt snippet; it has versions, resource files, trigger boundaries, execution steps, and validation rules.
• Personal Skills are private by default; after review, they can be shared with the team and assigned to other Agents.

Troubleshooting, code review, release checklists — learn it once, and the whole team can use it.

📖 A knowledge map that reads both docs and code

• Wiki turns product docs, design specs, and ops runbooks into structured pages with a link graph. (Inspired by Karpathy's LLM knowledge base.)
• CodeGraph indexes code symbols, files, call relationships, and impact paths.
• Agents can search, read, inspect callers/callees, and perform impact analysis before modifying code.

Wiki keeps Agents from reading every file list before getting to work. CodeGraph doesn't just tell them "the code is here" — it tells them "changing this might affect those."

🛡️ A team memory panel controlled by humans

• Create teams and Agents in Memory Hub; review, share, and equip memory assets.
• Manage ownership, versions, status, visibility, usage counts, and Agent bindings in one place.
• private belongs strictly to the Owner; team is visible to all team members; restricted grants precise access via User / Role / Agent ACLs.
• Two role layers: global System Admin manages users and teams (creating teams, adding members) and can also use Wiki, CodeGraph, Skill, and other asset management features; Team-level roles include Admin (team manager) and Member (regular member), responsible for asset collaboration and access control within a team. Asset ownership is tracked via Owner — the Owner automatically has management permissions for their assets.

Cold Start: Load the Save File, Then Get to Work

Most Agents' first task is re-learning your project. TencentDB Agent Memory turns the learning cost you've already paid into a save file:

• Codebases: Import existing repositories — CodeGraph automatically indexes symbols, files, call relationships, and impact paths.
• Documents & files: Import relevant docs and files — Wiki automatically generates structured pages with a link graph.
• Conversation sessions: Import past Agent conversation sessions — Skills and Chat Memory are automatically extracted as reusable assets.

Stop retraining every Agent. Give it the save file.

One Play Style: Build a Growing Agent Team for a One-Person Company

Open Memory Hub and create a team:

Tiny but Serious Inc.
├── 👤 You · Set goals / Make decisions
├── 🔭 Scout · Research / Find opportunities
├── 🛠 Builder · Write code / Build products
├── 🧪 Reviewer · Test / Find issues
└── 🧠 Agent Memory · Preserve the team's experience

Recruit first, then equip

Different roles, different loadouts. Less noise — give each Agent the memory assets it actually needs to get work done.

The company can be tiny. Experience can compound forever.

Memory Assets, Not a Chat Log Warehouse

RAG answers "what can be found?" Team Memory also answers "who can use it, which version is valid, and which Agent should receive it."

Memory Hub Is Not a Display Board — It's a Control Panel

When you open an asset, what matters is not just "what it says," but also "where it came from, which version it is, who it's assigned to, and whether it's been used recently."

Every Loop Gains Experience

Memory doesn't run the Agent loop; it ensures the next iteration inherits the previous one's results: valuable interactions stay in Chat Memory, proven workflows are distilled into Skills, and document/code changes are updated through Wiki ingest and CodeGraph sync.

Without Memory, loops may just repeat faster. With inherited memory, each iteration has the chance to be better than the last.

One Agent Team: Shared Experience, Not Shared Privacy

New Chat Memory and Skills are private by default. Sharing is an explicit action, not a default leak.

Technical Implementation

TencentDB Agent Memory doesn't aim to "store everything." It solves three problems: what's worth keeping, who can use it, and how to retrieve less while retrieving the right things next time.

1. Memory isn't flat records — it grows in layers

Conversations are first saved as L0, then refined by an async pipeline into multiple levels of granularity.

2. Memory isn't a global prompt — it's the Agent's loadout

Chat Memory, Skills, Wiki, and CodeGraph are all registered uniformly as Memory Assets. Memory Hub uses Fixed Binding + ACL to determine which assets a given Agent can use.

3. Knowledge isn't injected wholesale — it's called on demand

Documents are organized into searchable Wiki pages that support link-graph drill-down; codebases are indexed into CodeGraph assets containing files, symbols, and call relationships. Agents first discover capabilities via /v3/tools/list, then use /v3/tools/call to read relevant pages, source code, or impact paths.

Benchmark

PersonaMem tests whether an Agent can correctly understand and apply user information after extended interactions.

Notes

• Wiki and CodeGraph are built asynchronously; allow some processing time before they reach ready status.
• CodeGraph currently prioritizes public HTTPS repositories; support for private repositories and SSH credentials is still being refined.
• The Hub supports manual asset binding; fully automated memory routing is still being iterated.
• TencentDB Agent Memory currently supports OpenClaw, Hermes, Claude Code, CodeBuddy, and SDK integration; broader cross-framework migration is on the roadmap.

Acknowledgements

TencentDB Agent Memory stands on the shoulders of the open-source community:

• CodeGraph — our CodeGraph asset module uses code from this project.
• Hermes Agent (Nous Research) — our Skill asset management uses part of the Skill-related code from Hermes Agent and builds further optimizations based on it.
• "LLM Wiki" by Andrej Karpathy — the idea of treating documentation as an LLM-maintained, incrementally growing knowledge artifact directly informed how our Wiki layer is built and kept up to date.

Community & Contributing

• 🐞 Found a bug or have a question? Open an issue in GitHub Issues — we respond within 24 hours.
• 💡 Have an idea to share? Start a thread in GitHub Discussions.
• 🛠️ Want to contribute code? Please read CONTRIBUTING.md first.
• 💬 Want to chat with us? Join our Discord community and talk to the core developers directly.

Let the path the team has walked become the next Agent's starting line.

Workers AI runs inference for some of the best open models in the world on GPUs in Cloudflare data centers close to your users. Two of the most capable, and most demanding, are Moonshot's Kimi K-series and Z.ai's GLM. They are large, long-context, mixture-of-experts models, and they are wonderful to use. They are also very hard to serve efficiently because of memory constraints.

We've written before about how we serve large models on Workers AI and about separating the prefill and decode phases of inference to get more out of each GPU. This post looks at three techniques we layer on top of that to fit these models into memory and keep them fast: quantizing the KV cache, compressing the model weights, and, because both of those pack more requests onto shared hardware, protecting the cache those requests share. These optimizations enable us to support more customers at lower costs, with no change in model accuracy.

All our experiments and production traffic are running and benchmarked with SGLang, an open-source inference serving framework. We found that SGLang offers the best performance in the market, and we work closely with the SGLang team to upstream patches and new features to make our work available to the open-source community.

Quantizing the KV cache

As a model generates text, it stores the attention keys (K) and values (V) for every token it has already processed in a structure called the KV cache. The cache is what lets the model extend a long conversation without re-reading the entire context on every new token. For a long-context model, it grows quickly, and it is usually the KV cache, not the model's weights, that fills up GPU memory first.

By default, the cache is stored in 16-bit precision (BF16). We store it in 8-bit floating point instead (FP8, e4m3), which halves its size. On Kimi K2.6, that raises the amount of context we can hold in memory from roughly 686,000 tokens to about 1.37 million, twice as much.

It's worth being precise about where the benefit comes from, because it isn't raw speed. Quantizing the cache adds a small amount of work per token, since the FP8 attention kernel has to convert values as it reads them. What it changes is how many requests we can keep resident at once. The following measurements are for Kimi K2.6 decoding on a disaggregated H200 deployment, comparing the attention kernels directly:

At any single concurrency level, BF16 is a few percent faster per token. But BF16 runs out of cache at 32 concurrent requests and can't admit a 33rd, while FP8 keeps going to 64 and reaches 2,192 tokens per second, about 41% higher than BF16's peak, for roughly 30% less cost per token. Because we run prefill and decode as separate pools, we can apply this where it helps most: prefill is compute-bound rather than memory-bound, so there we leave the cache in BF16 and keep its slightly higher throughput.

None of this would matter if it changed the model's answers, so we checked. Across our evaluation suite, FP8 and BF16 caches are indistinguishable:

Compressing the model weights

The KV cache is one demand on GPU memory; the model's weights are the other. For GLM 5.2, we compress the weights from 8-bit floating point down to 4-bit integers (INT4) with no loss in accuracy. The checkpoint shrinks from 705 GB to 421 GB, about 40%, and per-GPU memory across an 8-way tensor-parallel deployment drops from roughly 88 GB to 52 GB, which leaves room for around 1.18 million tokens of KV cache on the same hardware.

Across our evaluation suite, INT4 and FP8 weights are indistinguishable:

Smaller weights make the decode phase faster, and for a clear reason: generating each token means streaming the model's weights out of GPU memory, so decode speed is limited by memory bandwidth. Move less data and every token arrives sooner. The effect is largest at low concurrency, where per-request latency matters most:

Prefill behaves differently. It is compute-bound, and INT4 weights have to be expanded back out before the model can multiply with them, so that extra step makes prefill slower rather than faster, GLM sustains about 10,160 tokens per second of prefill in FP8 versus 8,660 in INT4. As with the KV cache, the disaggregated design turns this into a choice rather than a compromise: we run INT4 for decode, where it wins, and FP8 for prefill, where it wins. Model accuracy stays within 0.8 points of the FP8 model across every benchmark we run, making its quality indistinguishable.

Protecting a shared KV cache

Both techniques above have the same effect: they let many more requests share one GPU's memory at the same time. That efficiency is the whole point, but it also means hundreds of requests are reading and writing pages of the same physical KV cache. The mechanisms that make this fast, paged attention, continuous batching, cache reuse, all rely on getting the bookkeeping exactly right, and at our request volumes, even a one-in-a-billion mistake would show up regularly.

So we built KV cache integrity checking as a layer of defense. The idea is straightforward: every physical cache page gets a tag that changes whenever the page is reallocated, and the server records which pages and tags each request expects to use. Before supported decode operations read from the cache, those mappings are checked. If anything doesn't match, the affected request is aborted rather than allowed to return data from the wrong page.

The question that decides whether a safety check ships is what it costs. We measured it on a mid-sized production model in a two-prefill, two-decode configuration, with 8,192-token inputs and 1,000-token outputs:

The cost is under 1% on both throughput and tail latency, and even the upper bound of the 95% confidence interval stays near 1%. We kept it computationally cheap by running the validation as a separate batch check rather than fusing it into the attention kernel, which would have introduced a race between GPU thread groups. It's enabled per deployment, and the default path uses a no-op tracker with no measurable overhead, so deployments that don't need it pay nothing.

What's next

Serving frontier models efficiently is a moving target, and this is the ongoing work behind it. We're expanding FP8 KV caches across more of the fleet, validating NVFP4 weights on Blackwell (NVIDIA’s GPU architecture), and working toward making integrity checks something we can leave on everywhere at negligible cost. These optimizations will allow us to continue to support more customers at a lower cost and at the same accuracy.

If squeezing the best open models onto GPUs and serving them to millions of developers sounds like your kind of problem, come work with us.

Feature Flag Orchestration with AWS DevOps Agent and LaunchDarkly

Introduction

Organizations that use feature flags alongside incident response tooling often connect the two manually. When an outage occurs, engineers must identify which flags are relevant, decide whether to disable them, and coordinate the change across teams. This manual process adds latency at the moment it matters most.

You can use AWS DevOps Agent and its MCP server feature to connect to LaunchDarkly’s hosted MCP server, enabling feature flag recommendations during both proactive deployment review and reactive incident response workflows. Once connected, DevOps Agent can query flag state, read targeting rules, and surface recommendations directly within the workflows where engineers make decisions.

This post walks through two primary use cases:

1. Pre-deployment review where the release management capabilities in AWS DevOps Agent evaluate changes and a DevOps Agent Skill recommends feature flag coverage before code ships.
2. Incident response where DevOps Agent queries LaunchDarkly flag state via MCP and recommends containment actions during active incidents.

We also cover the connection architecture, a reusable DevOps Agent Skill for pre-deployment flag validation, and links to get started.

Defense: Release Management and Proactive Flag Recommendations

Figure 1: DevOps Agent’s readiness review identifies high-risk PRs and recommends LaunchDarkly feature flag coverage before code ships.

The release management capabilities (now in public preview) in AWS DevOps Agent evaluate code changes before they ship to production.

It performs functional testing in an AWS-managed verification environment, assesses risks to cross-codebase dependencies, evaluates adherence to your organization’s standards and best practices, and mathematically verifies that access control configurations in CloudFormation do not deviate from Well-Architected best practices.

AWS DevOps Agent is designed to be extended and customized to fit your tools, standards, and practices. Using the product’s primitives, you can add Skills that enhance its capabilities. For example, when a high-risk change is identified, a custom Skill can evaluate whether the change has adequate feature flag coverage, operating on deployment metadata and code analysis to identify gaps and surface a recommendation to the developer, such as recommending feature flags with LaunchDarkly when needed.

What the Skill Evaluates

The release readiness flag Skill classifies code changes into risk tiers (Critical, High, Moderate) based on what’s being modified — payments, authentication, database schemas, third-party integrations, new API endpoints, performance-sensitive paths, and more — and recommends feature flags proportional to the risk level.

Figure 2: The high-risk-feature-flag-recommendations Skill configured in AWS DevOps Agent’s Knowledge panel.

What the Recommendation Includes

When the Skill identifies a gap, it surfaces a recommendation containing:

• Risk context: Why the change is flagged as high-risk (e.g., “This deployment modifies payment authorization logic across 3 downstream services with no existing rollback mechanism.”)
• Suggested flag configuration: A proposed LaunchDarkly flag key, variations, and default targeting rules aligned with the deployment plan.
• Rollout strategy: A recommended phased rollout (e.g., internal users first, then 5% of traffic, then full rollout) that matches the risk profile.
• Kill-switch behavior: What happens when the flag is turned off — the fallback code path, cleanup considerations, and data consistency implications.

Example Scenario

Consider a team deploying an update to a tax calculation service. The change modifies the tax rate computation logic, affecting all order totals across multiple regions. AWS DevOps Agent evaluates the deployment and classifies it as high-risk. The pre-deployment flag gate Skill then identifies:

• The change touches critical-path tax calculation code.
• No feature flag wraps the new computation behavior.
• The blast radius covers all active checkout sessions.

The Skill surfaces a recommendation: “This deployment modifies tax calculation logic with no existing feature flag coverage. Recommend wrapping the new tax computation in a LaunchDarkly flag (tax-calculation-v2) with a phased rollout targeting internal test accounts first, followed by 5% of production traffic.”

The developer can then action the recommendation, creating the flag in LaunchDarkly, adjusting the suggested configuration to fit their rollout plan, or noting the justification for proceeding without one as part of the deployment record.

Figure 3: AWS DevOps Agent release management report identifying checkout pricing changes deployed without LaunchDarkly feature flag coverage, including a suggested fix with sample code.

Closing the Loop with Kiro IDE

DevOps Agent’s release management capabilities identify when a deployment needs feature flag coverage. Paired with Kiro IDE, this recommendation becomes actionable without leaving the development workflow.

Kiro connects to LaunchDarkly’s MCP server directly, providing flag integration capabilities during development. When a developer builds a new feature in Kiro, the IDE can query LaunchDarkly via MCP to check whether a flag already exists for that feature and generate code with the flag evaluation built in from the start.

Together, this creates one continuous flow: DevOps Agent identifies the risk and recommends flag coverage → the developer, working in Kiro, generates the flag and wraps the code in a single action → the deployment ships with coverage already in place. No context-switching between tools, no manual flag creation in a separate console.

Developers can also use Kiro’s flag integration independently during feature development, even before a deployment triggers a release management review. The two operate as layered coverage: if Kiro catches it during development, DevOps Agent validates the targeting rules match the rollout plan at deployment time. If the developer bypasses Kiro or uses a different toolchain, DevOps Agent still identifies the gap.

Offense: Flag Recommendations During Incident Response

During an active incident, speed of containment directly affects customer impact. DevOps Agent participates in incident response workflows by querying LaunchDarkly to understand current flag state, then recommending containment actions based on what it finds.

Figure 4: DevOps Agent identifies a flag change (30ms from 2000ms) as the probable cause, queries LaunchDarkly for state, and recommends reverting the value.

When you detect an incident, DevOps Agent correlates the affected service with recent deployments. It queries LaunchDarkly to identify feature flags associated with those deployments and their current state (enabled, targeting rules, rollout percentage). If a relevant flag is enabled, the agent recommends disabling it as a containment option before suggesting a full rollback.

Flag-based containment provides an alternative containment option that can help reduce the time to resolution. Disabling a flag may return behavior to the previous state, which can be faster than a full deployment rollback in some scenarios

Example Scenario

An alert fires indicating sustained 5XX errors on the bot-service. The on-call engineer engages DevOps Agent, which:

1. Correlates the HTTP 503 errors with a LaunchDarkly feature flag change: bot-mutation-orchestration-timeout-ms was changed from the default 2000ms to 30ms (the “low latency” variation), applied to all traffic.
2. Identifies that the 30ms timeout budget is insufficient for inter-service HTTP calls during bot creation and deletion orchestration, which require DynamoDB reads/writes plus IoT Core calls, causing ReadTimeout exceptions.
3. Recommends reverting the bot-mutation-orchestration-timeout-ms flag to its default variation (2000ms) as the containment action, noting this will restore sufficient timeout budget without requiring a code deployment.

The engineer reviews the recommendation, updates the flag variation in LaunchDarkly, and the error rate returns to baseline within minutes.

Figure 5: AWS DevOps Agent investigation summary identifying a LaunchDarkly feature flag timeout change as the root cause of sustained 5XX errors

Step-by-Step Mitigation Plans

When DevOps Agent identifies a root cause, it generates a structured mitigation plan with concrete, executable steps. Rather than a generic recommendation, the agent provides:

1. Prepare — Document the current error baseline (with ready-to-run CLI commands, e.g., CloudWatch get-metric-statistics) and confirm the problematic configuration is still active before making changes.
2. Execute — Revert the specific change (in this case, reverting the LaunchDarkly feature flag bot-mutation-orchestration-timeout-ms from 30ms back to the 2000ms default) with clear instructions on which variation to target.
3. Verify — Validate that error rates return to baseline after the change, confirming the mitigation was effective.

Each step includes sub-steps with specific commands, API paths, and success criteria — giving the on-call engineer a clear, auditable runbook rather than a vague recommendation.

Figure 6: Structured mitigation plan generated by AWS DevOps Agent with executable steps to revert the feature flag and verify resolution.

Below, the LaunchDarkly targeting configuration shows the bot-mutation-orchestration-timeout-ms flag with its available variations. During the incident, the engineer reverted from the “low latency” variation back to “default” to restore the 2000ms timeout budget.

Figure 7: LaunchDarkly targeting configuration for the bot-mutation-orchestration-timeout-ms flag showing available variations including the default and low latency values.

Connecting to LaunchDarkly via MCP

As described in the introduction, DevOps Agent uses its MCP server feature to connect to LaunchDarkly’s hosted MCP server. This section covers the architecture and setup steps.

LaunchDarkly’s MCP server exposes flag management operations as agent-callable tools through the Model Context Protocol (MCP) standard. DevOps Agent connects as a client, giving it the ability to query flag state, read targeting rules, and list flags by project or environment without custom integration code.

Architecture

The connection follows this flow:

1. DevOps Agent identifies a need for flag-related context (e.g., during incident response).
2. DevOps Agent calls LaunchDarkly’s hosted MCP server using standardized MCP tool definitions.
3. LaunchDarkly MCP Server translates the request into LaunchDarkly API calls and returns structured responses (flag state, targeting rules, rollout percentages).
4. DevOps Agent uses the response to formulate recommendations presented to the engineer.

Registration and Configuration

To set up the connection:

1. Register LaunchDarkly’s hosted MCP server endpoint with DevOps Agent.
2. Configure authentication credentials (LaunchDarkly API key with appropriate scopes).
3. Validate connectivity by running a test flag query.

For the full setup walkthrough, including detailed configuration steps and permissions requirements, refer to LaunchDarkly’s companion blog post.

The same LaunchDarkly MCP server connection is available in Kiro IDE for flag-aware code generation during development; see the Defense section above for how Kiro completes the pre-deployment workflow.

Example Skill: High-Risk Feature Flag Recommendations

AWS DevOps Agent Skills are modular instruction sets that extend the agent’s capabilities with specialized domain knowledge and investigation methodologies tailored to your infrastructure and operational workflows. AWS DevOps Agent supports a subset of the Agent Skills specification. The format is flexible, but this example is structured into the following sections:

• Risk Classification Criteria — defines what constitutes Critical, High, and Moderate risk changes
• Feature Flag Recommendation Format — specifies the output structure: flag name, flag type, targeting strategy, and kill switch guidance
• Example Recommendations — provides reference examples so the agent produces consistent, actionable output
• Integration Notes — describes how recommendations surface during release readiness reviews
• What NOT to Flag — explicitly scopes out low-risk changes to reduce noise

Below is the full Skill used in this example:

# High-Risk Code Feature Flag Recommendations

When performing a release readiness review, use this skill to identify high-risk code changes and recommend LaunchDarkly feature flags for safer, controlled rollouts.

## Risk Classification Criteria

Evaluate code changes against these risk categories:

### Critical Risk (Always recommend feature flag)
- Payment/billing logic — any changes to checkout, payment processing, subscription handling, or pricing calculations
- Authentication/authorization — login flows, session management, permission checks, OAuth/SSO integrations
- Database schema changes — migrations, new columns, index changes, especially on high-traffic tables
- Data deletion or mutation — bulk updates, cascading deletes, data transformations
- Third-party API integrations — new external service dependencies or changes to existing integrations
- Core business logic — order processing, inventory management, user registration flows

### High Risk (Strongly recommend feature flag)
- New API endpoints — especially public-facing or partner APIs
- Performance-sensitive paths — changes to hot paths, caching logic, query optimizations
- Feature rewrites — replacing existing functionality with new implementations
- Concurrency changes — threading, async processing, queue handling modifications
- Configuration changes — environment variables, feature toggles, service endpoints

### Moderate Risk (Consider feature flag)
- UI changes to critical flows — checkout pages, login screens, dashboard views
- Logging/monitoring changes — new metrics, log format changes, tracing modifications
- Error handling changes — exception handling, retry logic, fallback behaviors

## Feature Flag Recommendation Format

When recommending a feature flag, provide:

### 1. Flag Name
Use a descriptive, lowercase, hyphenated name:
- enable-new-payment-processor
- use-v2-auth-flow
- rollout-order-service-refactor

### 2. Flag Type
Recommend the appropriate LaunchDarkly flag type:
- Boolean — simple on/off for feature enablement
- Multivariate — when you need multiple variations (A/B testing, gradual migrations)
- Number/String — for configuration values that might need adjustment

### 3. Targeting Strategy
Recommend an appropriate rollout strategy:
- Percentage rollout — start at 1-5%, monitor, then increase (default for most changes)
- User segment targeting — internal users first, then beta users, then general availability
- Environment targeting — enable in staging/canary before production

### 4. Kill Switch Guidance
Explain what happens when the flag is turned off:
- What code path executes when disabled
- Any cleanup or rollback considerations
- Data consistency implications

## Example Recommendations

### Example 1: Payment Processing Change

Code Change: Refactored payment gateway integration to support new processor

Recommendation:
CRITICAL RISK: Payment processing changes detected

Recommend wrapping in LaunchDarkly feature flag:
- Flag name: `enable-stripe-v2-integration`
- Flag type: Boolean
- Default: OFF (use existing payment flow)

Rollout strategy:
1. Enable for internal test accounts first
2. Expand to 1% of production traffic
3. Monitor payment success rates and error logs
4. Gradually increase to 100% over 1-2 weeks

Kill switch behavior: Reverts to existing payment processor immediately. 
In-flight transactions will complete with their original processor.

### Example 2: New API Endpoint

Code Change: Added new `/api/v2/orders` endpoint with different response format

Recommendation:
HIGH RISK: New API endpoint with breaking response format

Recommend wrapping in LaunchDarkly feature flag:
- Flag name: `enable-orders-api-v2`
- Flag type: Boolean
- Default: OFF (return v1 format)

Rollout strategy:
1. Enable for specific API clients by client_id targeting
2. Coordinate with consuming teams before enabling
3. Run both versions in parallel during migration period

Kill switch behavior: Returns v1 response format. Ensure v1 
serialization logic remains in codebase until flag is permanent.

### Example 3: Database Migration

Code Change: Adding new index to high-traffic `orders` table

Recommendation:
CRITICAL RISK: Database schema change on high-traffic table

Recommend wrapping dependent code in LaunchDarkly feature flag:
- Flag name: `use-orders-status-index`
- Flag type: Boolean  
- Default: OFF (use existing query patterns)

Rollout strategy:
1. Deploy migration to create index (can be done independently)
2. Deploy code that uses new index behind flag
3. Enable flag in staging, verify query performance
4. Enable in production during low-traffic window
5. Monitor query latency and database load

Kill switch behavior: Queries fall back to non-indexed path.
May see temporary performance degradation but no data loss.

## Integration Notes

When the release readiness review identifies high-risk changes:

1. Surface the risk level clearly in the review summary
2. Provide the flag recommendation with copy-paste ready configuration
3. Explain the rollout strategy appropriate for the risk level
4. Document the kill switch behavior so operators know what to expect

## What NOT to Flag

Not every change needs a feature flag. Avoid recommending flags for:
- Pure refactoring with no behavior change
- Test file additions or modifications
- Documentation updates
- Dependency version bumps (unless major version with breaking changes)
- Code formatting or linting fixes

Activating the Skill

DevOps Agent loads Skill metadata at the start of each workflow and loads the full Skill content when it determines relevance. To ensure the feature flag Skill is consistently applied during release readiness reviews, add a directive to your DevOps Agent Instructions (Agent.md), which is loaded in full at the start of every session:

“When performing release readiness reviews, always load and apply the high-risk-feature-flag-recommendations skill to evaluate code changes for risk and recommend LaunchDarkly feature flags where appropriate.”

This guarantees the agent loads and applies the Skill for every release readiness review rather than relying on relevance detection to surface it.

Getting Started

To begin using feature flag orchestration with AWS DevOps Agent and LaunchDarkly:

1. Enable AWS DevOps Agent in your AWS account to start building Skills and connecting MCP servers
2. Set up the LaunchDarkly MCP server: Follow the LaunchDarkly MCP server documentation for installation and configuration instructions.
3. Read the companion post: LaunchDarkly’s blog post explores why feature flags are essential infrastructure for SRE agents and how the LaunchDarkly MCP Server connects to AWS DevOps Agent for pre-deployment review and incident response workflows.

Conclusion

Feature flag orchestration with AWS DevOps Agent and LaunchDarkly reduces the manual coordination required during both deployment review and incident response. A DevOps Agent Skill surfaces flag recommendations before high-risk changes ship, and during incidents, the agent queries LaunchDarkly to recommend flag-based containment, providing faster resolution with less disruption than full rollbacks.

For developers using Kiro IDE, the same LaunchDarkly MCP server enables flag-aware code generation during development, shifting flag coverage left to the point of authorship. Together, these workflows provide layered coverage: individual developers build with flags, DevOps Agent’s release management capabilities validate coverage at deployment time, and DevOps Agent uses flag state during incident response.

Apple has asked the court for a preliminary injunction in its trade secrets lawsuit against OpenAI, arguing that it is being irreparably harmed as OpenAI continues to use allegedly stolen confidential information in its hardware development. While OpenAI agreed to stop using Apple's confidential information, preserve evidence, and halt disclosures, it refused Apple's requests for forensic inspections and comprehensive searches of its systems. Apple is also seeking expedited discovery, as OpenAI continues to publicly reject the allegations and criticize the lawsuit.

Ideas are cheap. Invention is not.

AI can generate ideas forever. How do you decide which ones survive?

Recently, my five-year-old wanted to build a pillow fort.

But he’d decided it couldn’t just be any old pillow fort. It needed to be different. It needed to be more interesting than “put the cushions against the sofa and throw a blanket over it”.

He wanted me to suggest things.

A cave? No.

A spaceship? No.

An igloo? No.

A pirate ship? No.

And at a certain point, I hit the limits of my imagination. I was tired, and I think he’d just decided to say “no” to everything. He was a challenging client. So I said “why don’t we ask ChatGPT?”.

It gave me ten ideas immediately. Some of them I’d already suggested. But he latched on to the idea of building an animal hospital, and he was off and building.

AI is a good machine for getting unstuck - it doesn’t run out of ideas.

But if there’s a machine that can generate ideas indefinitely, ideas stop being a scarce resource. The scarce resource becomes something else: selection, validation, even taste.

It’s less “can I think of something?”

It’s more “which of these ideas deserves to survive?”

Everyone with access to an LLM has their own brainstorming machine.

Brainstorming fills up a page. It can be energizing. It produces a list of things. But the old refrain of “no bad ideas in a brainstorm” only lasts as long as the brainstorm does. There’s nothing to say that those ideas will turn into something people would use, pay for, or trust.

Idea generation is not invention.

Building a pipeline, not a prompt

I created a set of invention skills that, together, are a structured opportunity discovery and invention suite.

Discover → Generate → Stress-test → Validate → Brief

I need the sequence.

Too much AI ideation starts in the middle. Product ideas. New features. Startup concepts. Ten improvements.

We need to start before that.

What’s the opportunity? Who has the pain? What workarounds exist? What would make someone want to use this? What pushes them away from current solutions, or keeps them attached to what they already have?

Once there’s a problem worth exploring, the suite generates concepts that go through multiple methods.

This isn’t free association. This is structured invention.

The suite applies SIT patterns. Uses TRIZ-style contradictions. De Bono provocations. It will collide problems with another domain entirely. It’ll map a solution space morphologically, and build a Zwicky box of parameters and combinations.

And when it’s expanded the problem into potentially hundreds of combinations of ideas, it gets less generous.

Ideas are scored. Stress tested. It compares competing hypotheses against the evidence. Validation planning asks which experiments reduce uncertainty. We do a Mom Test.

We apply kill criteria.

And then the pipeline produces a brief.

One page that states the opportunity, the proposed solution, and the evidence that supports it - provenance is vital. What’s still uncertain? How will we validate? When do we stop?

If you can’t give an elevator pitch for your invention then it’s not finished.

That doesn’t mean it isn’t useful. But it’s not work yet.

Pressure, not abundance

Different methods apply different pressures.

• The opportunity scan will ask if there’s a real problem underneath an imagined solution.
• SIT asks what happens if you remove something, divide it, give it new tasks, or add dependencies.
• Collision takes a domain and forces it into contact with another. Sometimes that second domain might be ancient. Sometimes it’s ordinary. Sometimes it’s weird. The point is not to deliberately get exotic. The point is to apply distance and structure.
• Morphological analysis maps the problem to configurations that might have been entirely overlooked.
• Hypothesis testing weighs ideas against supporting and contradictory evidence.
• Scoring forces those criteria into the open. It attempts to apply some objectivity, and to expose that judgment.
• Validation planning asks what the world needs to show us for this idea to earn more confidence.
• And the final brief ensures that the idea survives to the point of clear explanation.

The suite isn’t magic prompts.

It’s a set of instrumentation, where each instrument marks and deforms the problem in different ways.

Collision rather than metaphor

The skill I have the most fun, for me, is collision.

In a recent piece, I wrote about how old institutions can be repositories of hard-won judgement. Guilds, courts, religious orders, astronomers and scribes. Not because they’re quaint, but because they solved problems around trust, readiness, drift and dissent centuries ago.

My invention suite entrenches that instinct. But it’s not limited to ancient history.

Collision uses anything structurally rich.

DJs building mix decks manage transition, mood and energy. Air traffic controllers sequence risk. Emergency rooms triage scarce attention and resources. I’ve collided ideas and inventions with sources ranging from prehistoric petroglyphs to jazz improvisation to standup comedy.

The source domain has to be useful.

Pure analogy is decoration. “The dashboard is like a city.” Great. Maybe. But something operational needs to flow from that comparison. Metaphors can give the impression of depth without making anything better.

My collision skill tries to avoid that trap by mapping domains structurally.

Who are the roles? What are the processes? What are the constraints? What feedback loops exist? How does the system fail?

After that mapping, it looks for isomorphisms: places where the bones of those structures match up.

I don’t want to know if one idea reminds me of another.

I want to know if one domain has used a mechanism to solve a problem, and whether I can apply that mechanism to a different domain.

Collision should provide functionality.

Making a better dashboard

I’ve been building an internal product flywheel. An AI-and-human pipeline turning customer signals into prioritized work. Scanning sources, routing work, and giving a product manager a draft queue to review.

There’s a dashboard, so that the product manager can see what the flywheel did.

It provided status, trust tracks, run history, signal counts, sizing. It showed what was under the flywheel’s hood.

But the question I was asking of the dashboard was a simple one:

Do I need to do anything?

My dashboard had the problem many dashboards have. It shows you everything you already know. It expects you to infer what matters.

I ran the invention suite against a question: what should the next version of the dashboard look like?

The invention suite came back with a cluster of solutions.

Pattern-driven concepts from SIT. Possible configurations from the morphological pass.

The collider put the dashboard into contact with petroglyphs and twelfth-century administrative registers. That sounds ridiculous - until it produces useful artifacts.

The collision focused on an idea missing from normal critique. Spatial hierarchy is semantic encoding.

If something urgent is visually subordinate, that’s confusing.

That wasn’t the whole answer. But it was an additional pressure brought to bear.

And the same recommendation began to coalesce. A headline-first dashboard, with an action queue separated from the observatory.

That’s a good idea. It might even seem an obvious idea. And the important piece isn’t that the AI produced it. It’s important that multiple methods converged on it.

SIT liked that there was no need to parse the deck first. Morphological analysis had already identified “headline plus detail” as a strong configuration. Collision liked it because spatial hierarchy encodes priority.

It was solving a problem painful enough to justify work. And the hypothesis testing didn’t come back with contradiction.

And so the suite of skills concluded with a brief.

Build a headline-first dashboard with a plain-English status sentence at the top, and in the browser tab title. Put a queue of actions immediately underneath it. Don’t remove all the existing dashboard, but put it below the fold - for observation rather than action.

With a set of validation tests.

Do PMs close the dashboard quickly if it’s all-clear? Do action items get resolved? Does the headline produce false “all-clear” messages?

Scoring, challenging, briefing and validating is invention.

The Machine God isn’t omniscient

This doesn’t make the machine wiser.

The invention suite can still produce nonsense. Scoring can be subjective, with a veneer of precision. Validation plans are useless unless someone runs the experiments.

But the suite provides a foundation for better judgement.

I don’t want any single method to be authoritative. I want it to disagree. I want it to consider a null hypothesis (”don’t do anything”). I want kill criteria.

Curiosity is a good reason to explore something.

The invention suite is intended to help us turn that curiosity into trust.

Back at the pillow fort

My son didn’t need the invention suite for his pillow fort.

He just wanted ten ideas, fast, from a machine that thought faster than a tired dad.

After that, it was just a source of childhood play. The big list of possibilities is great when the cost of choosing is just having to pick up some of the cushions.

That’s not most work.

Product ideas have cost. Engineering work has cost. A strategic choice has cost. AI-generated recommendations entering the workflow have cost.

And as AI becomes increasingly powerful at generating ideas, our judgement of those ideas becomes increasingly important.

AI makes ideation trivial.

That exposes how much of invention was never ideation in the first place.

Invention is about killing the idea you really wanted to like. Then turning the surviving thing into a brief that’s clear enough for someone else to decide what to do next.

Invention is not cheap.

“How do we transition our thinking, not for one deeply thoughtful flow or feature, but for a whole system where agents can build things we’ve never seen?”

In his essay The Mental-Model Reset: Designing Systems That Decide, Aaron Sagray explores what it means to design intelligent interfaces at scale. The VP of design at Mural describes his own team’s shift and concludes that more than learning new tactics or design patterns, the next era of design requires a fundamental shift in perspective.

When an agent is composing the output itself, deciding at runtime what an analysis should look like for this user with this data, there is no screen to show. There’s a range of screens. A distribution of screens. … When the interface is assembled at runtime, designers need to shift to outcome-oriented design, defining the goals, constraints, and rules the generation must operate within, rather than the discrete elements themselves. …

Less playwright, more improv director. A playwright writes every line and the actors deliver it verbatim, eight shows a week, identical. An improv director never scripts a line; she designs the scene: who’s on stage, what they know, what the rules of the game are, what’s out of bounds. Then the performance happens, differently, every single night.

This change hurts the brain at first and sometimes offends professional instincts about what control and quality mean for design. Adapting requires unwinding some closely held assumptions about best practices or even what the craft is at its core. Aaron offers a list of 10 instincts to unlearn and proposes their replacements. On the “tired” list: “the screen I ship is the screen the user sees,” “same input, same output,” and “edge cases are rare states we document at the end.”

These are assumptions “held by your best people most firmly, because their careers were built on being right about them,” Aaron writes. “Treat the unlearning with respect or it won’t happen.” He offers an exercise to help limber up a design team around the implications and realities of radically adaptive interfaces.

Aaron draws on the good work of Maggie Appleton, Christopher Noessel, and Jakob Nielsen to explain the arc of this shift. And he shares some kind words about our book Sentient Design, too, calling it the best resource for embracing this transition: “The richest treatment of AI as a design material and radically adaptive interfaces. This is the book I’m recommending for this moment.”

Anthropic signs $10B deal with AI cloud startup Volta

Anthropic has been on a cloud partnership spree in recent months, and its latest move is reportedly a $10 billion deal with AI cloud startup Volta.

Bloomberg originally reported that Volta, founded earlier this year, will provide cloud compute to the Claude maker over a six-year period.

Volta has a partner in this deal, Bitdeer, a crypto-mining company that will help develop the data center to provide the compute capacity. That facility will be located in Norway and will deliver a 133 megawatt capacity. It will be fueled by Nvidia’s Vera Rubin systems, the chipmaker’s state-of-the-art AI chip architecture.

Volta is part of Nvidia’s Cloud Partner program, which is a consortium of AI cloud providers that use Nvidia’s GPUs in their data centers.

Volta had spoken about a deal with an AI lab but hadn’t named the specific company it was working with. Bloomberg originally cited anonymous sources familiar with the deal. TechCrunch reached out to Anthropic for more information.

Anthropic has sought to aggressively expand its compute capacity over the last several months as it wages a corporate battle with its competitors. The company also recently announced new compute deals with the likes of SpaceX and Amazon.

SpaceX's capital expenditures hit $18.4 billion in the most recent quarter. The bulk of that figure is tied to the company's ongoing AI build-out. The company is plowing money into terrestrial computing infrastructure, signing AI deals, and working toward launching orbital data centers. SpaceX is on track to have $100 billion in annualized recurring revenue by December, most of it coming from data center deals.

Siri AI will instantly become the world's most widely distributed AI chatbot when it is released in the fall in iOS 27. It excels at answering questions about on-screen data, and it can control device settings, send messages, and make phone calls, but ChatGPT has better conversational skills, advanced productivity features, and third-party integrations. This article compares the two chatbots to see how they stack up.

SpaceX plans to compete directly with mobile phone carriers in the US by complementing its satellite-based internet service with land-based infrastructure. The plan will require billions of dollars in investment into physical infrastructure. AT&T, T-Mobile, and Verizon have already said they will not give SpaceX access to their networks in a mobile virtual network operator capacity. They have formed a venture that aims to make satellite capabilities more readily available to mobile phone customers.

Huawei's top semiconductor scientist, Liao Heng, recently appeared on a four-hour-long interview where he discussed the best path forward in chip design, addressed some of the hardships Huawei faced when US sanctions cut it off from global chipmaking suppliers, and lauded Huawei's novel Tau Scaling Law approach. The appearance was a signal of confidence from the company. Huawei's Tau Scaling Law proposes focusing on improving transmission speeds between parts in a computer system. The company is set to soon unveil its first smartphone chip designed under that framework.

Most tech revolutions made work worse for employees. AI could be the exception

People are panicking about AI, yet racing to adopt it anyway. Fear of the robot apocalypse may be real, but it’s abstract and hard to prepare for. Believing AI will make your job worse is concrete, actionable and supported by changes brought about by previous tech revolutions. New tech has often benefited companies more than employees and led to more mundane work, time in the office and even existential dread. No wonder people are learning AI to keep jobs they expect to get worse. I may be contrarian, but I think this tech revolution could be good for both companies and workers.

The PC sped things up by shifting who did the work. The secretarial pool was eliminated because people typed their own memos and created their own presentations. The internet enabled email. Reaching customers and colleagues got faster and the post office and interoffice mail stopped being bottlenecks. Smartphones and laptops added 24/7 access from anywhere, raising velocity again and turning dens into home offices long before the pandemic. Prior to the PC, email and the smartphone, your job was to make 10 widgets a week; by 2015 you were supposed to make 20.

Increased access and speed led to more work. Companies thrived while employees worked harder. Expectations outstripped tech improvements. Melissa Mazmanian, Wanda Orlikowski and JoAnne Yates followed knowledge workers through the arrival of mobile email and named the result the autonomy paradox: people adopted the devices for the freedom to work anywhere and ended up working everywhere, all the time. The tool delivered flexibility to the individual and the group converted it into an expectation of constant availability. Nobody decided that. It’s just where the savings went.

I’m not arguing that technology never eliminates jobs, because it plainly does, or that the work it eliminates was good work. Almost nobody misses taking dictation. The stubborn pattern is that the time these tools save gets spent on higher expectations instead of going back to the person who saved it, however much that person is already doing.

The PC, email and the smartphone all increased the pace of work without doing any of it. Your email response didn’t write itself and the customer quote didn’t come together without your input. The promise of AI is different: it speeds things up, but it also does some of the work, including the net-new work that comes from everything moving faster. Your agent can draft a reply and even send a quote while you’re at the beach.

So far, the signs are somewhat discouraging. AI is making work more intense and not just for early adopters who are curious about it. People are expected to absorb tasks they once handed off since role boundaries are blurring. But we’re in the reorganization phase. Adopting significant new technology takes time and predictably causes turmoil and depresses output before paying off. This is a pattern economists call the productivity J-curve. The real question is whether, when the AI time savings finally arrives, we reclaim it or reflexively fill it with more of the same. I believe people will soon be encouraged to think and collaborate with the time saved.

When I’m stuck on a problem, I walk the dog, go for a run or hop on my bike, and I almost always come back with progress, sometimes even a solution. Maybe moving shakes an idea loose? I’m not unique: a Stanford study found that walking makes people more creative, even walking on a treadmill. But dealing with email often chains people to their desks.

My best ideas have come when talking to someone with a different perspective. Again, it’s not just me. Bell Labs built its famous lab around a long corridor designed so people from different disciplines crossed paths regularly, a deliberate choice by Mervin Kelly that Jon Gertner documents in The Idea Factory. MIT’s Thomas Allen measured the effect and found that communication between coworkers drops off sharply with distance, falling away past roughly 50 meters, and that later digital tools didn’t substitute for being close. Open-plan offices chase that proximity and mostly fail at it. When Ethan Bernstein and Stephen Turban studied two Fortune 500 companies moving to open floor plans, face-to-face interaction fell about 70% and people retreated to email. Nobody likes to be shushed, and people “crushing their goals” don’t get coffee with colleagues.

McKinsey expects AI to give knowledge workers back about 30% of their day by 2030. That’s roughly 2.5 hours. Automating 30% of the time spent on work won’t make 30% of roles redundant, since people aren’t fungible. And I don’t expect good companies to cut that fraction of positions. Instead, some firms will ask people to spend those hours making more widgets, but outside of commodities or markets with unmet demand, doing so just floods the market, drives prices down, and leaves you running to stand still. The alternative is improving quality, and at least one prior technology advancement has already set off a quality boom.

When desktop publishing arrived in the 1990s, people feared printshops would close and whole categories of work would vanish as everyone made their own newsletters and wedding invitations. But unlike the PC, email and the smartphone, it didn’t accelerate the pace of work. Instead, those new tools raised the quality bar. People tried making their own newsletters with images and clip art, fancy fonts and color, but realized they looked like ransom notes. Making a good newsletter isn’t just about tools. It requires skill and taste. Some rote jobs were indeed eliminated and few typesetters are left, but the design work grew. The number of designers working in the United States doubled over that span, from 393,000 in 1983 to 788,000 in 2001, while total employment grew 34% (Census Bureau, Statistical Abstract 2002, Table 588). AI is similar. An agent may be able to write at lightspeed in the voice of a well-known author, but that’s only part of the job. Even if writing well and quickly is commoditized, you still need great taste to choose a subject that will fascinate readers.

Improving quality starts with skill but taste requires creativity and collaboration, and 2.5 hours a day can fuel a lot of it. Some ideas will strike on a solo walk. Others will arise during an unplanned conversation. Those strolls and serendipitous chats might bring some purpose and community back to the AI-powered offices of the late 2020s. Desktop publishing proved a tech advance can pay off for workers and companies alike. AI is poised to prove it across the whole economy. Even if it doesn’t, I’ll settle for better muffler shop ads on the radio.

Microsoft has introduced new limits to how much its engineers can spend on AI tools at work and told employees that maximizing AI use internally is not the company’s goal.

This makes Microsoft one of the last major companies to rein in its employees’ expensive AI use. Scaling back maximalist AI use, or what some companies have called “tokenmaxxing,” is a trend we’ve covered in recent months as the price for using AI has increased while not always delivering commensurate productivity gains.

Bending Spoons to buy Airtable for $1.28B

In its first acquisition since going public last month, Bending Spoons on Tuesday said that it has agreed to buy spreadsheet and database startup Airtable for $1.28 billion in cash.

Founded in 2013, Airtable has so far raised more than $1.4 billion over multiple funding rounds. At its peak, during the boom days of 2021, it was valued at over $11 billion, but earlier this year, its shares were said to be trading on the secondary markets at a valuation of $4 billion.

With its current net cash-and-cash-equivalents balance, Airtable is now valued at about $2.25 billion, Bending Spoons said.

“Airtable is a pioneering brand reshaping how teams organize data and manage critical workflows. The value being delivered is reflected in annual recurring revenue growing over 20% YoY to approximately $480 million as of June 2026, and joining forces with Bending Spoons will accelerate innovation even further,” Bending Spoons’ founder Luca Ferrari said in a statement.

In January, Airtable unveiled a new product line under the Superagent moniker: an orchestration platform that can help users spin up a team of AI agents to do tasks. The company’s CEO, Howie Liu, said at the time that Airtable serves over 500,000 organizations, including 80% of the Fortune 100.

Bending Spoons, which went public at an $18 billion valuation in July, typically acquires companies that are trading at a decent discount to their private valuations, trims the staff, streamlines products, and tries to make them run profitably.

The company has so far acquired several notable brands, including Evernote, WeTransfer, EventBrite, and Vimeo.

For the past decade, Azure DevOps has powered software development at Microsoft, supporting some of our largest repositories and most complex engineering workflows across Azure Repos, Boards, and Pipelines.

Software development is being reshaped by AI, and where code lives now have a direct impact on how much value organizations can capture. For teams that want to take full advantage of AI-native development, repository location is becoming a strategic decision.

Azure DevOps and GitHub product teams have spent the past few years building the integration, migration, and enterprise-readiness capabilities needed to give organizations on Azure Repos a path to unlock the full value of GitHub’s latest agentic capabilities. That includes tighter Azure Boards and Azure Pipelines integration with GitHub repositories, purpose-built migration tooling like GitHub Enterprise Importer (GEI) and Enterprise Live Migrator (ELM), and the availability of GitHub data residency. As these capabilities came together, teams across Microsoft using Azure DevOps began actively exploring what it looks like to move repositories to GitHub while continuing to use Azure Boards and Azure Pipelines where those workflows remain critical. At Build 2026, we’re sharing what that looks like in practice: how we’re migrating, what we’ve learned, and what it means for organizations evaluating their own path forward.

Migrating at Microsoft scale with less engineering overhead

The Copilot, Agents, and Platforms (CAP) organization offers a useful view into what migration looks like at Microsoft scale. Responsible for Copilot products and other business and industry services, CAP operates roughly 4,000 active repositories across 53 Azure DevOps organizations. At that scale, it would be easy to assume migration requires a large, centralized team and months of focused engineering effort. CAP’s experience suggests otherwise.

With two dedicated engineering leads and a small bench of engineers supporting execution, CAP has migrated more than 80% of its in-scope repositories and 45% of its developers to GitHub. That translates to over 1,600 repositories and 3,100 developers over the past six months, including large repositories that support critical services such as Dynamics CRM and omnichannel CRM.

Some of CAP’s most complex repositories remain on Azure DevOps today, but the organization expects tools like Enterprise Live Migrator (ELM) to help accelerate the next phase, including more complex mono repos. For organizations planning a similar journey, that matters: large-scale migration is becoming more practical without requiring teams to pause ongoing development.

Why migrate now: AI is changing the calculus

By moving repositories to GitHub, CAP engineers gain earlier access to the latest AI capabilities as they become available. In practice, that means faster access to innovations such as GitHub Copilot Coding Agent, Code Review, Copilot Chat, and other agentic capabilities that are increasingly shaping how software is built and maintained.

The value is not just in the models themselves, but in where those capabilities show up. Across tools such as VS Code, Visual Studio, the GitHub Copilot CLI, GitHub Mobile, and the GitHub Copilot app, engineers can work with agents and AI assistance in the flow of day-to-day development rather than as a disconnected add-on.

CAP engineers are already running agentic workflows across migrated repositories, creating what is effectively a digital workforce of agents working alongside developers. These workflows can scan repositories for security, performance, and governance issues, open GitHub Issues, and route remediation to GitHub Copilot Coding Agent, including in Windows environments using Windows Runners.

Move repositories to GitHub while preserving critical DevOps workflows

For CAP, migration is as much about what stays as what moves. GitHub repositories are key to unlocking the latest AI and agentic capabilities, while Azure Boards and Azure Pipelines continue to support critical planning and CI/CD workflows.

To support this hybrid model, CAP uses the Azure Pipelines GitHub app to connect existing pipelines to migrated repositories and AB# syntax to link GitHub pull requests with Azure Boards work items.

Building on that foundation, CAP is also scaling newer workflows. By using GitHub runners with GitHub, teams can run Copilot agents across both Linux and Windows environments, enabling agent-driven workflows to operate consistently across a hybrid platform.

What changes after migration

Tools like GEI and ELM help move repositories quickly, but for many organizations the bigger question is what day-to-day work looks like after the move. For teams coming from Azure DevOps, GitHub can require some adjustment, especially when customization shifts away from UI extensions and toward APIs, Actions, and integrations.

Within CAP, developers with prior GitHub experience have helped ease that transition by sharing best practices and helping newer users adopt the platform. The organization’s hybrid approach reduces friction further by preserving familiar Azure Boards and Azure Pipelines workflows where they still add value.

GitHub also brings practical benefits beyond AI. Consolidating into a single GitHub organization improves code discovery across teams, reducing the fragmentation that came with work spread across 53 separate Azure DevOps organizations. Its multi-surface experience also makes it easier for developers to stay productive across the day, whether they are reviewing pull requests on mobile, working in the CLI, or using GitHub from the desktop.

Lessons for organizations evaluating their own path

Migration at this scale comes with tradeoffs, but it also creates meaningful opportunity. CAP’s experience highlights a few practical lessons for organizations evaluating their own path:

• Be deliberate about which repositories move first: CAP has already migrated more than 70% of its active, in-scope repositories, but many of the largest and most complex repositories remain on Azure DevOps. Tools like GEI and ELM can expand what is possible, but sequencing still matters.
• A hybrid approach can reduce disruption: Pairing GitHub repositories with Azure Boards and Azure Pipelines can make migration more manageable by preserving critical workflows while teams adapt to a new platform.
• Agentic capabilities are a major driver of value: Tools like GitHub Copilot Coding Agent, Code Review, and agentic workflows are changing how work gets done. For CAP, access to those capabilities is a primary reason to move repositories to GitHub.
• The platform shift brings additional benefits: Beyond AI, consolidating on GitHub improves code discovery, reduces organizational sprawl, and gives developers more flexibility through a multi-surface experience.

CAP is not alone in this journey. Other teams across Microsoft are following their own migration paths, reinforcing that this is broader than a single organization or use case. There is still work ahead, but the direction is becoming clearer: for teams that want to take full advantage of AI-powered software development, moving repositories to GitHub is increasingly becoming an important step. Microsoft’s early experience shows that this can be done incrementally, at enterprise scale, and without forcing organizations to abandon critical DevOps workflows overnight. Those lessons are already shaping what comes next inside Microsoft, and they can help other organizations make more informed decisions about their own path forward.

Full article content is not available for inline reading.

Read the original article →

AI has become the first audience for much of our work, interpreting and summarizing content before people see it, which makes machine-readable structure increasingly important. However, the goal should be to optimize for AI without designing for it, as the real value of design still lies in the invisible decisions—systems, accessibility, information architecture, and judgment—that AI-generated interfaces can't replicate. The challenge is to create experiences that are easy for machines to understand while remaining focused on the humans they're ultimately meant to serve.

Rebuild your website without starting over

Repaint is an AI website builder. Paste in your current URL, tell it what to keep or change, and get a new site in minutes.

Import from anywhere.

Repaint can rebuild sites from any platform. It uses AI to pull the content directly.

Plan your new site.

You describe what you want to keep, change, and delete. Repaint takes care of the rest.

Edit with chat.

Just ask in chat, and Repaint will edit anything on your site. No need to hire a web developer.

Done! I created a new Pricing page with three tiers.

Done! I added an interactive calculator to your Pricing page.

Done! The calculator now adjusts by team size.

The best AI web design platform

Generate images

Generate custom images for your site, matched to your brand.

Optimize SEO

Repaint can completely set up your technical SEO for you, so your site is ready for search.

Manage content at scale

Repaint is made to handle large business sites, including blogs and team pages.

Process documents

Upload files like PDFs or images and Repaint extracts the content for your site.

Fit every screen

Repaint designs sites that automatically look good on every screen size.

Pricing

Free

For getting started

$0

No credit card required

Unlimited websites

Limited weekly editing

Publish on Repaint subdomain

Includes Repaint branding

Plus

For professional websites.

$20 / month (Billed $240 annually)

Unlimited websites

Expanded weekly editing

Connect custom domains

No Repaint branding

Optional pay-as-you-go credits

Pro

For high-volume website editing.

$40 / month (Billed $480 annually)

Unlimited websites

4× the usage of Plus

Connect custom domains

No Repaint branding

Optional pay-as-you-go credits

FAQ

What is Repaint?

Repaint is an AI tool that rebuilds websites. You give it a link to your existing site, describe what you want to keep, change, or delete, and it generates a new version with updated design, content, and structure. You can keep editing by chatting with the AI until it's exactly what you want. If you don't have a site yet, Repaint can also build one from scratch.

Do I need an existing website?

No. A live site is the easiest starting point, but Repaint can also build from other references like images, files, or information it finds by searching you online. It's good at building from scratch too, so you can just describe what you want and go from there.

How is Repaint different from redesigning in my current platform?

Redesigning in your current platform means doing all the work yourself: rebuilding layouts, rewriting content, picking styles, moving things around. Repaint automates the process with AI, saving days of work. Then you manage your site in a state-of-the-art AI platform where big changes happen in minutes instead of hours.

Will my site look generic or obviously AI-made?

No. Repaint can reproduce your existing site's style and use your brand assets and colors, so the rebuild feels like yours. You can also pick a professional style from our library to avoid a generic AI look, or provide reference websites and screenshots to direct the design. Repaint takes direction well, so the output is tuned to your business.

What platforms can Repaint import from?

Repaint can import from any platform, because it reads the live website. You just need a link to it. The most common platforms people migrate from are WordPress, Wix, Squarespace, GoDaddy, Webflow, Framer, and Lovable.

Can I keep my existing domain?

Yes. Transferring the domain is simple. You can make a full new website in Repaint without touching your domain. Once you're happy with it, you swap your domain to point to the new site as the final step. Repaint can guide you through the process if you ask.

Will I lose my SEO rankings when I migrate?

No. Maintaining SEO requires maintaining the same page URLs, adding redirects if any change, and keeping the content consistent. Repaint is trained to do this for you. You can have it review everything before swapping the domain.

Can Repaint handle large sites?

Repaint can handle large sites, but we recommend working up to them. The technical side isn't the constraint, it's that importing a lot of content uses a lot of your weekly limit, and you don't want to migrate 100 pages only to realize you want a different style.

The best workflow for a large site: build the main pages first and nail the style, create one or two examples of CMS pages like blogs, then import the rest. This way you're not redoing work, and you have a clearer sense of how much usage you'll need.

What if I don't like the site Repaint builds?

Then ask Repaint to change it. You can drop one of our professional styles into the chat as a reference and have Repaint rebuild using it, or just pull pieces from it like the colors or typography. You can also tweak specific sections or regenerate the whole site. Big changes happen in minutes, so you can keep iterating until it feels right.

Can I make an ecommerce store in Repaint?

Repaint can make websites for a store, but it doesn't build inventory or checkout systems to process sales. If you want to sell through Repaint, you'll need to integrate a checkout system or link to another platform that handles it for you.

How much does Repaint cost, and how do usage limits work?

It's free to generate a site and start editing. Plus is $25/month ($20/month billed annually), which expands usage, connects a custom domain, and removes Repaint branding.

Usage limits control how much you can ask Repaint to do in a given week. They reset weekly and apply across all your sites. The free tier is sized for trying Repaint and building simple sites. Plus covers most real business sites, including ones with regular edits, and most Plus users never need to buy credits on top of their subscription.

Heavy one-time jobs are where limits matter most. Rebuilding a 100-page site or generating dozens of images can use a lot at once. For projects like that, we recommend migrating in chunks so you don't hit a limit mid-generation.

Anthropic, the AI company behind the Claude chatbot, recently agreed to pay $1.5 billion to a group of authors, in a settlement approved by a US judge. It might sound like a devastating blow. But does that mean creatives are winning the fight against AI? I'm not sure.

The first thing is that, legally speaking, this wasn't a verdict on whether AI was allowed to read these books and learn from them. That remains perfectly legal, after Judge William Alsup ruled last year that training an AI model on copyrighted text counts as 'fair use'.

Instead, the thing Anthropic is being fined for is downloading millions of books (including my own) from pirate sites such as Library Genesis, rather than buying them. The ruling doesn't say AI companies need permission to train on your work. It simply says they need a receipt.

Do the maths

Even the fine itself isn't as significant as it looks. Yes, $1.5 billion is an enormous sum. But it's basically loose change to a company valued in May at $965 billion. By my maths, that makes the fine less than 0.2% of Anthropic's worth: the corporate equivalent of losing a fiver down the sofa. Irritating, sure, but not game-changing.

The per-author breakdown is more depressing still. The settlement covers around 500,000 works, with eligible authors and publishers claiming roughly $3,000 per pirated book. US law technically allows damages of up to $150,000 per work in cases of wilful infringement, so authors are getting about 2% of the theoretical maximum.

That'll still be a useful cheque to many, and 91% of the roughly 440,000 eligible claimants have already taken it. But "largest copyright recovery in history" and "significant win for creatives" are two different things, and mainstream coverage of this case has mostly blurred them together.

Losing sleep

While this wasn't a win for creatives, it's not over for the AI companies either. The settlement doesn't release Anthropic from future claims, or from anything based on what its models actually generate. That's because this case was never really about Claude's output; it was about how Anthropic built its library.

Picture a burglar who smashes a window, climbs into your bedroom and rifles through your underwear drawer. He gets punished for the broken window, and you feel pretty good about that. Then the judge adds a footnote: had he climbed in through an unlocked window instead, the underwear-rifling would have been perfectly legal. You'd still find it hard to sleep at night, wouldn't you?

That's roughly where things stand for creatives. Artists, illustrators, photographers and game developers whose work has been fed into the current generation of AI models have no legal protection, as long as the company doing the feeding has a receipt for the book, print, game or whatever form their work was published in. That's rather less comforting than the "AI company forced to pay authors" headline suggests.

A settlement that won't settle anything

Be aware, too, that this ruling sets no binding precedent. By settling rather than going to trial, Anthropic has ensured the case will never reach an appeals court, the only route to a ruling that would bind other judges. Google, Meta, Midjourney and OpenAI are all fighting their own versions of this dispute, each to be decided on its own facts. Just last week, publishers including Hachette and Cengage filed a fresh suit against Google over Gemini's training data.

So what does the biggest AI copyright payout in history actually change for creatives? Less than the number suggests, I'd say.

It hands a welcome cheque to a few hundred thousand authors, from a company that can absorb the cost without much noticing. It confirms that training AI on your work without permission remains broadly legal, provided the company paid for its content first. And it leaves every other AI company's practices to be litigated separately, from scratch. The war, in short, rumbles on.

A discarded upper stage of a Falcon 9 rocket unintentionally crashed into the Moon early this morning. The four-ton rocket stage will hit the Moon at 5,400 miles per hour. It is unknown whether the flash from the crash and the resulting plume of debris and dust will be observable. Understanding the physics of such impacts could be crucial for people living on the Moon in the future.

OpenAI says that Apple was sloppy about securing files after employees left and has denied allegations that the employees it hired from Apple were involved in theft.

Figma's nested folders are a long-requested feature that helps growing teams stay organized. Creating the feature required rebuilding the company's content and permissions system from scratch. The team abandoned traditional product development in favor of leading with code, blurring roles across engineering, design, and product, and replacing handoffs with ongoing collaboration and shared craft. Customer feedback from early-access programs and community outreach shaped the rollout, which is expected to reach all users within a few weeks.

Vermont Tourism has unveiled its first dedicated brand identity, created by DNCO, with a custom wordmark inspired by the state's hand-painted signs, landscapes and cultural heritage. Rather than relying on generic travel imagery, the branding highlights Vermont as a "State of Inspiration," using a flexible design system to showcase its artistic community, natural beauty and local traditions. While some critics compared the logo to Comic Sans, the design's details intentionally reference Vermont's hills, roads, moonlit landscapes and folklore, making it part of a broader identity rather than a standalone logo.

Describe what you need. Watch a polished, on-brand deck appear in seconds. Iterate by chat. Export to PowerPoint, Google Slides, or as a PDF.

Autograph is a drag-and-drop motion design tool for all types of creators. You can swap images, video, and audio, and Autograph will handle the rest.

Frictionless design is often forgettable and meaningless, while friction can bring memory, reflection, connection, and personal growth back into experiences. Embracing friction, rather than eliminating it, is the path toward greater awareness, transparency, and growth.

Adoratorio Studio rebranded luxury eyewear retailer Indice for its 10th anniversary by repositioning it as "The Eyewear Lounge"—a welcoming, culture-driven destination rather than a traditional optical store. Inspired by the shop's interiors, the new identity features a flowing logo based on the curves of a De Sede sofa (which also resembles an eyelash), a muted color palette drawn from the space itself, and a mix of expressive typography and soft film-style photography. The result is a brand system that reflects the store's atmosphere of craftsmanship, intimacy, and slow, considered shopping, making the visual identity feel like a natural extension of the physical experience.

Epics and user stories often spark pointless arguments that muddy clarity.

Illustrator Anna Karetnikova creates richly detailed, emotionally expressive illustrations inspired by Slavic folklore, everyday life and traditional drawing techniques, inviting viewers to slow down and discover layered stories.